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.
|