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