Vampyre Imaging Library 0.26 Released

[Galfar]

New version of Imaging was released few days ago.

0.26 Change list:
(+) Canvas class was extended with many new methods and effects. They include image drawing with blending (custom blending factors), filtered image stretching, nonlinear filters (min, max, median), point transforms (contrast, brightness, gamma, threshold), and blended rectangle filling.
(+)New data formats using 3Dc compression added: ATI1N and ATI2N. Updated DDS file format to be able to load and save images in this format. OpenGL and Direct3D extensions were updated to allow creating textures in these formats.
(+) New unit ImagingBinary.pas added with morphologic operations on binary images.
(+) XPM file format loader added.
(E) LCL Imager and Image Browser demos were extended with new functionality provided by canvas class (blending, filters, morphology, etc.).
(*) Updated OpenJpeg library (JPEG 2000) to version with CDEF patch that saves JP2 files with alpha properly.
(*)Changed some file format loaders/savers to be more thread safe so more images can be loaded concurrently.
(F) Many bugs in library fixed (GIF, BMP, and PNM loaders, ConvertSpecial, linear filters, ...).

Imaging homepage: http://imaginglib.sourceforge.net

[arthurprs]

downloading... :)

[Brainer]

Nice work man, keep it up! :D I'm going to use the latest version of your lib with my engine. Downloading. :)

[chronozphere]

Just awesome! ;)

[cronodragon]

Great! I'll try it!

[technomage]

I've never actually looked at Vampyre before. looks good I might give it a go :)

nice work.

[savage]

Nice work, bumped to news item.

[pstudio]

I'll join the other and say: "Great work" :D

[Chebmaster]

