I’m currently rewriting much of a Jpeg 2000 for Pascal library. There is a new IO class responsible for decoding and encoding of Jpeg 2000 files instead of only VCL TBitmap descendant. It’s cross platform and with only Delphi/FPC RTL dependencies. VCL and LCL TGraphic classes will be built using this IO class but it can be used independently as well (Imaging library will use it too).
New features of Jpeg 2000 for Pascal will be CMYK colorspace support and also indexed/palettized images support (yes, it’s possible to have image using palette in Jpeg 2000). These features as well as proper alpha channel definitions are patched into OpenJpeg library. Its team is not very active in incorporating larger patches into their code, so patches will probably always be additional step for people who want to recompile OpenJpeg themselves for use with PasJpeg2000.
You can follow the progress of the new version in SVN repository here: branch v120.
I tried compiling Imaging in C++ Builder (it uses Delphi compiler to generate .obj file which C++ linker can link and also generates C++ header for Pascal unit) few years ago. It didn’t work – there was internal compiler error, I think right in ImagingTypes unit.
Few days ago I tried C++ Builder 2010 and was pleasantly surprised. It worked! I tried just the library core for now (ImagingTypes, Imaging, ImagingFormats, Pascal only file handlers, etc.) and it works without problems. I’m not sure which C++ Builder version is required for successful compile though. Versions 6 and 2006 stopped with internal error, 2010 worked, and there are 2 other versions between.
Anyway, I’ll try to check out most of the library until the 2010 trial expires for me. Hmm, I’m wondering how many people use C++ Builder for C++ development – I’ve never did something serious in it, basically just to get object files usable by Delphi – so I have no idea if it’s ok.
PS: Another C++ Builder related news – patch for OpenJpeg library to get it compiling in BCB is posted here.
JPEG 2000 for Pascal project is based on OpenJpeg library. For a very long time there was a bug that caused alpha (fourth and subsequent image channels) channel to be saved with all the samples having the value of 0.5 (128 for 8bit channels). This buggy behavior also depended on compiler settings – optimization level in case of GCC. You could use at most O1 in Windows and Linux, and only O0 in Mac OS X. Bug was also present when compiling with C++ Builder (to get object files usable in Delphi) but only when irreversible DWT transformation was enabled in OpenJpeg during encoding (it wasn’t before, but working versions of both PasJpeg2000 and Imaging use it now when lossy compression is selected by user to get smaller files).
You can read more about it in this news group post. Basically it was all fixed by changing a condition in one if statement to prevent accessing the fourth element of a three element array.
So what can you expect in the next version of PasJpeg2000 library?
Higher GCC optimization levels should make it a lot faster when using Free Pascal (particularly in Mac OS X where O0 was used). Irreversible DWT transformation produces smaller lossy files than current PasJpeg2000 version and with optional MCT (multicomponent transform – basically RGB>YCbCr) you get even smaller ones. There’s now also a patch that enables OpenJpeg to get palettes from JP2 files so indexed JPEG 2000 images could be supported too. And finally, there are some bug fixes (wrong reconstruction of subsampled files, …).
Vampyre Imaging Library project was updated to version 0.26.4 few hours ago. This was supposed to be fix/patch/update release only but new features got in nevertheless (most notably APNG support I wrote about earlier and arbitrary angle image rotations).
More info and downloads at Imaging’s homepage.
Imaging supported DXT image/texture compression since one of the earliest releases. Quality of compressed images isn’t very high though (at least the compression isn’t too slow). For future Imaging versions I plan to ditch the current compression code and add a new one. To be precise, two new ones – fast and lower quality (still probably better than current Imaging’s compression), and slow and higher quality mode. Fast one will be based on Real-Time DXT Compression by Id Soft. I’m not decided on high quality one yet, but probably something like cluster fit algorithm from Squish library.
Mainly for testing purposes during implementation of these new methods, I want to create extension for Imaging that compares two images (original and one reconstructed from compressed original) and measures PSNR and some other quality metrics.
I’m also thinking of implementing DXT5 based format using YCoCg colorspace and PVRTC (texture compression currently used in iPhone).
Few links if you’re interested:
Here’s some quick comparison of DXT compressors (click the image to see full size). Value in brackets is MSE (mean square error) – lesser number means compressed image is more similar to original.
I finally released first version of JPEG 2000 for Pascal library. It’s based on translated header and precompiled OpenJpeg library that was part of Imaging for a long time – now released separately.
There’s header translation working with both Delphi and FPC and original C library precompiled to object files (Delphi) and static libraries (FPC for Win32, Linux x86/x64, and Mac OS X).
I’ve written simple TBitmap descendant that loads and saves JPEG 2000 images. It’s only for Delphi now – can’t do LCL version with just few IFDEFS, there are lot more changes between VCL and LCL TBitmaps. I plan to write separate LCL version for one of upcoming releases (using TFPCustomImageWriter and TFPCustomImageReader classes).
You can get JPEG 2000 for Pascal library at it’s project page.
APNG loading and animating implementation for Imaging wasn’t very hard work. However, there are not that many test images to be found on the Internet and most of the available ones are very simple. They’re usually not using disposal methods and are basically just collection of independent images. Big difference compared to GIF files – some of them were quite difficult to animate right. I even got most of nontrivial APNG test files by converting some more complex animated GIF files. Tools for creating APNG images are not yet as sophisticated as some GIF animation tools – there’s GIF to APNG converter, APNG Anime Maker, and some web based tools that assemble simple APNG file from bunch of uploaded single PNG frames.
Now I’m gonna extend PNG saver to allow saving multi images to simple APNG files, much like MNG saving works now. There’s really not a good unified way how to pass some more information to image file savers in current library design – that’s one of TODOs for new Imaging architecture.
I started working on support for APNG format for Imaging library. APNG is unofficial extension of PNG image file format created by two guys from Mozilla Corporation. The point of APNG is to allow storing simple animations in PNG files (hence the “A” for “Animated”).
There is already PNG-like chunk based format for animations called MNG (already supported by Imaging – at least the basic features). However, MNG is quite complex format and its support among browsers and image viewers/editors is lacking. Code library supporting all MNG features is huge.
APNG on the other hand is just an extension of PNG and its implementation is not so complex. I’m going to load only the raw frames from files at first and see what will have to be done to support animating the frames next. Canvas class will have to be used here for alpha blending subsequent frames to previous ones. I’ll add option to turn the animating on/off just like it is available for animated GIF files.
More info about APNG: http://www.animatedpng.com and https://wiki.mozilla.org/APNG_Specification.
I wasn’t sure if Vampyre Imaging Library works right in Mac OS X until few weeks ago. One poster in Imaging’s forum wrote a post about scrambled images produced by the library on Mac OS X. Fortunately, the problem was related only to Lazarus LCL support – all other functionality worked fine.
After not so straightforward installation of Mac OS X in VMWare I fixed the issue just by changing number “24” to “32” in the code (TRawImage.Description.Depth field, LCL raw image to TBitmap conversion). Apparently, Carbon created bitmap with 6 bits per color channel. Now I just need to check if 24->32 change doesn’t break anything when using other LCL widget sets (I’m sure there was a reason for 24bits since I vaguely remember 32bits were there few years ago) – so maybe conditional compilation will be needed here.
Another issue I noticed is that LCL Imager demo couldn’t load default image (Tigers.jpg) that is displayed when it is started without parameters. Demo uses relative path to the image but (from Demos/Bin to Demos/Data directory). Mac OS X application LCLImager.app is placed in Demos/Bin directory by Lazarus but it is not a simple single file. It’s a directory itself and actual demo executable is located somewhere inside. I’ve not really decided on solution yet. Maybe embed the image in the executable as resource?
See the difference?
My Vampyre Imaging Library was updated to version 0.26.2 few days ago. This was mostly fix/patch/update release with no significant new features.
I decided to remove Kylix support (CLX graphic classes, project files, build scripts, core library still compiles). It’s not working properly on many (all?) current Linux distros (so I can’t test) and it was abandoned by Borland/Codegear quite some time ago. It was nice to have DCC compiler in Linux and it also made Borland to make Delphi RTL crossplatform. There are rumors about crosscompiling features in upcoming Delphi releases (in 2010?) so maybe we’ll see DCC in Linux again.
Instead of Kylix project files there are new ones for Delphi 2009. Imaging itself didn’t require many fixes to compile and work with Delphi 2009, most of them were related to text-based file format loaders (XMP, PNM) and external libraries (JpegLib, ZLib).
More info and downloads at Imaging’s homepage.