Free Lossless Image Format (FLIF)


I've been checking on JPEG-XL every now and then. Hard to add it to browsers if the bitstream isn't finalized yet, to be fair.
It's just not ready yet.
 
That link doesn't work for me; I assume it's pointing here:
Code: 
https://news.slashdot.org/story/20/07/09/202235/chrome-and-firefox-are-getting-support-for-the-new-avif-image-format
According to that AVIF is getting support from the big web browsers, but JPEGXL is still the next format from the JPEG foundation. Whether that will be enough for it to get better support than FLIF ever had remains to be seen though. The browsers can still add it later on, but perhaps that's looking less likely; AVIF got added after only being drafted for a little over a year. JPEGXL doesn't seem to be quite that old yet though.
 
Hi everyone, long time no see :)

JPEG XL reached version 0.1 recently. This is the "format release candidate" version; if all goes well we will soon proceed to version 0.2 which will be the "format release", i.e. bitstream stable enough to guarantee that encoded jxl files remain decodable.

It will be an interesting battle of the codecs in 2021. WebP just got universal browser adoption. AVIF is in Chrome and is coming in Firefox. WebP 2 is coming. Apple supports HEIC. And then there's JPEG XL.

Out of all the new image codecs, only JPEG XL was actually designed as an image codec. The others are all based on single-frame video. I do think that JPEG XL has technical advantages over the other codecs, see e.g. https://cloudinary.com/blog/how_jpeg_xl_compares_to_other_image_codecs

JPEG XL has become a powerful combination of a FLIF/FUIF-derived codec and a PIK-derived codec, combining the advantages of both approaches as much as possible and adding some good new stuff on top of it.

For some more info: here's a slide deck on jxl: https://docs.google.com/presentation/d/1LlmUR0Uoh4dgT3DjanLjhlXrk_5W2nJBDqDAMbhe8v8/edit?usp=sharing
 
@_wb_

You stay gone for a while, and come back in better resolution :)

Is it Is it .jxl or .jpgxl by default? Is there any hope of getting onto cameras retroactively provided there is enough openness?

Some spellery
Slide 25 should be "OK".
Slide 30 should be ellipsis "…"
Slide 35 "to encode" → "encoding"
Slide 36 comma before "but"
Slide 37, comma before "or"
Slide 39 should be "encoding"?
Slide 40 "FLIF, and lossless WebP"
Slide 41 Should be "and"
Slide 42 Comma before "but"
Slide 44 "decoding"?
 
Does jpegXL support animation natively? If it's just a new image format that has implications for the archival of images, but videos are a bigger deal on the internet these days.

Edit: The linked blog post about jpegXL talks all about legacy applications for PNGs and JPEGS, and only mentions video codecs as being a bad way to derive a static image format from.
 
Last edited:
levi said:
Does jpegXL support animation natively? If it's just a new image format that has implications for the archival of images, but videos are a bigger deal on the internet these days.

Edit: The linked blog post about jpegXL talks all about legacy applications for PNGs and JPEGS, and only mentions video codecs as being a bad way to derive a static image format from.
Click to expand...

JPEG XL does support animation, but it's not a video codec: it does not have inter frames with motion estimation and all the complications and patent minefields that that brings. If you want well-compressed video, it's better to use a video codec.
Post automatically merged:

Silent-Hunter said:
Yeah but is that official? Or just someone claiming it?
Click to expand...

All the good stuff from FLIF went into JPEG XL. In lossless compression, jxl is slightly better than FLIF, while it decodes faster. I stopped working on FLIF and I think JPEG XL can do everything FLIF can do and more.
 
Well there is this notice here. The FLIF code hasn't gone anywhere yet though, so you're still free to use it, but going forward experience has shown that if you find a bug in it, you won't get much support other than fixing it yourself. The active project _wb_ is mostly involved in these days is jpegXL. If you're looking to work with other people, waiting for the v0.2 drop then using jpegXL is probably the way to go, but until then flif or maybe fuif is a more stable project still.

Edit: Ninja'ed by the man himself in the main.
 
Last edited:
Okay, well is JPEG XL finished? Right now I can convert things to .flif with ImageMagick.
 
comradekingu said:
@_wb_

You stay gone for a while, and come back in better resolution :)

Is it Is it .jxl or .jpgxl by default? Is there any hope of getting onto cameras retroactively provided there is enough openness?

Some spellery
Slide 25 should be "OK".
Slide 30 should be ellipsis "…"
Slide 35 "to encode" → "encoding"
Slide 36 comma before "but"
Slide 37, comma before "or"
Slide 39 should be "encoding"?
Slide 40 "FLIF, and lossless WebP"
Slide 41 Should be "and"
Slide 42 Comma before "but"
Slide 44 "decoding"?
Click to expand...

Thanks for the suggestions!

It is .jxl, the encoder is called cjxl, the decoder is djxl, and the media type is image/jxl.

I usually pronounce it jay-ex-ell, but it would be nice to pronounce it "yixel", since that rhymes with pixel.

Post automatically merged:

Silent-Hunter said:
Okay, well is JPEG XL finished? Right now I can convert things to .flif with ImageMagick.
Click to expand...

At version 0.2 we can do a delegate encoder/decoder in ImageMagick, at version 0.3 we can do a libjxl integration.

In a few months, I hope jxl will have better tooling support than flif.
 
Thank you! I would like to be able to use it. And thanks for developing these. I like FLIF, and I hope you're right about JPEG XL being just as good.
 
That doesn't really tell you anything you don't already know if you've already read that blog post. But perhaps some people prefer people talking in their ears compared to reading a blog.

But looking at other sources, it seems v0.2 of this dropped just in time for Christmas! That means you've discrete cjxl and djxl in the release now, and it should remain compatible with v0.3 if not for longer. I don't know if this in integrated into imagemagick yet though.
 
And 0.3 dropped ten days ago or maybe a little more. It's now part of imagemagick.

_wb_ also pushed a new video to youtube. It reports to be about showing the variable DCT block size selection. All I really know is that towards the end you can see the image on the right degrade and there's a certain correlation to the image on the left.

 
Hey does anyone know if JPEG XL can do that thing where you partly load a picture to get a lower resolution version? That's one of the coolest features from FLIF.
 
Silent-Hunter said:
Hey does anyone know if JPEG XL can do that thing where you partly load a picture to get a lower resolution version? That's one of the coolest features from FLIF.
Click to expand...
Yes, of course :)

It is called "progressive coding", and it's in the specs:

JPEG - JPEG XL

jpeg.org jpeg.org
What is "progressive coding"?
encyclopedia2.thefreedictionary.com

progressive coding

Encyclopedia article about progressive coding by The Free Dictionary
encyclopedia2.thefreedictionary.com encyclopedia2.thefreedictionary.com

See the first image of the whitepaper:


Or look at this, where the JXL is displayed after the first 60 kb, but keeps enhancing itself when it gets more data (611kb):

Or... let the man explain it himself:
 
Last edited:
You must log in or register to reply here.
Back
Top