Vampyre Imaging Library 0.26 Released

[Galfar]

Did you upload your dynamic loader unit? OpenJpeg.pas changed since 0.24. For example there is a new field in opj_image_comp record just before data field which could be the reason of your image.comps[Z].data[Y * Width + X] access violation.

What Linux distribution do you use? I testes static loader in Mandriva, SUSE, and Fedora and it worked ok there.

[Chebmaster]

I updated it by copying everything except the function definitions from your new module.

Everything looks identical:

  opj_image_comp = record
    dx: Integer;            { XRsiz: horizontal separation of a sample of ith component with respect to the reference grid }
    dy: Integer;            { YRsiz: vertical separation of a sample of ith component with respect to the reference grid }
    w: Integer;             { data width }
    h: Integer;             { data height }
    x0: Integer;            { x component offset compared to the whole image }
    y0: Integer;            { y component offset compared to the whole image }
    prec: Integer;          { precision }
    bpp: Integer;           { image depth in bits }
    sgnd: Integer;          { signed (1) / unsigned (0) }
    resno_decoded: Integer; { number of decoded resolution }
    factor: Integer;        { number of division by 2 of the out image compared to the original size of image }
    comp_type: OPJ_COMPONENT_TYPE; { type of this component: color channel, opacity, ... }
    data: PIntegerArray;    { image component data }
  end;

I checked the record size and enum size with the working Windows version, both are equal (52, 4).

I'm using Fedora 8.

...ok, it needs much more time that I currently have. Till weekend then.
On the other hand, you may have recompiled the libraries (how else could the record format have changed), but those I use for dynamic loading are from 3rd party and don't know that? Seems like it.

[Chebmaster]

P.S. I copied ImagingJpeg2000 unit from vampyre 0.24.2 and replaced the record definitions with that of 0.24.2, AND IT WORKED!

So, it seems, the root of the problem is that you've changed (customized?) the OpenJpeg library itself, making vampyre incompatible with the dynamic libraries I use. Or are you using their new 2.0 alpha version?
Sorry, got to go. More investigating later.

[Galfar]

Yes, that's it. I use customized OpenJpeg (loading/saving CDEF boxes in JP2 files to get proper support for images with alpha channel) library. I submitted the patch but OpenJpeh team said it could be added to 2.0, not current 1.3 because it changes library interface (hence the record sizes mismatch).
Can you use the compiled OpenJpeg lib from Imaging release? I could send you the patch if you want to compile it yourself. But note that OprnJpeg compiled in GCC with some optimization options screws up data of fourth and subsequent color channels.

[Chebmaster]

Can you use the compiled OpenJpeg lib from Imaging release?

I'd like to, but the "undefined reference to `pow' " spoils everything.

At the next weekend I'll look what could be done about this nasty obstacle. Preferably write the damned pow myself.

I could send you the patch if you want to compile it yourself.

Alas, my knowledge of c is negligible. The c sources would be of no use for me.

[Chebmaster]

Ok, this little addition to your OpenJpeg unit solves the problem:

{$ifdef unix}
  {$ifdef fpc}
    uses math;
  {$endif}
{$endif}  
...
      {$linklib libopenjpeglinx86.a}
      function pow(const base, exponent: Double): Double; cdecl;  export;
      begin
        Result:= Power(base, exponent);
      end;

I wonder if I can replace all of these required functions with wrapped Pascal equivalents and ditch that fat-ass c++ library altogether.

P.S. I removed {$LINKLIB stdc++} and it still compiles and still works. Don't tell me...

[Chebmaster]

P.P.S. Just removed fpc 2.2.0 and reinstalled 2.2.2. My program compiles, Vampyre works!
And there is no need for that pesky libstdc++. It seems, only that one pow() function was used.

[Galfar]

When I remove {$LINKLIB stdc++} FPC can't find pow but also C mem management functions like malloc/free/calloc etc. Not many functions overall so I'll add their Pascal replacements like you did with pow to OpenJpeg unit to get rid of stdc++.

Hmm when I compile project in Lazarus it doesn't need stdc++ nor function replacements, maybe Laz links some C libs automatically?

[Chebmaster]

Lazarus does something strange when it compiles, I avoid using it for compiling non-LCL applications. For my projects I write a special .sh/.bat script and tell Lazarus run it instead of calling the compiler directly. This gives quite different results, most notable is smaller executables. While compiling directly from Lazarus often creates executables that just won't run.

Lazarus is a handy thing and I'm glad it's here, but it still weird.

but also C mem management functions like malloc/free/calloc etc.

Aha. Then it probably works for me because my program links libc due to using the libc unit (required for determining RAM size).

Try adding uses libc to your units and see if the memory management functions are there. I suspect both libc and libstdc++ have these functions.

This what I got from Visual Dependency walker on my executable.

 libcrypt.so.1 /lib
   libc.so.6   /lib
     ld-linux.so.2     /lib
 libc.so.6 /lib
   ld-linux.so.2   /lib
 libdl.so.2 /lib
   ld-linux.so.2   /lib
   libc.so.6   /lib
     ld-linux.so.2     /lib
 libpthread.so.0 /lib
   ld-linux.so.2   /lib
   libc.so.6   /lib
     ld-linux.so.2     /lib
 librt.so.1 /lib
   ld-linux.so.2   /lib
   libc.so.6   /lib
     ld-linux.so.2     /lib
   libpthread.so.0   /lib
     ld-linux.so.2     /lib
     libc.so.6     /lib
       ld-linux.so.2       /lib
 libX11.so.6 /usr/lib
   libc.so.6   /lib
     ld-linux.so.2     /lib
   libdl.so.2   /lib
     ld-linux.so.2     /lib
     libc.so.6     /lib
       ld-linux.so.2       /lib
   libxcb.so.1   /usr/lib
     libc.so.6     /lib
       ld-linux.so.2       /lib
     libXau.so.6     /usr/lib
       libc.so.6       /lib
         ld-linux.so.2         /lib
     libXdmcp.so.6     /usr/lib
       libc.so.6       /lib
         ld-linux.so.2         /lib
   libxcb-xlib.so.0   /usr/lib
     libc.so.6     /lib
       ld-linux.so.2       /lib
     libxcb.so.1     /usr/lib
       libc.so.6       /lib
         ld-linux.so.2         /lib
       libXau.so.6       /usr/lib
         libc.so.6         /lib
           ld-linux.so.2           /lib
       libXdmcp.so.6       /usr/lib
         libc.so.6         /lib
           ld-linux.so.2           /lib

P.S. It still crashes spectacularly when I try to load a progressive JPEG file, allocating more than a gigabyte of RAM, pushing everything to swap, etc. No matter if I use {$DEFINE IMJPEGLIB} or {$DEFINE PASJPEG}

[Chebmaster]

P.S. I just dabbled a bit. The JpegError callback function is called when you call jpeg_start_decompress from TJpegFileFormat.LoadData, but since that function of yours is a stub, nothing happens.

P.P.S. Crash occurs only in the Win32 version, in Linux everything works fine.