Re: OpenEXR from shared libs.
Nikolaj Thygesen <nikolaj.thygesen <at> diamondbox.dk>
2007-03-01 22:46:27 GMT
I must shamefully admit that the pure virtual msg of my previous
mail was caused by some debugging code of mine :o/ Though after fixing
this, my code still Seg-faults a while after finishing reading the
image, which, in some cases, I get to see. I don't know what would
happen if running my EXR code compiled into my main program instead of
keeping it in an .so as is presently the case.
I know 1.2.2 is a tad old, so I tried to build 1.4.0a myself, and
run "make check" which yielded the following partial output when
checking the RGBA interface:
file with missing and broken scan lines
writing
reading one scan line at a time, comparing
reading multiple scan lines at a time, comparing
number of threads: 1
channels RGBA, line order 0, compression 0
channels RGB, line order 0, compression 0
channels A, line order 0, compression 0
channels RB, line order 0, compression 0
channels RGBA, line order 0, compression 1
channels RGB, line order 0, compression 1
channels A, line order 0, compression 1
channels RB, line order 0, compression 1
channels RGBA, line order 0, compression 2
channels RGB, line order 0, compression 2
channels A, line order 0, compression 2
channels RB, line order 0, compression 2
channels RGBA, line order 0, compression 3
channels RGB, line order 0, compression 3
channels A, line order 0, compression 3
channels RB, line order 0, compression 3
channels RGBA, line order 0, compression 4
Segmentation fault (core dumped)
FAIL: IlmImfTest
===================
1 of 1 tests failed
===================
*** Error code 1
Stop in /usr/home/nikolaj/openexr-1.4.0/IlmImfTest.
*** Error code 1
Stop in /usr/home/nikolaj/openexr-1.4.0/IlmImfTest.
*** Error code 1
at least this indicates that there's something fishy going on with
the RGBA interface... at least on FreeBSD.
br - N :o)
Florian Kainz wrote:
> The "pure virtual method called" message is strange.
> Can you run your program in a debugger and check where
> exactly the call to the pure virtual method occurs?
> What does the stack trace look like at this point?
>
> Nikolaj Thygesen wrote:
>> Hi,
>>
>> I realize my example was badly and incompletely reproduced. The
>> slightly modified version incorporating your suggested changes
>> follows below.
>>
>> RgbaInputFile input_file;
>> Box2i dw = input_file.dataWindow();
>> Rgba pixels[width];
>> while (dw.min.y <= dw.max.y)
>> {
>>
>> input_file.setFrameBuffer(pixels - dw.min.x, 1, 0);
>> input_file.readPixels(dw.min.y);
>> dw.min.y++;
>>
>> }
>>
>> Unfortunately even after implementing your fixes my shared lib still
>> crashes in readPixels() during the first scanline :o( In fact this is
>> what I get:
>>
>> pure virtual method called
>> terminate called without an active exception
>> Abort trap: 6 (core dumped)
>>
>>
>> What you write makes much sense to me. I just can't make it fit with
>> the example from section 2.5 of the OpenEXR document, in which they
>> read a partial image, and do this calculation for every block:
>>
>> Array2D<Rgba> pixels (10, width);
>> while (dw.min.y <= dw.max.y)
>> {
>>
>> file.setFrameBuffer (&pixels[0][0] - dw.min.x - dw.min.y * width, 1,
>> width);
>> file.readPixels (dw.min.y, min (dw.min.y + 9, dw.max.y));
>> dw.min.y += 10;
>>
>> }
>>
>> To me "*&pixels[0][0] - dw.min.x - dw.min.y * width*" looks like you
>> need to offset the scanline from the origo of the virtual complete
>> frame buffer?! I suspect that perhaps the zero byte row stride saves
>> us in your example - no?
>>
>> Best regards - Nikolaj
>>
>> Florian Kainz wrote:
>>> Hi Nicolaj,
>>>
>>> I am not entirely sure how to interpret your example. I assume that
>>> your
>>> program contains a loop to read all the scan lines in a given file,
>>> but I
>>> am not sure which of the code in your example is meant to be
>>> included in
>>> the loop; it does make a difference. Let's say your code is
>>> analogous to
>>> this:
>>>
>>> RgbaInputFile input_file;
>>>
>>> Box2i dw = input_file.dataWindow();
>>> Rgba pixels[width];
>>> input_file.setFrameBuffer(pixels - dw.min.x - dw.min.y * width,
>>> 1, width);
>>>
>>> while (dw.min.y <= dw.max.dy)
>>> {
>>> input_file.readPixels(dw.min.y);
>>> dw.min.y++;
>>> }
>>>
>>> If this is the case, then frame buffer address arithmetic is wrong.
>>> No matter which scan line you are reading, you want the leftmost pixel,
>>> t x coordinate, dw.min.x to be stored in pixels[0]. The pixels at x
>>> coordinates dw.min.x+1, dw.min.x+2, etc. should to to pixels[1],
>>> pixels[2],
>>> etc. In other words, the address of pixel (x,y) is:
>>>
>>> pixels - dw.min.x + x
>>>
>>> Here's the corresponding setFrameBuffer() call (see also section 2.2 of
>>> the Reading and Writing OpenEXR Image Files document):
>>>
>>> input_file.setFrameBuffer (pixels - dw.min.x, 1, 0);
>>>
>>> Hope this helps,
>>>
>>> Florian
>>>
>>>
>>>
>>> Nikolaj Thygesen wrote:
>>>> Hi list,
>>>>
>>>> I'm currently trying to interface to the OpenEXR library from my
>>>> own shared library reading scanlines one at a time. My code is
>>>> heavily based on the sample code on the OpenEXR home page
>>>> describing the reading of an RGBA file using the RgbaInputFile
>>>> class + a raw copy-paste of the C_IStream class using the old-skool
>>>> stdio FILE *'s to access the bytes of files. When compiling my
>>>> program as a stand-alone program, everything works fine for all
>>>> sample *.exr files, but as soon as the code goes into a *.so,
>>>> reading crashes in the "input_file.readPixels(dw.min.y);" call of
>>>> the snippet below.
>>>>
>>>> I should mention that I'm running FreeBSD 6.2, using gcc 4.1and
>>>> OpenEXR V1.2.2, which is the release currently available in the
>>>> ports tree. My question is: Does OpenEXR have any issues with
>>>> shared libs?? Do I need or should I avoid any certain
>>>> compiler/linker flags??
>>>>
>>>> RgbaInputFile input_file;
>>>>
>>>> Box2i dw = input_file.dataWindow();
>>>> Rgba pixels[width];
>>>> input_file.setFrameBuffer(pixels - dw.min.x - dw.min.y *
>>>> width, 1, width);
>>>> input_file.readPixels(dw.min.y);
>>>> dw.min.y++;
>>>> lineno = line_number++;
>>>>
>>>>
>>>>
>>>> br - Nikolaj Thygesen
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openexr-devel mailing list
>>>> Openexr-devel <at> nongnu.org
>>>> http://lists.nongnu.org/mailman/listinfo/openexr-devel
>>>>
>>>>
>>>
>>
>
RSS Feed