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

Marco van de Voort marcov at stack.nl
Fri Dec 9 12:39:54 CET 2016


In our previous episode, Michael Van Canneyt said:
> >> Why FPImage uses 64bit per pixel is beyond me! The original author of
> >> FPImage clearly thought he/she saw something cool in that, but 99.99999%
> >> of the time *nobody* needs that. It's causing more grief (and code to do
> >> conversions) than anything else.
> >
> > 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.

I never got the one size to rule them all mentality. 

I understand that code for more complex code like advanced filters won't be
written for various bitsizes and subformats.  But run of the mills
usage IMHO should be in the format closer to both disk and display.

Simple Load,save,display of 24 and 32-bit RGBA are the bulk of the cases,
with about 5 common storage permutations, some of which are not even supported by
many programs. (but are by e.g. OpenGL)

That said, for production I use own fcl-image derived png and bmp loaders
for various performance and memory layout reasons for a decade, (industrial
cameras can't seem to store 64-bit pixeldata) and I haven't researched recent
fcl-image developments. 

Are there still no ways around the 64-bit storage format? I thought
TLazintfImage was meant to be a step in that direction?


More information about the fpc-pascal mailing list