TIFF tags writer was update long ago,
but it probably won't work in MS Doc Imaging
anyway due to the bug in MS Doc described previously.

Thanks for the contribution, will be included for the next release :)

Hello,

Did this work before you downloaded "working"?

Could you try ifA8R8G8B8 instead of ifA32R32G32B32F in the conversion?

What file formats have you loaded from/saved to?

Thanks for the report, working versions are not always tested in all Delphi versions :(
I'll update the repository with a fix in a short while.

You can get print resolution from JPEGs (provided that this info is embedded inside) using metadata framework.
It's not stored in image itself so you need to keep track of it if you want to later save the values that were loaded.

type
  // defined in Imaging.pas
  TResolutionUnit = (
    ruSizeInMicroMeters, // value is pixel size in micrometers
    ruDpi,               // value is pixels/dots per inch
    ruDpm,               // value is pixels/dots per meter
    ruDpcm               // value is pixels/dots per centimeter
  );

var
  XRes, YRes: Single;
  ResUnit: TResolutionUnit;

... load image ...

ResUnit := ruDpi;
if GlobalMetadata.GetPhysicalPixelSize(ResUnit, XRes, YRes) then
begin
  ... print resolution present, do something with it
end;

... do something with image
GlobalMetadata.SetPhysicalPixelSize(ResUnit, XRes, YRes, True)
... save image

Checkout TMetadata class in Imaging.pas for implementation details.

Hi, sorry for late answer.

There are two problems with your code:

1) Your setting Palette variable to point to the address of ImageData.Palette field, not to the actual
palette info. Correct way is this:
//Palette := @ImageData.Palette;  wrong
Palette := ImageData.Palette; // ok
Palette := @ImageData.Palette[0]; // also ok, if ImageData.Palette <> nil

2) When you fix the palette pointer problem you'll notice you get 'Access violation' exception now. That's because
ImageData.Palette = nil. ReduceColors keeps the image in its original data format and doesn't convert it to indexed (that's because ReduceColors supports color counts up to 4096 for which there is no indexed format).
In short, you need to convert to indexed format explicitly by adding ConvertImage call after ReduceColors:
ReduceColors(ImageData, NumberOfColors);
ConvertImage(ImageData, ifIndex8); // added
Palette := ImageData.Palette;

Now the colors are counted correctly.

Thanks for the link to test images.
HDR loading in Imaging is working now, I'll test it with few more exotic images and update the repository.
Saving will be done a little later.
HDR can store gamma and exposure value in the file, these are read by Imaging as well and accessible
trough the new metadata support class (though any of the PhotoShop HDRs doesn't have this defined).

Hi, XE2 support is already done and uploaded to repository.
What's currently supported: Win64 target compatibility, OSX target compatibility, FireMonkey bitmap converter.

Here's page where the link points to: http://sourceforge.net/donate/index.php?group_id=125626  :)

Ok I'll let you know when HDR/RGBE file format support is ready.
What software do you use for working with HDR imagery?

You can find a link to donations at Imaging's homepage http://imaginglib.sourceforge.net/ (in right column). Thanks!

Hi, I thought of supporting OpenEXR several years ago but it seems nearly impossible: it's quite complex format and only thing that supports it
completely is OpenEXR library from ILM. Library is too big to translate it to Pascal and since it's interface is in C++ it cannot even be linked to
Pascal program (libraries in plain C can be used quite easily). One solution would be to write DLL in C++/C that will provide simple interface for Imaging.

HalfFloat image formats have been supported by Imaging for several years (if you look in ImagingFormats.pas you'll find this exact FloatToHalf
function there  ;)).

Formats that currently support floating point images in Imaging apart from Delphi only TIFF are DDS, PFM/PAM, and PSD (I'll be adding HDR/RGBE format) .

This is the difference between VCL demo and LCL demo - the conversion has both R8G8B8 and A8R8G8B8 images in the memory at the same time. VCL demo only converts images incompatible with canvas class so for R8G8B8 input no conversion is needed - thus it uses nearly half the memory of LCL demo.
In VampConvert if you just resave to another format no conversion is needed so again it's half the memory usage of LCL imager.

Determining the memory limit is not so easy, even if you have 1GB free and try to allocate 500MB it can still fail due to memory
fragmenation.

Imaging can work with these large images provided that you have a lot of RAM and use 64 bit compiler. I just tried loading 20000x20000 R8G8B8 image and it opened ok in VCL demo. Memory mapping and using tiled images would work (probably what Photoshop itself uses when working with these large images) when the memory needed to hold the images is bigger than installed RAM but that's quite a lot of work.

How much RAM does your computer have installed?
This image should take up ~300MB of memory.
Since it works in Delphi app maybe it's some problem with memory manager used by FPC
(cannot allocate continuous mem block of that size).

Could you try saving that image in some other file format and try to open it in LCLImager? To see
if this problem is tied to PSD loader or the whole LCL/FPC app.

Hi, yes it's still updated, but the progress is slower than it used to be.
Right now I'm making compatibility changes in Imaging for new Delphi (to target Win64 and MacOSX  ;))