Free Lossless Image Format (FLIF)


yeah, as _wb_ mentioned to me earlier in this thread, don't use a lossless format to encode a lossy file (e.g. jpg)...
 
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.
 
Last edited:
[BUMP]
Hi all,

@_wb_ : are you involved in this one ?
Code: 
https://jpeg.org/jpegxl/
https://www.slideshare.net/cloudinarymarketing/imagecon-2019-jon-sneyer

Cheers, Magic Sam
[/BUMP]
 

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.
 
So are both formats going to be maintained? I was hoping to use FLIF for my photos when it is finished. Should I use JPEG XL instead? Also I see a third one now, FUIF!

I remember using FLIF for a bit for some images as a test and it worked quite well I thought.
 
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.
 
elvissteinjr said:
was kind of tedious with the load times,
Click to expand...
I hope intelligent image viewers will come out, that know to stop reading at 1/3 of the file because I only have SVGA resolution and the image is 4K.
 
Here's the first public drop of prototype code for JPEG-XL.

gitlab.com

JPEG / JPEG XL Reference Software · GitLab

JPEG XL image format reference implementation. Mirror from https://github.com/libjxl/libjxl, info on latest releases there!
gitlab.com gitlab.com

I'm currently building it (via the AUR recipe on Arch) so we'll see how it goes.

Edit: Nope, It's spit out some libraries and a lot of test scripts, but it failed to build fully even after disabling AVR2 as per the instructions in the readme. It hasn't spit out cjpegxl for example.
 
Last edited:
i'm also having trouble building, but i at least got cmake to work. seems like i don't have a JPEGXL_VERSION defined somewhere, so it's complaining.

Code: 
Scanning dependencies of target cjpegxltool
[ 75%] Building CXX object tools/CMakeFiles/cjpegxltool.dir/cjpegxl.cc.o
/home/$USER/code/jpeg-xl/tools/cjpegxl.cc:118:42: error: expected ')'
    fprintf(stderr, "cjpegxl - version " JPEGXL_VERSION "\n");
                                         ^
/home/$USER/code/jpeg-xl/tools/cjpegxl.cc:118:12: note: to match this '('
    fprintf(stderr, "cjpegxl - version " JPEGXL_VERSION "\n");
           ^
/home/$USER/code/jpeg-xl/tools/cjpegxl.cc:126:55: error: expected ')'
            "            /\\ |_   e n c o d e r    [" JPEGXL_VERSION "]\n\n");
                                                      ^
