Re: [Openexr-devel] OpenEXR from shared libs.

[Nikolaj Thygesen]

   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
> > > > address@hidden
> > > > http://lists.nongnu.org/mailman/listinfo/openexr-devel