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: hads...@blueskystudios.com
Blue Sky Studios http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
_______________________________________________
Openexr-devel mailing list
Openexr-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/openexr-devel