Ok, I found a time to try it, at last. :D
FPC 2.2.2:
The Windows version works without a notch.
The Linux version, hovever... :(

Linking ../../../chentrah
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_rateallocate':
tcd.c:(.text+0x1436): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_malloc_decode_tile':
tcd.c:(.text+0x21bb): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_init_encode':
tcd.c:(.text+0x2e76): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_malloc_encode':
tcd.c:(.text+0x392f): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_rateallocate':
tcd.c:(.text+0x1436): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_malloc_decode_tile':
tcd.c:(.text+0x21bb): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_init_encode':
tcd.c:(.text+0x2e76): undefined reference to `pow'
/e/cheb/chentrah/3rdparty/Imaging/Extras/Extensions/J2KObjects/libopenjpeglinx86.a(tcd.o): In function `tcd_malloc_encode':
tcd.c:(.text+0x392f): undefined reference to `pow'
/home/cheb/chentrah/modules/chentrah/src/chentrah.lpr(63,3) Error: Error while linking

My modified OpenJpeg with dynamic loading generates AV at first attempt to decode a file. I'll look into it further: looks like I missed something.

On the other hand, maybe I do it the wrong way. There is my build script:

BUILTIN=_test013

mkdir /tmp/.chentrah
rm /tmp/.chentrah/*

bin2obj -o cl_builtin_font.inc -c builtin_font font.png
bin2obj -o cl_console_font.inc -c iim_console consolefont.png
bin2obj -o cl_bgimg_error.inc -c error_bg_img cl_background_error.png
bin2obj -o cl_j2k_test.inc -c j2k_test_image cl_test.jp2

fpc extractdwrflnfo.pp -FE../../../bin/ -FU/tmp/.chentrah/
strip -s -x -X ../../../bin/extractdwrflnfo
fpc brutalstrip.pp -FE../../../bin/ -FU/tmp/.chentrah/
strip -s -x -X ../../../bin/brutalstrip
fpc incbuild.dpr -FE../../../bin/ -FU/tmp/.chentrah/
strip -s -x -X ../../../bin/incbuild

fpc chentrah.lpr -Xs -gw -XX -O3 -dcge -dnotlaz -OpPentium4 -OoUncertain -OoRegVar -OoPeepHole -Ooasmcse -Sd -Sh -Sc -Sg -Rintel -Fu./ -FE../../../ -FU/tmp/.chentrah/ -Fi../../${BUILTIN}/src/ -Fu../../${BUILTIN}/src/ -Fu../../../3rdparty/Imaging/Source/ -Fu../../../3rdparty/Imaging/Source/JpegLib/ -Fu../../../3rdparty/Imaging/Source/ZLib/ -Fi../../../3rdparty/Imaging/Source/ -Fu../../../3rdparty/Imaging/Extras/Extensions/ -Fu../../../3rdparty/Imaging/Extras/Extensions/J2KObjects/

../../../bin/incbuild build.h
../../../bin/extractdwrflnfo ../../../chentrah
mv ../../../chentrah.elf-zdli ../../../bin/
strip -s -x -X ../../../chentrah

[Chebmaster]

I removed fpc 2.2.2 and re-installed 2.2.0 but it still won't compile, the same "undefined reference to pow".

I'll look into in the next weekend. For now, I tried to find why it crashes when I use my dynamically loaded OpenJpeg, I traced the access violation to line 261 of ImagingJpeg2000,
more specifically, to
1: Pix^ := image.comps[Z].data[Y * Width + X] + Iff(Signed, $80, 0);
in
TJpeg2000FileFormat.LoadData
The Pix pointer hex value looks suspiciously low, maybe Bits is uninitialized?
Anyway, I have no more time today.

[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.

[Galfar]

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.

Found the bug at last.
See http://galfar.vevb.net/imaging/smf/index.php/topic,90.0.html

[arthurprs]

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.

Found the bug at last.
See http://galfar.vevb.net/imaging/smf/index.php/topic,90.0.html
galfar, this bug is critical or only present in some progressive jpeg's?

[Galfar]

galfar, this bug is critical or only present in some progressive jpeg's?
It seems that progressive Jpegs only, didn't gave any problems with normal Jpegs. Fixed Imaging is in SubVersion repository.

Note that the problem is still present in PasJpeg shipped with FPC and Lazarus.

[Chebmaster]

(post removed)

[JernejL]

Just wondering, can i use vampyre to compress TGAs into DXT3-ed dds? how can i achieve that?

[Galfar]

Just wondering, can i use vampyre to compress TGAs into DXT3-ed dds? how can i achieve that?
Yes you can, somplest code would be like this:
var
Img: TSingleImage;
begin
Img := TSingleImage.CreateFromFile('myfile.tga');
Img.Format := ifDXT3;
Img.SaveToFile('myfile.dds');
Img.Free;
end;

Any reason you want to use DXT3 instead of DXT5?

[JernejL]

My textures have alpha, and lower quality is not a issue, they must just take as little memory in the GPU as possible.

EDIT: seems like imaging's opengl extension doesn't support glscene opengl header, i'd like to suggest this would be a useful feature to have.

[Galfar]

Good idea about the header, current GLScene uses OpenGL1x.pas unit? (haven't seen GLScene for a while)
DXT5 textures take up the same amount of memory as DXT3 ones, and the alpha quality is usually higher.

[JernejL]

Good idea about the header, current GLScene uses OpenGL1x.pas unit? (haven't seen GLScene for a while)
DXT5 textures take up the same amount of memory as DXT3 ones, and the alpha quality is usually higher.

Yes it uses OpenGL1x.pas, but it names some constants differently than dgl and normal headers and has no ati compression extension constants, so i had to hack imaging opengl header a bit to get it working, but i have problems with it and i'll probably just convert the graphics to dds cache when ships load and use my own dds loader.

[JernejL]

Good idea about the header, current GLScene uses OpenGL1x.pas unit? (haven't seen GLScene for a while)
DXT5 textures take up the same amount of memory as DXT3 ones, and the alpha quality is usually higher.

I didn't know that, how does it improve alpha? by using space from color channels?

EDIT: galfar, i made a simple netimmerse image loader for imaging:
http://mathpudding.com/BC/imagingnif.pas

It is not a complex format, and the loader oversimplifies file structure a bit but so far this loaded every single .nif texture i had at my disposal without problems, the file format is used by star trek bridge commander and perhaps some other games using gamebyto / netimmerse game engine.

Another thing, what is the most efficient way for me to fill alpha channel with a specific color with imaging? is SetPixel32 the best way? i just need to fill alpha channel of ifA8R8G8B8 with blank alpha (full transparency) like.. SwapChannels but which sets the choosen channel with choosen value

[Galfar]

Alpha: You want to keep the other channels intact right? I'll add some function for
this to TImagingCanvas. This should work until then (for ifA8R8G8B8 only):
procedure SetAlpha(const Image: TImageData; const Alpha: Byte);
var
Data: PByte;
I: Integer;
begin
Data := @PColor32Rec(Image.Bits)^.A;
for I := 0 to Image.Size div 4 - 1 do
begin
Data^ := Alpha;
Inc(Data, 4);
end;
end;

NIF: Great work. NIF files store 3D models right (I remeber seeing them in Morrowind)?
So your loader extracts model texture from file? (more in PM)

DXT: DXT3 uses 4 bits per pixel for explicit alpha, so you have 16 possible alpha values for entire image. DXT5 also uses 4 bits but interpolates over 4x4 pixel block (you get max 8 possible alpha values but they can be different for each 4x4 pixel block) - RGB color in DXT is stored in the similar way.

[JernejL]

Alpha: You want to keep the other channels intact right? I'll add some function for
this to TImagingCanvas. This should work until then (for ifA8R8G8B8 only):
procedure SetAlpha(const Image: TImageData; const Alpha: Byte);
var
Data: PByte;
I: Integer;
begin
Data := @PColor32Rec(Image.Bits)^.A;
for I := 0 to Image.Size div 4 - 1 do
begin
Data^ := Alpha;
Inc(Data, 4);
end;
end;

NIF: Great work. NIF files store 3D models right (I remeber seeing them in Morrowind)?
So your loader extracts model texture from file? (more in PM)

DXT: DXT3 uses 4 bits per pixel for explicit alpha, so you have 16 possible alpha values for entire image. DXT5 also uses 4 bits but interpolates over 4x4 pixel block (you get max 8 possible alpha values but they can be different for each 4x4 pixel block) - RGB color in DXT is stored in the similar way.

Thanks for the alpha clearing code, i will add that to my game.

NIF is used by many games yes, but there are many versions of the format, the texture loader will work with version 3.1 and only for uncompressed files, i have a actual correct model loader in my project too (https://sourceforge.net/projects/st-sc), but it also loads only 3.1 models however nif tools project have code which loads and saves almost any nif file version.

EDIT: thanks for the dxt5 idea, i tried this now, and lights which are stored as alpha channel look much better on ships now, i'll stick to dxt5 now.

[Galfar]

Imaging library was updated to version 0.26.2.
Here's detailed change list:

(*) Delphi 2009 and Lazarus 0.9.26 compatibility fixes.
New project files for Delphi 2009 added. Kylix and CLX stuff removed.
(+) New canvas methods: flood and boundary fills, color channel
fills, color level adjustment, histogram calculation.
(+) Animated GIF support rewritten and it now properly animates
all tested GIFs (several thousand, true color ones too).
(+) PSD images with alpha channel are now saved as layers
to get proper transparency when opened in Photoshop.
(+) Added new Extras/Contrib directory with
Imaging modifications, extensions, demos, etc. contributed
by users (now with ExtraGIF, NIF loader, and HqResampler).
(*) Changed conditional compilation of ImagingComponents
unit to properly work with LCL widget sets other than Win32 and GTK.
(*) Removed linking against libstdc++ library in JPEG 2000 headers in Unix
(replaced with libc and Pascal functions).
(F) Fixed problem with loading of progressive JPEGs (out of memory)
when using FPC Win32.
(*) Changed LINK defined symbols that control which file formats will be
automatically registered.

Head to Imaging Homepage (http://imaginglib.sourceforge.net) for downloads and updated documentation.

[JernejL]

NIF code didn't make it into this version?

EDIT: nevermind :D i overlooked it.

[JernejL]

Imaging is missing raw image loading capability, for example i want to create a ifA8R8G8B8 image of specific dimensions, and use existing picture that i already have in a memorystream to create a imaging image object.

This would be incredibly useful when working with obscure and custom file formats in custom editors (usually because such formats are really strange and have strange features imaging doesn't support (example: renderware's extra image name for alpha channel)), right now it takes manually setting pixel data using SetPixelDirect, or writing a whole wrapper written around TImageFileFormat, which is a big overkill when you want - for example integrate imaging into some legacy image editor just to use it's more efficient dxt compression code.

If imaging class had a efficient readrawpixels method, i could just give it pointer to data to copy and easily build a image, this is a highly desirable feature.

perhaps there could be done using a overloaded NewImage method which takes additional parameter - pointer where to copy data from, or a SetPixelDirectEX routine, which can set a whole continous sets of pixels at once.

EDIT: i just found out that image has a "bits" and "size" property.. i feel rather silly now which makes this suggestion kinda redundant :|

[JernejL]

I noticed what is perhaps a bug in vampyre DXT3 compression implementation, alpha is totally messed up, see difference:

On left is MWDDS ( http://www.btinternet.com/~mnwright/graphix.htm ) dxt3 compressor i used so far (i believe it is based on nvidia dxtc code), and on right is vampyre, vampyre compressed picture alternates columns, if i manually swap each pair of columns the compressed image looks fine.

The format for both is ordinary DXT3 with alpha channel.

http://mathpudding.com/temp/imaging_dxt3.jpg

[Galfar]

Thanks for reporting this, bug was fixed and updated code is in SVN.

[JernejL]

There seems to be a missing unit in latest trunk - "LibTiffDelphi", I'm compiling this with delphi 7 - i set the no tiff directive to workaroun this.

EDIT:

I noticed that imaging dxt3c was performing kinda bad in quality when compared to say mwdds, i did some checking and came to conclusion that imaging's DXI1 and DXT3 produce pixel perfect exact images, both of which look like lower quality dxt1, is this by design, or is there any compression quality setting i can use?

http://mathpudding.com/temp/dxtccompression.jpg

[Galfar]

It's there, do you have it in search path (ImgLibRoot\Extras\Extensions\LibTiff)?.

You mean alpha or color quality of DXT 1 and 3? Color compression/decompression scheme for all DXT formats is the same (only differs a bit for DXT1 with alpha).
As you wrote mwdds is based on NVidia's dxt compressor, their and ATI's compressors (used in ATI Compressonator) produce better quality results than many other compressors.

[JernejL]

Maybe this can help you, it seems that nvidia switched their compressor with this aswell, the quality is very nice, it is opensource and the codebase also doesn't seem very big:

http://www.sjbrown.co.uk/2006/01/19/dxt-compression-techniques/

http://code.google.com/p/libsquish/ ( MIT License)

[JernejL]

I got my hands on a libsquish dll from a friend that i can use with delphi, it's a little glitchy (some very odd AV exception issue), but try..finally block avoids it, still - the image compressed works properly, so i'm using that for now.

It would be great if imaging could use libsquish, i wouldn't object if you had it link to a external library, but ofcourse with a compiler define so people can choose weither they want to use libsquish for compression. since most of time compression is done in external game tools having a external dll would not be a issue.

I rewrote some more tools i had for my game to use imaging library, i rewrote the sprite "delta" builder - which compares a bunch of images based on pixels, the speedup is around 500%!

[Galfar]

Thanks for the tip. I checked out squish's sources and it looks like it wouldn't be too much work to adapt of of its compression schemes for Imaging. Which one do you think gives best results or which one do you use (cluster fit, range fit, ...)?

Could you provide that dll and header for delphi please? I could make Imaging extension out of it. I'm also thinking of translating whole squish to Pascal, that would take some time though.

[JernejL]

The most suitable algorythm i would ever choose is always the best quality one, not looking at the speed. libsquish code is very fast and uses a very high quality compression setting as default.



procedure CompressImage( const rgba: pointer; width, height: integer; block: pointer; flags: integer{; metric: pointer }); stdcall; external 'libsquish.dll'; // metric is part of new version, the dll is compiled for old one
procedure DecompressImage( rgba: pointer; width, height: integer; blocks: pointer; flags: integer ); stdcall; external 'libsquish.dll';
function GetStorageRequirements( width, height, flags: integer): integer; stdcall; external 'libsquish.dll';


I think the way the dll was compiled causes the strange exceptions in my app, you could just recompile the dl to make sure it works properly with delphi.

The dll is from rage tools by Arushan as part of spark iv:
http://code.google.com/p/gtaivtools/source/browse/trunk/RageLib/Textures/Encoder/Squish.cs
http://code.google.com/p/gtaivtools/

EDIT: are you planning to add any functionality to rotate image by any angle? it would be useful for some preprocessing i intend to to for my game sprites, but i can do it with opengl, if it's not planned.

[Galfar]

The most suitable algorythm i would ever choose is always the best quality one, not looking at the speed.

Yeah, true for offline texture preprocessing. Some applications need realtime DXT compression though. Best way would probably be to provide two compression options - very fast/lower quality, slow/good quality. That's what I'm planning for future Imaging.



I think the way the dll was compiled causes the strange exceptions in my app, you could just recompile the dl to make sure it works properly with delphi.

I got exceptions too, but they were caused by wrong calling convention of CompressImage. Try using cdecl instead, I get no more exceptions now.



EDIT: are you planning to add any functionality to rotate image by any angle? it would be useful for some preprocessing i intend to to for my game sprites, but i can do it with opengl, if it's not planned.

This is planned for next release.



For now I created extension for Imaging that uses Squish DLL, check it out here:
http://imaginglib.svn.sourceforge.net/viewvc/imaginglib/trunk/Extras/Extensions/ImagingSquishLib.pas?view=markup

[Rodrigo Robles]

We are using Vampyre Imaging in our Project (http://www.pascalgamedevelopment.com/forum/index.php?topic=4559.0). It works pretty well. Thanks Galfar for this great work.

[Galfar]

We are using Vampyre Imaging in our Project (http://www.pascalgamedevelopment.com/forum/index.php?topic=4559.0). It works pretty well. Thanks Galfar for this great work.

Rodrigo, I see there's also my SOAR code in Mundo's sources. Is it used for anything there?

[Galfar]

Imaging library was updated to version 0.26.4.
Here's detailed change list:


(+) APNG file format (Animated PNG) loading, animating, and saving added to existing PNG support.

(+) Arbitrary angle image rotation.

(+) Mac OS X (Intel) compatibility (garbled LCL bitmaps in Carbon, JPEG 2000 support, ...).

(+) XPM file format saving added, JPEG 2000 file format loading improved.

(+/F) New canvas methods: premultiply and unpremultiply alpha. New methods for TFastARGB32Canvas: InvertColors, DrawAlpha/StretchDrawAlpha. Fixed DrawAlpha/StretchDrawAlpha destination alpha calculation.

(+) Three new extensions in Extras/Extensions directory: ImagingJpegIJL.pas uses Intel Jpeg Library to load/save Jpegs (DLL needed), ImagingSquishLib.pas uses Squish DXTC library with Imaging (DLL needed), ElderImagerySky.pas loads SKY images from Daggerfall.

(+) Conversions between RGB and YCoCg colorspaces.

(F) Bug fixes: loading of some GIFs when using D2009+ failed, bugged XPM loading in Linux, indexed images resizing leak, PNM saving using D2009+, DXT3 alpha encoding, RGB>>CMYK conversion, garbled images in Lazarus GTK IDE.

(*) Delphi 2010 and Lazarus 0.9.28 compatibility fixes.

_________________________________________________
Head to Imaging Homepage (http://imaginglib.sourceforge.net) for downloads and updated documentation.

[JernejL]

(+)[/b] Arbitrary angle image rotation.


Is this rotation interpolated, or just rotating simple pixels? if it's interpolated, does it handle alpha channel aswell?

[Galfar]

Yes, linear interpolation is used.
And alpha is handled the same as all other channels.
You can test how does it look like in LCLImager demo.

[JernejL]

That's great, as soon as i get someone to work on art for my game i'll use this to pre-generate car door animations, it should save hours of manual slicing in paint shop pro.

[Rodrigo Robles]

We are using Vampyre Imaging in our Project (http://www.pascalgamedevelopment.com/forum/index.php?topic=4559.0). It works pretty well. Thanks Galfar for this great work.

Rodrigo, I see there's also my SOAR code in Mundo's sources. Is it used for anything there?


I did not notice that you is the author of the SOAR code too. Appears to be that you own a great slice of the Mundo source :)
We made tests with SOAR, but we aren't using it yet. Maybe we use it later, when we start to enlarge the map.

[Rodrigo Robles]

Galfar, I got two reports of people having difficulties to compile Imaging under Windows 7 64-bit and Freepascal.
They send me the following error messages:

"-Imaging\ImagingJpeg.pas(190,53) Error: Argument can't be assigned to -Imaging\ImagingJpeg.pas(356,45) Error: Argument can't be assigned to -Imaging\ImagingJpeg.pas(407,47) Error: Argument can't be assigned to"

There are some tip to compile in this environment?

[Galfar]

Which version of Free Pascal?
And which version of Imaging?
(line numbers in error message don't match the most recent version of ImagingJpeg.pas I have)

[Rodrigo Robles]

Which version of Free Pascal?
And which version of Imaging?
(line numbers in error message don't match the most recent version of ImagingJpeg.pas I have)


The reported errors came from the following box:

* Windows 7 64-bit
* Lazarus 0.9.28 beta
* Imaging ImagingJpeg.pas,v 1.9 2006/02/23

[Galfar]

Well that's nearly 4 years old version of Imaging, no 64-bit compatibility was in back then.
It's the lines like this one:

Inc(LongWord(Dest), PtrInc * LinesRead);
that cause problems - assumes sizeof(pointer) = 32.

You can fix those lines or just upgrade to newer Imaging version.

[Rodrigo Robles]

Well that's nearly 4 years old version of Imaging, no 64-bit compatibility was in back then.
It's the lines like this one:

Inc(LongWord(Dest), PtrInc * LinesRead);
that cause problems - assumes sizeof(pointer) = 32.

You can fix those lines or just upgrade to newer Imaging version.


Well, I think upgrading is better :)
Thanks Galfar.

[JernejL]

I put the free rotating to good use in my car sprite editor, automatic generation of detachable parts rocks :D

just wondering, is there any distort functionality in imaging lib?

such as: http://www.imagemagick.org/Usage/distorts/#shepards ?

[Galfar]

Currently there are no distortion functions in Imaging. Something simpler like affine matrix transforms could be added but probably nothing fancy as Shepard (not much time for working on Imaging recently).

[JernejL]

Well, i need something to apply localized distortions, to apply some kind of damage to the vehicle textures.