Here is another clue that might help someone find the bug:
The shift in data is independent of the number of channels in the
deep-data part. When I tested with 6 channels (named A, B, G, R, X,
and Y), the channels are written and read in that (alphabetic)
order. Looking at the bad data read for pix[0] I discovered that
pix[0].A was garbage, but pix[0].B was pix[256].A. Each channel of
pix[0] was the previous channel's value for the last sample. It
looks like the data were in the buffer, but the start pointer was
off by one float.
On 04/20/2018 02:50 PM, Richard Hadsell
wrote:
Your last suggestion was most helpful. I had already examined the
pointers and strides, set the part to NO_COMPRESSION, and
generated only 1 sample per pixel, but I had not tried it with
tiny images.
I found that an image with a single scanline and up to 256 pixels
was okay. However, 257 pixels resulted in the first pixel
(pix[0]) having junk and the other pixels being shifted, so that
pix[1-256] had the values that should have been in pix[0-255].
This was the result from reading the file.
Using 'od' to look at the file showed that the last float in the
file was, indeed, the sample for pix[256]. Maybe the write was
okay, but the read was not.
(Testing with 258 pixels in the scanline resulted in bad data for
pix[0-1], and values in pix[2-257] were the samples that should
have been in pix[0-255].)
For the test with 257 pixels, I looked at the data in TotalView
and saw that readPtr, as calculated in line 673 of
ImfDeepScanLineInputFile.cpp, points to floats that correspond to
the samples that are bad. The first float is junk, and the next
256 samples are those that should have been in pix[0-255]. The
float after that was 0, not the value that should have been in
pix[256], so I conclude that the data in the buffer were not read
correctly from the file.
Of course, I don't know enough about the layout of data in the
file to know whether the problem is in reading or writing. I can
see that the samples are there in the file, but maybe they are in
the wrong place.
I hope this is enough information for someone to duplicate the
problem. I don't think I can take it any farther myself.
--
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
|