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