Re: Problem with deep data
Richard Hadsell <[email protected]> Fri, 20 Apr 2018 14:50:39 -0400
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4045361483670219867== Content-Type: multipart/alternative; boundary="------------090802050509030302090804" This is a multi-part message in MIME format. --------------090802050509030302090804 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Your last suggestion was most helpful. I had already examined the pointers and strides, set the part to NO_COMPRESSION, and generated only 1 sample per pixel, but I had not tried it with tiny images. I found that an image with a single scanline and up to 256 pixels was okay. However, 257 pixels resulted in the first pixel (pix[0]) having junk and the other pixels being shifted, so that pix[1-256] had the values that should have been in pix[0-255]. This was the result from reading the file. Using 'od' to look at the file showed that the last float in the file was, indeed, the sample for pix[256]. Maybe the write was okay, but the read was not. (Testing with 258 pixels in the scanline resulted in bad data for pix[0-1], and values in pix[2-257] were the samples that should have been in pix[0-255].) For the test with 257 pixels, I looked at the data in TotalView and saw that readPtr, as calculated in line 673 of ImfDeepScanLineInputFile.cpp, points to floats that correspond to the samples that are bad. The first float is junk, and the next 256 samples are those that should have been in pix[0-255]. The float after that was 0, not the value that should have been in pix[256], so I conclude that the data in the buffer were not read correctly from the file. Of course, I don't know enough about the layout of data in the file to know whether the problem is in reading or writing. I can see that the samples are there in the file, but maybe they are in the wrong place. I hope this is enough information for someone to duplicate the problem. I don't think I can take it any farther myself. On 04/19/2018 06:36 PM, Peter Hillman wrote: > > Hi Richard, > > It may also be instructive to confirm the library built correctly by building and running the IlmImfTest suite. Running IlmImfTest with "deep" as an argument will run only the deep tests. > > The source code of those tests should provide further examples of how to read/write deep data. The different tests intentionally use slightly different approaches to read/write data. You might modify one of those tests to disable the file cleanup, which > would generate a deep file you can read with your own code, and compare to the known values written into the file. > > Are you getting the correct sample counts but entirely incorrect data? That would suggest you have the pointer-to-arrays pointing to the wrong memory locations. If some of the values are correct (e.g. only the first pixel in the image, only the first > pixel on each row, or only the first sample of each pixel) that would suggest the pointers are correct, but the yPixelStride,xPixelStride,sampleStride (respectively) values are wrong. > > Try writing a small amount of 32 bit float data (e.g. a 2x2 pixel image with 1 channel) with compression set to NO_COMPRESSION and check the file contents in a hex editor: the last 4 bytes of the file should be the last sample of the last pixel of the > last channel in the file. That might tell you whether you are writing the file correctly > -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: [email protected] Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560 --------------090802050509030302090804 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by nospam.blueskystudios.com id w3KIo929000525 <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> Your last suggestion was most helpful.=A0 I had already examined the pointers and strides, set the part to NO_COMPRESSION, and generated only 1 sample per pixel, but I had not tried it with tiny images.<br> <br> I found that an image with a single scanline and up to 256 pixels was okay.=A0 However, 257 pixels resulted in the first pixel (pix[0]) having junk and the other pixels being shifted, so that pix[1-256] had the values that should have been in pix[0-255].=A0 This was the result from reading the file.<br> <br> Using 'od' to look at the file showed that the last float in the file was, indeed, the sample for pix[256].=A0 Maybe the write was okay, but the read was not.<br> <br> (Testing with 258 pixels in the scanline resulted in bad data for pix[0-1], and values in pix[2-257] were the samples that should have been in pix[0-255].)<br> <br> For the test with 257 pixels, I looked at the data in TotalView and saw that readPtr, as calculated in line 673 of ImfDeepScanLineInputFile.cpp, points to floats that correspond to the samples that are bad.=A0 The first float is junk, and the next 25= 6 samples are those that should have been in pix[0-255].=A0 The float after that was 0, not the value that should have been in pix[256], so I conclude that the data in the buffer were not read correctly from the file.<br> <br> Of course, I don't know enough about the layout of data in the file to know whether the problem is in reading or writing.=A0 I can see that the samples are there in the file, but maybe they are in the wrong place.<br> <br> I hope this is enough information for someone to duplicate the problem.=A0 I don't think I can take it any farther myself.<br> <br> <div class=3D"moz-cite-prefix">On 04/19/2018 06:36 PM, Peter Hillman wrote:<br> </div> <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dwindows-1252"> <p>Hi Richard,<br> </p> <p>It may also be instructive to confirm the library built correctly by building and running the IlmImfTest suite. Running IlmImfTest with "deep" as an argument will run only the deep tests.<br> </p> <p>The source code of those tests should provide further examples of how to read/write deep data. The different tests intentionally use slightly different approaches to read/write data. You might modify one of those tests to disable the file cleanup, which would generate a deep file you can read with your own code, and compare to the known values written into the file.<= br> </p> <p>Are you getting the correct sample counts but entirely incorrect data? That would suggest you have the pointer-to-arrays pointing to the wrong memory locations. If some of the values are correct (e.g. only the first pixel in the image, only the first pixel on each row, or only the first sample of each pixel) that would suggest the pointers are correct, but the yPixelStride,xPixelStride,sampleStride (respectively) values are wrong.<br> </p> <p>Try writing a small amount of 32 bit float data (e.g. a 2x2 pixel image with 1 channel) with compression set to NO_COMPRESSION and check the file contents in a hex editor: the last 4 bytes of the file should be the last sample of the last pixel of the last channel in the file. That might tell you whether you are writing the file correctly </p> </blockquote> <br> <pre class=3D"moz-signature" cols=3D"256">--=20 Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:hadsell@= blueskystudios.com">[email protected]</a> Blue Sky Studios <a class=3D"moz-txt-link-freetext" href=3D= "http://www.blueskystudios.com">http://www.blueskystudios.com</a> 1 American Lane, Greenwich, CT 06831-2560 </pre> </body> </html> --------------090802050509030302090804-- --===============4045361483670219867== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Openexr-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/openexr-devel --===============4045361483670219867==--