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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
