Actually, now that it's got lossy support built in, it actually seems to be not to bad for storing photos. I just processed all of the photos off my old 10MP camera into flif via PNG format using the -lossy 50 argument, and comparing the original JPEGs to restored PNGs out of the FLIF files showed that only a little colour resolution was lost I think. The sea lost a few turquoise highlights, while trees appeared slightly more green, but all shapes were maintained, and skintones were all good, and all of that in a file less than a quarter of the size of my original JPEGs! If I weren't comparing them at 1:1 resolution side by side, I probably wouldn't notice any changes.
I couldn't get flifview to run on my machine fwiw. It complained about a missing so.0 file, but that file had been previously installed via make install. Setting my LD_LIBRARY_PATH (which seemed to be unset, to my surprise) didn't help either.
Thanks! I'd already tried gdb and clang's static analyser, but both managed to skip over what I wanted.
It seems the path to libflif.so.0 is hardcoded to be /usr/lib. The install target of the makefiles put it in /usr/local/lib, so viewflif will fail if built and installed from git source. I'll raise an issue, I think.
Edit: Seems it's an Arch issue. The trick is to use the flif from AUR, not build it yourself from the makefiles it seems.
Yup, that's him!
[doublepost=1566339504,1566324221][/doublepost]The real question now is how much of FLIF is in JPEG-XL ? And can it stand on it's own, as a format, in a hostile world (where other formats reign).
I'd expect everything learned during the devlopement of FLIF went into JPEG-XL, therefore almost everything in FLIF made it through. Maybe some things that were in FLIF turned out to be suboptimal in practice and were therefore dropped for JPEG-XL, but otherwise I'd expect JPEG-XL to be a direct development on top of FLIF.
Yes, I also tried converting some of my JPEGs to FLIF. They came back rather a lot bigger, but that's unsurprising as FLIF had to encode all of the JPEG artifacts losslessly as well as the actual image data. I then found that I could crop the end of the file to a fraction of the size of the original JPEG and still get perfectly usable images out of it. I never spent enough time to figure out how much to actually cut them to store them though, and storing an already lossy JPEG as a cropped FLIF felt doubly lossy to me. If I could actually process my camera RAW files into GIMP out to a flif file, I'd be happier cropping that and saving that, but as far as I can see GIMP still doesn't support FLIF. I don't really want to have to go via a mahoosive PNG if I can avoid it.
Seems to me that FLIF for us was effectively a preview of JPEG-XL for us, and it's unlikely to be improved on from now on. JPEG-XL meets the requirements set by the Joint Photographic Experts Group, so I'd expect to have better tools support.
The main thing stopping me from using FLIF was less the overall support, but rather the lack of highly optimized tools. Viewing bigger collections of high-res images was kind of tedious with the load times, let alone the initial conversion process. The bigger backing could hopefully change this. I know that kind of compression doesn't come without computational complexity, but still.