Vampyre Imaging Library 0.24.0

[Galfar]

New version of Imaging was released few days ago.

Main news/changes in 0.24.0:
- New image file format support: GIF (native), TIFF (libtiff), Photoshop PSD (native).
- New image data format: BTC (block truncation coding).
- File format compatibility fixes (for BMP, JPEG, and DDS) and platform/compiler support fixes (Win64, UNIX, FPC, ...).
- Bug fixes and some enhancements (buffered file IO, ...).

Current Imaging info and features:
Imaging is native Object Pascal cross platform image loading, saving and
manipulation library. Main development language is Object Pascal (Delphi, Kylix and Free Pascal compilers are supported) and there are interfaces to the library (compiled into dll/so) for other languages like C/C++ and Delphi.NET. Currently supported operating systems are Windows, Linux, FreeBSD, DOS (and .NET using unmanaged DLL). Supported CPU architectures are x86 and AMD64.
Currently supported image file formats are: (loading and saving) BMP, JPEG, PNG, GIF, TGA, DDS, MNG, JNG,
JPEG2000, PSD, TIFF, PGM, PPM, PAM, PFM (loading only) PCX, and PBM.
Many internal image data formats are supported: 8/16/24/32/48/64 bit RGB and ARGB formats, indexed formats, grayscale formats, half/single precision floating point formats, and compressed formats DXT1/3/5 and BTC.
Additionally there are extensions for creating SDL surfaces, OpenGL and D3D9 textures, VCL/LCL TGraphic descendants, canvas class, and more.

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

[Chebmaster]

I think you deserve to know. :D

I used your vampyre to rebuild Quake 2 renderer (ref_gl.dll) - just to add the lanczos filtering. The result is...

Happy second birthday, Q2!

