Hey guys,
some years ago I stumbled across the FLIF-format, which might be very interesting for wikimedia commons and/or Mediawiki in general.
I try to summon the fileformat and it's advantages a bit:
It's a free, patent free, lossless image compression format, which supports RGB(A) / greyscale images as well as palette-images.
FLIF also supports animations and 16 bit/channel color-deph for still images as well as animations. embedded ICC color profiles, Exif and XMP metadata are supported. They started to work on RGGB-raw-file-support, but this is not fully implemented right now.
There's a small JavaScript library which can be used until there's a browser support given, so theres no need to wait until there is browser-support.
A small portion of a FLIF file, can be decoded as well (progressive decoding).
For thumbnails we can simply load a 5-10% portion of a multi-mb file and show this as a thumbnail. If a user want a larger view, later, we just fetch some additional data to the already saved one, removing the need to fully download the same 'data' again.
It's also great for resposive designs, where the user might rotate his device and know need a 50% larger resolution of the same file.
If the user click on that image, to get a fullscreen popup we can also use the thumbnail-data and just fetch some additional KB to fullfil this requirement of a larger resolution.
Also the browser might start rendering with a 1% portion of the file, and show a low quality image. When some more percent are downloaded, the browser can update the low quality image with a larger one.
###
My idea was, to convert all new uploads to FLIF at the time we receive those files. So JPGs get a lot larger, GIF and PNG some KB smaller, but the most interesting advantage is: we do not get any generation-loss anymore:
If someone upload a JPG-file, we save it to FLIF. If someone want to edit the file again, he need to download the FLIF and read it nativly with an application or download it as PNG and upload the edited file again as PNG. We then simply convert it back to FLIF for storage.
###
There's also an advantage for the caching proxies, they does not need to handle image files in various sizes, which should simplify the overhead, because we use just one filename and url for all views on that file.
###
I hope I found the right place to discuss this topic, have a nice weekend! :)
Best regards
Ruben