New version of Imaging was released few hours ago.
As stated before it is patch and update release with no
important new features added.

News/changes in 0.24.2:
  - Updated OpenJPEG (JPEG 2000) library to latest revision and added JPEG 2000 support for 64bit Linux.
  - Fixed compatibility issues with new Lazarus 0.9.24 and added project files for RAD Studio 2007.
  - Updated LCL Imager demo and added new features to OpenGL texture builder.
  - Bug fixes in JPEG and GIF support.
  - Pascal translation of Hq resampler with Imaging demo added to Extras directory.

Head to Imaging Homepage for downloads and updated documentation.

The official response from OpenJpeg team regarding color definition was:
"this is not planned in the near future... but contributions are welcome!"
So I will probably implement it in OpenJpeg myself when I have some time
but it won't be ready for Imaging 0.24.2 (which will be released today around midnight).

1) Currently only multiplies of 90 degrees rotations are supported.
2) No collision detection, thats really out of scope of Imaging.

It is a pointer so that it can support all image data formats - it should point to actual pixel color in the same format as the image.
For A8R8G8B8 format the filling code would look like this:

var
  Color: TColor32Rec;
begin
  ....
  Color.A := 0;
  Color.R := 192;
  Color.G := 128;
  Color.B :=  64;
  FillRect(Pow2Sprite.ImageDataPointer^, 0, 0, Pow2Sprite.Width, Pow2Sprite.Height, @Color);   
  ....


If you use the new PasteNonPow2ImagesIntoPow2 option it will use pixel color at [0, 0] fill to fill the whole image (like the green color in jdarling's post). So if that is transparent the extra region will be transparent too.
If you want some custom color you can use the approach shown in the code few posts above. Just fill entire Pow2Sprite image with your color.

Some sort of SVG support can be done (loading only since Imaging is raster image library).
It could use new canvas to draw shapes defined in SVG xml files (nothing too fancy though).

Yes, there was a problem with GIF background color transparency settings.
It is fixed now, new code is in SVN repository.

Also you don't need to set image format before loading (like in your code example).
Whole image (size, format, etc.) is thrown away during loading.

Quote from: jdarling on  5 October 2007, 22:27:31
My other request would be getting transparency working when blitting :(. 

Quote from: sofakng on 27 November 2007, 16:20:58
I'd really like it to support alpha blending...

Thats on my list already (for quite a long time I might add). I plan to implement
various source and destination blending functions (just like in D3D/OGL).
Problem with this is that it won't be very fast - so I also plan to add
optimized versions of some most used blending operations (like alpha and additive blend)
but only for some image data formats.

As I wrote before Imaging's PSD loader doesn't read layer information which is how transparency is stored in your image. You need to get your transparency into alpha channel (and set image mode from CMYK to RGB as Imaging currently doesn't read alpha channel of CMYK images).

How I made attached Imaging compatible transparent PSD from your image:
1. 'Merge Visible' the two image layers
2. 'Select Layer Transparency' on merged layer
3. Set 'Image->Mode' to RGB
4. 'Save selection as channel' which created alpha channel with proper transparency
5. Finally save the file

Complicated, but at least both PSD layers and native CMYK data formats will be supported in
upcoming Imaging 0.3x.

Could you please upload it as attachment on the forum? I have problems
downloading it from rapidshare.

I'm waiting with the 0.24.2 release for new OpenJPEG major version 1.3 which should be released this week or the next one. After that it will take me few days to put the release together and test it.

Could you post some non working image here please?
PSD loader only reads raster data, no layers, objects, etc.
Transparency stored in alpha channel works ok (tested with CS2).

Lararus 0.9.24 is finally out so the new RawImage API is now used as default by Imaging.

Looks like there is a problem with OpenJPEG (3rd party library that Imaging uses to load/save JPEG2000 images). It doesn't save color definition info in the file. That's no a problem if image has one or three (standard RGB) color channels, but four channel images (like the one you had problem with - doesn't matter if it is saved as lossy or lossless) are not loaded correctly by some (most) software.

I'm now adopting new version of OpenJPEG for Imaging 0.24.2. I'll let you know if it works with this one. 

That would be great  ;)
I've just added hq2x to Extras directory (SVN) and build a new demo.