Re: Problem with deep data
Richard Hadsell <[email protected]> Fri, 27 Apr 2018 14:43:49 -0400
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============8795918442762410734== Content-Type: multipart/alternative; boundary="------------020209070305000409010009" This is a multi-part message in MIME format. --------------020209070305000409010009 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 04/23/2018 11:46 AM, Richard Hadsell wrote: > > On 04/22/2018 05:13 PM, Peter Hillman wrote: >> >> Duplicating the problem will be hard without seeing your code. If the IlmImfTest deep tests are passing, but your code is failing, that would make me suspect there's either a bug in your own code, or that you are using the API in an unusual way - >> different to how the tests use it - that's triggering a bug we've not seen before. The IlmImfTest suite does write images similar to the ones you've been testing with. >> >> A couple of perhaps more obvious things to double-check: make sure that you don't have a mysterious 8 bit variable there that's wrapping round in a weird way, or some calculation that's casting to a 'char' instead of 32 or 64 bit value. That could fit >> the your symptoms, particularly if it's in the part of the code where you set up the array of pointers to float arrays to store each pixel. Also, a common slip-up with OpenEXR is forgetting that the data and display windows are /inclusive/ - a 256 pixel >> wide image has displayWindow.max.x set to 255. >> >> On linux, you might try running your code through valgrind to see if it identifies any issues with accessing uninitialised or out-of-bound memory. >> >> In your descriptions you don't mention how many samples per pixel are being written. Perhaps try writing 257 pixel wide scanline with one data sample in each pixel, then an image where the first or the last pixel has many samples and all the rest have 0 >> samples. This might shed light on whether the odd behaviour you are seeing is dependent on the total number of samples written, or the total number of pixels. You can also try writing with an offset dataWindow (e.g. a 256 pixel wide dataWindow with >> dataWindow.min.x = 100 and dataWindow.max.x=355) to see whether the 256 pixel problem is relative to the dataWindow or the displayWindow. >> > My tests were using 1 sample per pixel. I verified in TotalView that the pointers I set up are correct, and the OpenEXR code is accessing them correctly. > > I will try to test other variations of sample numbers, as you suggest. And I will also try to run it through valgrind. > > Meanwhile, I will also try to work around the problem by using tiles that are no more than 256 pixels wide. I found the problem in our code. It was a mistake in the return code from the read function in our I/O class that derives from IStream. The EOF indication was reversed. In ordinary reads, this was ignored. Only when called from a skip function did the bug have an effect. It stopped the skipping over the sample counts after the first 1024 bytes (256 pixels). Thank you for your suggestions. Testing the effects of various numbers of samples in various places showed nothing new, but it forced me to follow the actual read operations in TotalView, which uncovered the skip function that was returning early. -- 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 --------------020209070305000409010009 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 w3RIdi72018991 <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> On 04/23/2018 11:46 AM, Richard Hadsell wrote:<br> <blockquote cite=3D"mid:[email protected]" type=3D"cite"> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> <br> <div class=3D"moz-cite-prefix">On 04/22/2018 05:13 PM, Peter Hillma= n 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"> <br> Duplicating the problem will be hard without seeing your code. If the IlmImfTest deep tests are passing, but your code is failing, that would make me suspect there's either a bug in your own code, or that you are using the API in an unusual way - different to how the tests use it - that's triggering a bug we've not seen before. The IlmImfTest suite does write images similar to the ones you've been testing with.<br> <br> A couple of perhaps more obvious things to double-check: make sure that you don't have a mysterious 8 bit variable there that's wrapping round in a weird way, or some calculation that's casting to a 'char' instead of 32 or 64 bit value. That could fit the your symptoms, particularly if it's in the part of the code where you set up the array of pointers to float arrays to store each pixel. Also, a common slip-up with OpenEXR is forgetting that the data and display windows are <i>inclusive</i> - a 256 pixel wide image has displayWindow.max.x set to 255.<br> <br> On linux, you might try running your code through valgrind to see if it identifies any issues with accessing uninitialised or out-of-bound memory. <br> <br> In your descriptions you don't mention how many samples per pixel are being written. Perhaps try writing 257 pixel wide scanline with one data sample in each pixel, then an image where the first or the last pixel has many samples and all the rest have 0 samples. This might shed light on whether the odd behaviour you are seeing is dependent on the total number of samples written, or the total number of pixels. You can also try writing with an offset dataWindow (e.g. a 256 pixel wide dataWindow with dataWindow.min.x =3D 100 and dataWindow.max.x=3D3= 55) to see whether the 256 pixel problem is relative to the dataWindow or the displayWindow.<br> <br> </blockquote> My tests were using 1 sample per pixel.=A0 I verified in TotalView that the pointers I set up are correct, and the OpenEXR code is accessing them correctly.<br> <br> I will try to test other variations of sample numbers, as you suggest.=A0 And I will also try to run it through valgrind.<br> <br> Meanwhile, I will also try to work around the problem by using tiles that are no more than 256 pixels wide.<br> </blockquote> I found the problem in our code.=A0 It was a mistake in the return code from the read function in our I/O class that derives from IStream.=A0 The EOF indication was reversed.=A0 In ordinary reads, th= is was ignored.=A0 Only when called from a skip function did the bug hav= e an effect.=A0 It stopped the skipping over the sample counts after th= e first 1024 bytes (256 pixels).<br> <br> Thank you for your suggestions.=A0 Testing the effects of various numbers of samples in various places showed nothing new, but it forced me to follow the actual read operations in TotalView, which uncovered the skip function that was returning early.<br> <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> --------------020209070305000409010009-- --===============8795918442762410734== 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 --===============8795918442762410734==--