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