[Top][All Lists]
[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
- [Openexr-devel] d_exr : assert (entrySize == _rmanPixelSize),
John Haddon <=