/home/$USER/code/jpeg-xl/tools/cjpegxl.cc:125:12: note: to match this '('
    fprintf(stderr,
           ^
2 errors generated.
make[2]: *** [tools/CMakeFiles/cjpegxltool.dir/build.make:63: tools/CMakeFiles/cjpegxltool.dir/cjpegxl.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:5844: tools/CMakeFiles/cjpegxltool.dir/all] Error 2
 
I don't think that's actually complaining about the JPEGXL_VERSION, it's complaining about the second argument to fprintf being a series of space separated strings. I don't even know what that's meant to do. As it says, after the first term it expects a close bracket.

I think my problems are more to so with the vintage of the machine I'm trying to build it on, a 2008 vintage core 1 system, which is still perfectly fast enough for me running linux. But that tops out at SSSE3 and don't do SSE4 let alone AVR.
 
@ible I know it is inside a make file and I think the initial thought was for the variable to be replaced by the value, like in a template, however it is not doing that, it is defining the variable as if a define.
So fprintf wants: fprintf(file, template, variable,variable,...), so it looks like in cjpegxl.cc the

fprintf(stderr, "cjpegxl - version " JPEGXL_VERSION "\n");
needs to be rewritten as:
fprintf(stderr, "cjpegxl - version %s \n", JPEGXL_VERSION);
or if all fails, as:
fprintf(stderr, "cjpegxl - version CUSTOM_IBLE \n");


edit: Reading https://gitlab.com/wg1/jpeg-xl/-/blob/master/tools/cjpegxl.cc
The JPEGXL_VERSION is a variable at make time, and is used in cjpegxl.cc and djpegxl_main.cc
The variable JPEGXL_VERSION is given at compilation time through a -D parameter, as we see from:

Code: 
fbnil@vm1:~/CODE/C/jpeg-xl-master$ find . -type f -exec grep JPEGXL_VERSION {} /dev/null \; |grep =       
./build/CMakeCache.txt:CMAKE_CXX_FLAGS:UNINITIALIZED=  -DJPEGXL_VERSION=\"\" -DJXL_DEBUG_WARNING -DJXL_DEBUG_ON_ERROR
./build/CMakeCache.txt:CMAKE_C_FLAGS:UNINITIALIZED=  -DJPEGXL_VERSION=\"\"
./ci.sh:JPEGXL_VERSION=${JPEGXL_VERSION:-${CI_COMMIT_SHA:0:8}}
./ci.sh:CMAKE_FLAGS="${CMAKE_FLAGS:-} -DJPEGXL_VERSION=\\\"${JPEGXL_VERSION}\\\""


EDIT: added the concatenated form:

A short demo of that #DEFINE is:

fbnil@vm1:~/CODE/C$ gcc -D'JPEGXL_VERSION="1.44kb"' test.c ; ./a.out
cjpegxl - version 1.44kb
cjpegxl - version 1.44kb

can also be called with escaped quotes (as the ci.sh has):
fbnil@vm1:~/CODE/C$ g++ -DJPEGXL_VERSION=\"1.44kb\" concat.c && ./a.out

code snippet for test.c:
C: 
#include <stdio.h>

int main(void){
  fprintf(stderr, "cjpegxl - version %s\n", JPEGXL_VERSION);
  fprintf(stderr, "cjpegxl - version " JPEGXL_VERSION "\n");
  return 0;
}

works with gcc and g++ (C and C++).

knowledge source: http://addisu.taddese.com/blog/inserting-svn-revision-number-in-your-cc-code/
 
Last edited:
i imagine JPEGXL_VERSION is supposed to be a macro (#define JPEGXL_VERSION "12.345"), in which case the space-separated strings would just automatically concatenate at compile time. but i shouldn't have to muck around with the source.

fprintf doesn't need formatting arguments, if it's just a string.

seems like cmake should be defining JPEGXL_VERSION as some string, based on a quick grep...
Code: 
~/code/jpeg-xl$ grep JPEGXL_VERSION *
ci.sh:JPEGXL_VERSION=${JPEGXL_VERSION:-${CI_COMMIT_SHA:0:8}}
ci.sh:echo "Version: $JPEGXL_VERSION"
ci.sh:CMAKE_FLAGS="${CMAKE_FLAGS:-} -DJPEGXL_VERSION=\\\"${JPEGXL_VERSION}\\\""

[edit]ahh, maybe i'm supposed to be using the ci.sh to compile things. i assumed it would be a `mkdir build; cd build && cmake ..` idea. i'll try again a bit later...
 
Yes, the website lists debian building instructions if you don't want to use docker, but that seems to be behind a login wall so I couldn't view it for you.

Edit: I can confirm all of your previous findings. My copy of the cjpegxl source contains the same odd-looking line, and JPEGXL_VERSION is defined in ci.sh. My AUR pkgbuild doesn't call ci.sh directly though, it invokes cmake with options -B build and -S jpeg-xl then make with -C build and test. I've limited experience with cmake though, so I don't know exactly what any of that does.
 
Last edited:
@levi although the README.md says "doc/building_in_debian.md", maybe that file is actually "./doc/developing_in_debian.md" ? Also: edited previous post to add the auto-concatenate-at-compile in the example.
@ible I did the same before I read the README, but then ran the ci.sh and my tools are too old :( (will have to look into the mechanics of PortableAnsible that has a make that actually builds a docker from scratch to build there)
 
looks like i got it to build (after deleting my old attempt's build dir). not sure what i'm doing with it at this point, though!
 
Awww... AVIF got chosen over JPEG-XL :(

Alterslash archive for 2020-Jul-09

Alterslash picks the best 5 comments from each of the day’s Slashdot stories, and presents them on a single page for easy reading.
alterslash.org

edit: Fixed the URL, thanks @levi
 
Last edited:
You must log in or register to reply here.
Back
Top