openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: John Haddon
Subject: [Openexr-devel] d_exr : assert (entrySize == _rmanPixelSize)
Date: Fri, 04 Mar 2005 15:45:42 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]