before/after :
http://host-17-99.imsys.net/_share/_001/q2_facelift.jpg
before (big): (http://host-17-99.imsys.net/_share/_001/q2_facelift_before.jpg)
after (big): (http://host-17-99.imsys.net/_share/_001/q2_facelift_after.jpg)

I wonder why didn't Carmack do that by himself?.. The art in Q2 has a huge reserve that the original engine just wastes uselessly, due to the hardcoded 256x256 texture size limit - while the textures range from relatively small to 309x170 to even 512x256...

Did you know that?

[Galfar]

Nice work Cheb. Hmm, 256x256 looks like Voodoo max texture size, does Q2 downsample textures even when using software renderer?

[Chebmaster]

No, it doesn't. AFAIK, software renderer's limit is 512x256 (btw., all the bosses have the skins of that size: the big tank, the "bee" flyer, Makron too.)

That's why I noticed the problem in the first place: I saw that the software renderer gives a much sharper picture. Unfortunately, most of the mission pack won't work with software renderer: they glitch, then they crash.

[cronodragon]

I have a question about the licensing. If I distribute a software with your library what should I add to the software? A copy of your license, credits, the source code? I'm not well versed about licenses :?

[arthurprs]

Awesome :twisted:

[Chebmaster]

A bugreport
(note: I'm still using the 0.22.0 so these bugs may be already fixed)

-- This progressive jpg file crashes the loader spectacularly (it allocates up to 1Gbyte of memory, then everything dies because I have only 1Gb RAM):
http://www.chebmaster.narod.ru/_tmp/_crashes_cl_background_default.jpg
(note: click the link on the page that opens, the narod.ru hosting force-inserts a disclaimer that they aren't responsible for the image content)

-- The NewImage() fails if called on an uninitialized TImageData variable (i.e. you always need to zero it with FillChar() beforehand, or things go boom)

[Galfar]

Thanks for the reports:


-- This progressive jpg file crashes the loader spectacularly (it allocates up to 1Gbyte of memory, then everything dies because I have only 1Gb RAM):
http://www.chebmaster.narod.ru/_tmp/_crashes_cl_background_default.jpg
(note: click the ]
Probably some problem with JpegLib, I'll check it out.
[quote="Chebmaster"]
-- The NewImage() fails if called on an uninitialized TImageData variable (i.e. you always need to zero it with FillChar() beforehand, or things go boom)
Well, InitImage is expected to be called for every TImageData before using NewImage or any other function. It is stated somewhere in the docs but I'll put it in some more visible place too.

[arthurprs]

i'm using this lib since the first day i downloaded it, highly recommended .

[Chebmaster]

Well, InitImage is expected to be called for every TImageData
Oops... :oops:

But still, using records is a bit illogical. I think it would be better to use "handles", where each handle is PImageData and the image data itself is allocated and handled by Vampyre (for example, NewImage/Load Image returns such a pointer instead of using an user-defined variable).

But it's probably too late now.


i'm using this lib since the first day i downloaded it, highly recommended .
Same here :)

[ianatwork]

I've got some images that are stored in a database a DIBs. Is there anyway I can get them into a TImageData ?

[Galfar]

I've got some images that are stored in a database a DIBs. Is there anyway I can get them into a TImageData ?
If they are standard Windows DIB bitmaps (or other formats supported by Imaging) you could get the data from DB and use LoadImageFromMemory (or LoadImageFromStream) function to get them into TImageData.

[ianatwork]

I see there is a "resize Image" function that takes a width and height value. Is there a command that will allow me to just enter one of these values and the resulting picture will be resized but keeping the original aspect ratio ?

[Robert Kosek]

I see there is a "resize Image" function that takes a width and height value. Is there a command that will allow me to just enter one of these values and the resulting picture will be resized but keeping the original aspect ratio ?In all honesty finding the aspect ratio is childsplay, so I don't see why it needs a function where you can omit these values. It's as little as two lines....

If you truly want to, then you can make overloaded versions that do this. As far as I know, and I looked at the docs, you cannot omit one dimension and let the library solve for it for you.

aspectratio := img.height / img.width;
ResizeImage(img, newheight, width * aspectratio, rfBicubic);

[ianatwork]

aspectratio := img.height / img.width;
ResizeImage(img, newheight, width * aspectratio, rfBicubic);

This doesn't seem right to me (or may be I've misunderstood). I have an image that is 64 by 64 so using your example I have an aspect ratio of 1 ( image.height / image.width = 1 ). If I want to resize the height to 100 my width would still be 64 as I'm multiplying the original width by my aspect ratio of 1. I end up with a tall narrow image which isn't what I want.

[Galfar]

aspectratio := img.height / img.width;
ResizeImage(img, newheight, width * aspectratio, rfBicubic);

This doesn't seem right to me (or may be I've misunderstood). I have an image that is 64 by 64 so using your example I have an aspect ratio of 1 ( image.height / image.width = 1 ). If I want to resize the height to 100 my width would still be 64 as I'm multiplying the original width by my aspect ratio of 1. I end up with a tall narrow image which isn't what I want.

This should work:
aspectratio := img.width / img.height;
ResizeImage(img, newwidth, newwidth / aspectratio, rfBicubic);

Imaging doesn't keep aspect ratios when resizing. As Robert wrote, it is not hard
to find correct width and height (although it would be easy to extend ResizeImage to keep the
ratios).

[ianatwork]

Hello, Thanks for your help, I've now sorted my problem. I'm using the image library to extract images from a database and then formatting them before they are saved. How they are manipulated is totally scripted so most of the libraries functionality is configurable via XML. Being able to resize an image and keeping its aspect ratio was a feature that my program needed so I had to implement it. As others have mentioned, it is straight forward. I just didn't want to spend time "reinventing the wheel" if there was already a handy feature such as a flag or passing in -1 to the parameter that needed to be auto sized. Anyway, its all sorted now so thanks again.

[Robert Kosek]

Sorry about that Ian, my code was untested psuedocode that demonstrated the principle. I haven't actually done something with it and I figured that there had to be an error somewhere. As Galfar demonstrated, the adjustments are simple enough to get it operational. ;)

Sounds like an interesting piece of work you're making there. You'll have to show us some screenshots here sometime.

[cronodragon]

Galfar! Your imaging library is great!! :D I started trying to create my own BMP interpreter and when I checked all you made in your library I totally removed my code. Now I'm integrating Vampyre in my game engine. Noticed a file size increase in my exe of just about 200 KB which is ok to me. And the possibility of using it without dragging DLLs is excellent.

Have you thought about creating a pixel format converter? In my engine I'm only using RGB and ARGB formats, which are the most useful. I consider lower pixel formats are bad quality, so it's better having only the truecolor ones and optimize everything around them. I'd like to make this pixel format converter that transforms an image loaded with Vampyre if the pixel format is low.

Regards!
-Marco

[Galfar]

Galfar! Your imaging library is great!! :D
Glad you like it.



Noticed a file size increase in my exe of just about 200 KB which is ok to me.
Most responsible for the increase are file formats like JPEG, JPEG2000, and PNG. If you don't
need some of them you can disable them in ImagingOptions.inc and the file size increase should
be smaller.



Have you thought about creating a pixel format converter? In my engine I'm only using RGB and ARGB formats, which are the most useful. I consider lower pixel formats are bad quality, so it's better having only the truecolor ones and optimize everything around them. I'd like to make this pixel format converter that transforms an image loaded with Vampyre if the pixel format is low.

I'm not sure what exactly do you mean. Program that converts loaded images?

[Brainer]

That's exactly what I've been looking for! I'm going to use it with my engine. :) Thanks a lot and keep improving the library. It's just awesome!

[cronodragon]

Have you thought about creating a pixel format converter? In my engine I'm only using RGB and ARGB formats, which are the most useful. I consider lower pixel formats are bad quality, so it's better having only the truecolor ones and optimize everything around them. I'd like to make this pixel format converter that transforms an image loaded with Vampyre if the pixel format is low.

I'm not sure what exactly do you mean. Program that converts loaded images?

I mean a function that converts between pixel formats :)

