Re: [Openexr-devel] d_exr : assert (entrySize == _rmanPixelSize)

[Florian Kainz]

The "from += _rmanPixelSize" statements in lines 288 and 300 assume
that the input to DspyImageData is contiguous in memory.  The assert()
in line 254 makes this assumption explicit.  The assumption appears to
be wrong; your fix is probably the thing to do.

If anyone from Pixar is reading this, can you confirm that the input to
DspyImageData may not be contiguous in memory?

John, would you mind sending me the fixed version of d_exr.C, so that
I can check it into the Savannah CVS repository?

Florian


John Haddon wrote:
> Hi,
>
> We've been using d_exr for most of our prman rendering output here for a 
> good while, and are really happy with it (and very grateful).
>
> Very very occasionally we've had frames error with the following 
> assertion failure :
>
> prman: d_exr.C:254: void {unnamed}::Image::writePixels (int, int, int,
> int, int, const unsigned char *): Assertion `entrySize ==
> _rmanPixelSize' failed.
>
> We've finally tracked this down to something which only seems to occur 
> when we're rendering single channel float images, and pretty much only 
> when rendering with prman in single proc mode (although even more 
> occasionally in dual proc). In these cases it seems the pixel data prman 
> passes to DspyImageData is not contiguous in memory, and therefore 
> entrySize!=_rmanPixelSize, in order to specify the correct skip from 
> pixel to pixel.
>
> However, Image::writePixels asserts that these are the same. We removed 
> the assertion and used entrySize (as specified by prman to 
> DspyImageData) rather than _rmanPixelSize (as calculated in 
> DspyImageOpen) to calculate our pixel offsets into the data from prman, 
> and everything seems to work just fine in all cases we've tried.
>
> So I guess we have a couple of questions :
>
> 1) Is there a reason why the assert() is there, and the display driver 
> needs the data to be contiguous (is there something we've missed in 
> implementing our "fix"?) ?.
> 2) If what we've done seems sensible, is there a way we can commit it 
> back to savannah?
>
> It'd be great to know if anyone else has seen this, or if what we're 
> doing is just plain wrong for any reason...
>
> Cheers...
> John
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel