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: address@hidden
Blue Sky Studios http://www.blueskystudios.com
1 American Lane, Greenwich, CT 06831-2560
|