[fpc-pascal] FPImage and mult-page TIFF support

[Michael Van Canneyt]

On Fri, 9 Dec 2016, Graeme Geldenhuys wrote:

> On 2016-12-09 07:28, Michael Van Canneyt wrote:
>>>> The 64bit is the maximum limit. I doubt the 99.99999%. Image editing
>>>> require more than 8bit per channel since decades.
>> And that is why we decided to use 64-bit.
>
> Sorry, maybe I'm getting confused with the meaning of all than. What I'm
> saying is that FPImage uses 16bit color channels, but literally only a
> hand full (and I mean less than 5) of image editing programs support
> 16bit color channel images. Most image viewers can't even display those
> either. eg: The most widely used image editing software for X11 based
> systems, The GIMP, doesn't even support 16bit color channel images. Yet
> everybody supports the defacto standard 8bits per channel images. So
> every time anybody works with FPImage, we have to do constant
> 16bit-to-8bit color translations.  Where has the decision to default to
> 16bits per color channels come in useful in the history of FPImage?

The desire was to be able to support all possible channels when reading a file. 
That means 16bit. That you don't use this feature in X% of cases was irrelevant.

If we had decided to use 8 bit, then one day someone would come along with a
16bit channel file and we'd have to say "sorry, we don't support that", or
read/write it with loss of information.

It's obviously possible to question this decision, but it was taken more than 10 years
ago. A bit late to change our minds now...

Note that you don't need to store the image with full 64 bits per pixel.
You can perfectly store an image with 1 bit (i.e. black/white) per pixel.
But the API uses 16 bits per channel.

Michael.