Re: Problem with deep data
Richard Hadsell <[email protected]> Mon, 23 Apr 2018 11:46:32 -0400
| Newsgroups | gmane.comp.video.openexr.devel |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4076184376392080350== Content-Type: multipart/alternative; boundary="------------000309070106010802060708" This is a multi-part message in MIME format. --------------000309070106010802060708 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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. -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: [email protected] Blue Sky Studioshttp://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560 --------------000309070106010802060708 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 w3NFjrQ9006760 <html> <head> <meta content=3D"text/html; charset=3Dwindows-1252" http-equiv=3D"Content-Type"> </head> <body bgcolor=3D"#FFFFFF" text=3D"#000000"> <br> <br> <div class=3D"moz-cite-prefix">On 04/22/2018 05:13 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"> <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=3D355) 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> <br> <div class=3D"moz-signature">-- <br> <pre class=3D"moz-signature" cols=3D"256">Dick Hadsell 203-992-63= 20 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> </div> </body> </html> --------------000309070106010802060708-- --===============4076184376392080350== 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 --===============4076184376392080350==--