[Galfar]

I mean a function that converts between pixel formats :)
Well, you can already convert between all supported image data formats.

[cronodragon]

I mean a function that converts between pixel formats :)
Well, you can already convert between all supported image data formats.

With this one? http://galfar.vevb.net/imaging/doc/RefDoc/ConvertImage@TImageData@TImageFormat.html

That's what I was looking for :D

[Galfar]

With this one? http://galfar.vevb.net/imaging/doc/RefDoc/ConvertImage@TImageData@TImageFormat.html
Yes, that's the one, ConvertImage.

[Galfar]

A bugreport
(note: I'm still using the 0.22.0 so these bugs may be already fixed)

-- This progressive jpg file crashes the loader spectacularly (it allocates up to 1Gbyte of memory, then everything dies because I have only 1Gb RAM):
http://www.chebmaster.narod.ru/_tmp/_crashes_cl_background_default.jpg
I finally had some time to look at you image. Looks like the problem is in Pascal translation of JpegLib, original C code compiled to objects and linked to Pascal app works fine.
FPC generated exes crash with "out of memory", Delphi just screws up some colors.

[Chebmaster]

I installed fpc 2.2.2 for linux... and unexpectedly, it created a problem with vampyre.

If I disable extras, everything is fine.
If I enable extras, various linking problems arise. First, it couldn't find libstdc++.a . I searched for it and copied to /usr/lib. Now linker says "undefined reference to `pow' " :(
I want jpeg2k support, so just disabling extras doesn't appeal to me.

Did I install fpc incorrectly? (I did it from an .rpm package, not from yumex)
Or I probably just need to link some c math library - now to figure its name :?

Why the same {$linklib stdc++} worked in fpc 2.2.0 ?
The executable generated by 2.2.2 is much smaller than one generated by 2.2.0 (0.8 Mb vs 1.7) Maybe they shed dependency on some c library?

[Chebmaster]

P.S. I'll try to modify OpenJpeg.pas, make it dynamically load libopenjpeg.so . It's one more dependency, but smaller executable.

[Chebmaster]

Ok, I implemented the dynamic loading. The windows DLL I downloaded from http://www.openjpeg.org/ (has a weird name mangling and stdcall convention). The Linux dll is a part of Linux ("openjpeg" package). I had to add dynamic loading of libstdc++.so.5 for it to work.

There were three modifications:
1. to ImagingJpeg2000:
{$ifdef DYNAMIC_LINK_JPEG2000}OpenJpegDynamic{$else}OpenJp eg{$endif};

3. The unit itself,
http://217.70.20.10/cge/openjpegdynamic.pp

P.S. On the other hand, I'll just have my own OpenJpeg.pas in my project directory. Compiler will find it first and use it insteda of one included with vampyre. Ain't I clever? 8)

[Galfar]

Sorry for not answering earlier Cheb, I was on vacation.
I haven't installed FPC 2.2.2 yet, I'll check it out and try to fix the static linking.
Good work on the dynamic loader, I could add it to Contrib part of Imaging release if that's ok with you (there's new version of static OpenJpeg.pas though).

[Srki_82]

Any particular reason for BGR(A) pixel format instead of RGB(A)?

[paul_nicholls]

I assume BGR(A) is used so it can match the Windows BMP format more easily :-)
cheers,
Paul

[Galfar]

I assume BGR(A) is used so it can match the Windows BMP format more easily :-)
cheers,
Paul
Yes, and D3D textures, GDI, TGA images, etc.
Some RGBA formats are supported too though.

[Chebmaster]

OpenGl can use this texture format easily. Caused me some trouble though, since I belong in the "If after umpteenth try it doesn't work, READ THE MANUAL AT LAST!" category. :oops:

[vgo]

I can't use any jpeg images as textures with OpenGL, LoadGLTexture always returns 0 as the handle?

[Galfar]

Some more information please, it works for me.
Library version, OS, compiler, maybe upload on of your jpegs that doesn't work.
Other formats work ok for you?

[vgo]

That was on 0.26.0, I had forgotten to update... With 0.26.2 it works just fine. :)

[vgo]

This is strange... When I use the 0.26.2 version with Delphi 2007 and 2009 they both complain about memory leaks??? I don't even have to load any images I just have to include them in my project... I didn't have this with the old version I used.

EDIT: The actual memory leaks are not caused by Vampyre, but they are still strange and point to classes that could possible not have memory leaks (ie. TObject descendant with one LongWord public variable and a few methods etc.)...