10 ms·

Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. Likely the

by jjcm 7y ago

Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF. Since it's based on AV1, you'd get hardware acceleration for decoding/encoding once it starts becoming a standard, and browser support will be trivial to add once AV1 has wide support. Compression wise AVIF is performing at about the same level as FLIF (15-25% better than webp, depending on the image), and is also royalty free. The leg it has upon FLIF is the Alliance for Open Media[1] is behind it, which is a consortium of companies including: "Amazon, Apple, ARM, Cisco, Facebook, Google, IBM, Intel Corporation, Microsoft, Mozilla, Netflix, Nvidia, Samsung Electronics and Tencent." I'm really excited for it and I hope it actually gets traction. It'd be lovely to have photos / screenshots / gifs all able to share a common format. [1] https://en.wikipedia.org/wiki/Alliance_for_Open_Media https://en.wikipedia.org/wiki/Alliance_for_Open_Media

BurningCycles 7y ago
>Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF I used to think the same as well, however I now think Jpeg XL is poised to be the 'winner' among next gen image codecs. It's royalty free, great lossy and lossless compression which is said to beat the competition, as well as providing a perfect upgrade path for existing jpeg's as it can losslessly recompress them into the jpeg XL format with a ~20% size decrease (courtesy of the PIK project). It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.
- mceachen 7y ago
  Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? (Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
  - BurningCycles 7y ago
    >Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? Well, it's not finalized as of yet (though it is imminent), so rate of adoption is just pure guesswork at this stage. However, things I deem necessary for a new image codec to become the next 'de facto' standard are: royalty free major improvements over the current de facto standards Both AVIF and Jpeg XL tick these boxes, however Jpeg XL has another strong feature which is that it offers a lossless upgrade path for existing jpeg's with significantly improved compression as a bonus.
    - rjvs 7y ago
      So you're suggesting that the advantage JPEG XL has is that it will compress existing JPEGs better than FLIF or AVIF?
      - lukevp 7y ago
        Sounds like it will just take an existing JPEG and reduce the size, but not re-compress it - so even though the original JPEG is lossy, there will be no additional loss introduced, whereas another format not based on JPEG would require a re-encode pass that would lose additional information.
      - BurningCycles 7y ago
        Yes, it losslessly recompresses existing jpeg's into the jpeg XL format, while also making the files ~20% smaller, key point being lossless. Thus it is the 'perfect' upgrade path from jpeg which is the current lossy standard, as you will get better compression and no loss in quality when shifting to Jpeg XL. This being a 'killer feature' of course relies on Jpeg XL being very competitive with AVIF in terms of lossy/lossless compression overall.
        setr 7y ago
        I'm assuming this is bidirectional? You can go back from XL to jpeg losslessly as well? If thats the case, I'm having trouble imagining a scenario where you're not correct; it'd be an utterly painless upgrade path
- modeless 7y ago
  Does it have the feature where the file can be truncated to any size to form its own thumbnail? That would be an incredibly useful feature in so many applications.
  - Scaevolus 7y ago
    It has a progressive mode, but not as aggressive of one as FLIF.
  - ralusek 7y ago
    Surely not any size. It'd have to be squares or something for that to make any sense, right?
    - Dylan16807 7y ago
      Some amount of data at the end of the file won't be usable, but it's easy to make a format that's resilient to you chopping anywhere.
    - someguyorother 7y ago
      Some wavelet formats (SPIHT and EZW e.g) have the property that truncating the lossless version at 10% of the size gives you the 10:1 lossy rendering of that picture. That property holds not just for 10% but for any fraction of the file. It's not quite the same thing, but a very highly compressed high-res picture would probably look okay in thumbnail format.
- edflsafoiewq 7y ago
  It sounds interesting, although my initial impression is that it sound like it will suffer from the same daunting complexity that afflicted JPEG 2000.
  - janwas 7y ago
    Good news: the reference software (http://gitlab.com/wg1/jpeg-xl http://gitlab.com/wg1/jpeg-xl) can decode about 50 Megapixels/s on a single Skylake core, with 3.1-3.7x speedup on 4 cores. Encoding throughput is configurable from ~1 MP/s to about 50 per core. That's somewhat slower than JPEG, but can be faster with multiple cores.
- marton78 7y ago
  JPEG XL is a terrible name for something that claims to produce extra small results.
  - jonsneyers 7y ago
    It may not be the best name, but it sure is better than the names of the projects it was based on: PIK and FUIF. At least if you speak Dutch. A "pik" is a penis and a "fuif" is a party, so the combination would be the "penis party" image codec. I prefer "JPEG XL". The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.
    - stingraycharles 7y ago
      There might be an explanation around it, but I find it not much better than Apple with their iPhone XS. I agree that XL is a bad name, and I don’t think that “pik fuif” would matter a lot (I’m also Dutch). Could have been e.g. JPEG PF or JPEG LTS.
  - l8rlump 7y ago
    PIK project is also a terrible name for people who understand Danish.
- gardaani 7y ago
  I hope that JPEG XL will be simpler than the competitors. If it's compression ratio is similar to AVIF and it can do HDR, then I'll all for it! AVIF (and its image sequences) seems to be fairly complicated. Here's few comments [1] about it: "Given all that I'm also beginning to understand why some folks want something simpler like webp2 :)" "Despite authoring libavif (library, not the standard) and being a big fan of the AV1 codec, I do occasionally find HEIF/AVIF as a format to be a bit "it can do anything!", which is likely to lead to huge or fragmented/incomplete implementations." Anyway, instead of adding FLIF, AVIF, BPG, and lots of similar image formats to web browsers, I think only one good format is enough and JPEG XR might be it. After something has been added to web browsers, it can't be removed. Safari hasn't added support for WebP (which is good, there's no need for WebP after AVIF/JPEG XR is out) and it hasn't added support for HEIF (which is weird, considering Apple is using it on iOS), but maybe they know that there's no need to rush. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=960620#c33 https://bugs.chromium.org/p/chromium/issues/detail?id=960620...
  - jhabdas 7y ago
    Browsers don't need the codecs anyway. They just need Wasm and a decoder. Clients can do the work[1] until the hardware supports the goods. [1] https://git.habd.as/comfusion/fractal-forest/src/branch/master/Dockerfile https://git.habd.as/comfusion/fractal-forest/src/branch/mast...
    - bscphil 7y ago
      The example you linked to is pretty telling, because not only do the BPG images decode more slowly than natively supported images, the javascript decoding approach apparently breaks the browser's (Firefox's) color management. I think native support is needed for newer codecs to be viable for more than simple demos.
      - spider-mario 7y ago
        Chrome appears to interpret the canvas as sRGB and to convert from that, but that means that images decoded that way are effectively limited to sRGB until the canvas API allows specifying other colorspaces.
shotashota 7y ago
the article briefly mentions that its based on a decision tree. Does that it mean it doesn't parallelize well? Or does this fact not matter much?
- jonsneyers 7y ago
  FLIF doesn't parallelize well, but that's not really because of the MA trees, but just because the whole bitstream is inherently sequential. Modular mode in JPEG XL also has MA trees, but the bitstream is organized in a way that allows parallel decode (as well as efficient cropped decode).
mehrdadn 7y ago
Is AVIF lossless like FLIF?
- Dylan16807 7y ago
  It can be but it looks like it balloons a lot of files to do so.
kalleboo 7y ago
What it will take for something to overthrow JPEG is for both Google and Apple to adopt it. If Android, Chrome, iOS, macOS and Safari all support it (and the phones shoot in it natively like the iPhone does with HEIF right now), it will take over.
- jhoechtl 7y ago
  Think of it Google favoring sites with AVIF, JPEG XL, whatever they settle on in their page rank? Within half a year 80% of the web sites will have converted.
pmarreck 7y ago
Is this superior to HEIF and H.265 other than licensing being freer?
- spider-mario 7y ago
  It’s faster (especially to encode), and in my opinion, better tuned for high quality. H.265 can give a “usable” image in a relatively small file size, but it sometimes takes a surprising amount of additional bytes to get rid of the somewhat oversmoothed aspect, and that additional amount can vary a lot from one image to the next, so with the current implementations, you have little choice but to verify visually. At least, that’s my experience with the reference encoder. I haven’t had a chance to experiment with Apple’s implementation. In contrast, with JPEG XL, I can simply use the high quality setting once per image and be done with it, trusting that I will get a faithful image at a reasonable size.
  - JyrkiAlakuijala 7y ago
    This is an insightful comment.
thdrdt 7y ago
Exactly what you are saying: FLIF is not new (2015) but is still not adopted in any browser I know. I also believe this was due to some license choices in the past. But in this time of responsive websites it is a great format! Just download the amount of pixels you need to form a sharp image and then skip loading the rest. I really hope this becomes mainstream one day.
qwerty456127 7y ago
> It'd be lovely to have photos / screenshots / gifs all able to share a common format. Given the way GIF is used nowadays the only reason it exists is it let's you put a video on the most of the places where you are only allowed to put pictures. For some weird reason many of such websites still won't let you upload an MP4 file despite they auto-convert the gifs you upload to MP4/AVC. From the technical point of view there hardly is a reason for GIF to be used at all.
- GoblinSlayer 7y ago
  Spinners are nothing but energy drain anyway. If there's no progress, spinner won't stop.
  - exikyut 7y ago
    Objectively worse are infinite CSS-animations with opacity:0 set on them that Blink can't figure out are indeed invisible and don't need repainting at 60fps. Cue me noticing my CPU is at 100% and 69°C after about 2 minutes... (ThinkPad T400s are really bad at thermal management.)
sarink 7y ago
Would this really be lovely? Isn't there some value in having 3 distinct formats (still picture, moving picture, moving picture with audio)? Each one is a subset of the next, but they are 3 different things that can easily be identified by what they (only potentially, but probably) are.
- cookiecaper 7y ago
  It's a win from the implementation side because you can support all three use cases with one format, reducing code duplication and at least hypothetically leveraging the same improvements across the three use cases with no additional effort. The UX concern you're describing doesn't necessarily have to have anything to do with the implementation details themselves, as demonstrated by sites like imgur rebranding silent mp4/webms as "gifv". As long as the new format makes it reasonably easy to access data about its content (e.g., header field indicating animation/movement), there shouldn't be any issue with collapsing the use cases into a single implementation and simultaneously addressing the UX concern you mention.
dTal 7y ago
Worth noting that it's not really "new" as such, being over 4 years old. It still doesn't seem to have hugely caught on... That said, lossless codecs have it easier because you can freely transcode between them as the mood takes you, with no generation loss, so there's less lock-in. For example, FLAC is dominant in audio, but there are a variety of other smaller lossless formats which still see use. Nobody much minds.
- rurban 7y ago
  Because it was replaced by FUIF as a successor, then Google's PIK, then JPEG XL.
stevespang 7y ago
If the Big Boys are all supporting AVIF then that leads one to suspect it <may> have some legal backdoors for eventual patenting, or worse, already covered by some obscure patent(s) ? It appears the legal background needs more discussion and revealing . . . unfortunately we live in an age where Big Tech looks to benefit themselves first and everyone else last.
amelius 7y ago
> Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. The hardest part is figuring out which patents they infringe, and how to circumvent them.
hrgiger 7y ago
For the curious netflix has shared AVIF format images http://download.opencontent.netflix.com/?prefix=AV1/Chimera/AVIF/ http://download.opencontent.netflix.com/?prefix=AV1/Chimera/... Here are some supporting implementations: https://github.com/AOMediaCodec/av1-avif/wiki#demuxers--players https://github.com/AOMediaCodec/av1-avif/wiki#demuxers--play... If you want to check how it looks like on supported browser: https://kagami.github.io/avif.js/ https://kagami.github.io/avif.js/ I was also digging around and as OP mentioned found it interesting topic.
deleted 7y ago
[deleted]

by jjcm 7y ago

BurningCycles 7y ago

>Likely the format with the best chance of overthrowing the jpg/gif/png incumbents is AVIF I used to think the same as well, however I now think Jpeg XL is poised to be the 'winner' among next gen image codecs. It's royalty free, great lossy and lossless compression which is said to beat the competition, as well as providing a perfect upgrade path for existing jpeg's as it can losslessly recompress them into the jpeg XL format with a ~20% size decrease (courtesy of the PIK project). It's slated for standardisation within a couple of weeks, it will be very interesting to see large-scale comparisons of this codec against the likes of AVIF and HEIF.

mceachen 7y ago
Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? (Speaking as someone who's seen several open, licensing-unencumbered image/video/audio formats fail to get traction with a majority of browsers).
- BurningCycles 7y ago
  >Interesting. Where have you seen that adoption will be swifter with JPEG XL instead of, say, AV1/AVIF? Well, it's not finalized as of yet (though it is imminent), so rate of adoption is just pure guesswork at this stage. However, things I deem necessary for a new image codec to become the next 'de facto' standard are: royalty free major improvements over the current de facto standards Both AVIF and Jpeg XL tick these boxes, however Jpeg XL has another strong feature which is that it offers a lossless upgrade path for existing jpeg's with significantly improved compression as a bonus.
  - rjvs 7y ago
    So you're suggesting that the advantage JPEG XL has is that it will compress existing JPEGs better than FLIF or AVIF?
    - lukevp 7y ago
      Sounds like it will just take an existing JPEG and reduce the size, but not re-compress it - so even though the original JPEG is lossy, there will be no additional loss introduced, whereas another format not based on JPEG would require a re-encode pass that would lose additional information.
    - BurningCycles 7y ago
      Yes, it losslessly recompresses existing jpeg's into the jpeg XL format, while also making the files ~20% smaller, key point being lossless. Thus it is the 'perfect' upgrade path from jpeg which is the current lossy standard, as you will get better compression and no loss in quality when shifting to Jpeg XL. This being a 'killer feature' of course relies on Jpeg XL being very competitive with AVIF in terms of lossy/lossless compression overall.
      - setr 7y ago
        I'm assuming this is bidirectional? You can go back from XL to jpeg losslessly as well? If thats the case, I'm having trouble imagining a scenario where you're not correct; it'd be an utterly painless upgrade path
modeless 7y ago
Does it have the feature where the file can be truncated to any size to form its own thumbnail? That would be an incredibly useful feature in so many applications.
- Scaevolus 7y ago
  It has a progressive mode, but not as aggressive of one as FLIF.
- ralusek 7y ago
  Surely not any size. It'd have to be squares or something for that to make any sense, right?
  - Dylan16807 7y ago
    Some amount of data at the end of the file won't be usable, but it's easy to make a format that's resilient to you chopping anywhere.
  - someguyorother 7y ago
    Some wavelet formats (SPIHT and EZW e.g) have the property that truncating the lossless version at 10% of the size gives you the 10:1 lossy rendering of that picture. That property holds not just for 10% but for any fraction of the file. It's not quite the same thing, but a very highly compressed high-res picture would probably look okay in thumbnail format.
edflsafoiewq 7y ago
It sounds interesting, although my initial impression is that it sound like it will suffer from the same daunting complexity that afflicted JPEG 2000.
- janwas 7y ago
  Good news: the reference software (http://gitlab.com/wg1/jpeg-xl http://gitlab.com/wg1/jpeg-xl) can decode about 50 Megapixels/s on a single Skylake core, with 3.1-3.7x speedup on 4 cores. Encoding throughput is configurable from ~1 MP/s to about 50 per core. That's somewhat slower than JPEG, but can be faster with multiple cores.
marton78 7y ago
JPEG XL is a terrible name for something that claims to produce extra small results.
- jonsneyers 7y ago
  It may not be the best name, but it sure is better than the names of the projects it was based on: PIK and FUIF. At least if you speak Dutch. A "pik" is a penis and a "fuif" is a party, so the combination would be the "penis party" image codec. I prefer "JPEG XL". The etymology of the name "XL" is as follows: JPEG has called all its new standards since j2k something that starts with an X: XR, XT, XS (S for speed, since it is very fast and ultra-low-latency), and now XL. The L is supposed to mean Long term, since the goal is to make something that can replace the legacy JPEG and last as long as it did.
  - stingraycharles 7y ago
    There might be an explanation around it, but I find it not much better than Apple with their iPhone XS. I agree that XL is a bad name, and I don’t think that “pik fuif” would matter a lot (I’m also Dutch). Could have been e.g. JPEG PF or JPEG LTS.
- l8rlump 7y ago
  PIK project is also a terrible name for people who understand Danish.
gardaani 7y ago
I hope that JPEG XL will be simpler than the competitors. If it's compression ratio is similar to AVIF and it can do HDR, then I'll all for it! AVIF (and its image sequences) seems to be fairly complicated. Here's few comments [1] about it: "Given all that I'm also beginning to understand why some folks want something simpler like webp2 :)" "Despite authoring libavif (library, not the standard) and being a big fan of the AV1 codec, I do occasionally find HEIF/AVIF as a format to be a bit "it can do anything!", which is likely to lead to huge or fragmented/incomplete implementations." Anyway, instead of adding FLIF, AVIF, BPG, and lots of similar image formats to web browsers, I think only one good format is enough and JPEG XR might be it. After something has been added to web browsers, it can't be removed. Safari hasn't added support for WebP (which is good, there's no need for WebP after AVIF/JPEG XR is out) and it hasn't added support for HEIF (which is weird, considering Apple is using it on iOS), but maybe they know that there's no need to rush. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=960620#c33 https://bugs.chromium.org/p/chromium/issues/detail?id=960620...
- jhabdas 7y ago
  Browsers don't need the codecs anyway. They just need Wasm and a decoder. Clients can do the work[1] until the hardware supports the goods. [1] https://git.habd.as/comfusion/fractal-forest/src/branch/master/Dockerfile https://git.habd.as/comfusion/fractal-forest/src/branch/mast...
  - bscphil 7y ago
    The example you linked to is pretty telling, because not only do the BPG images decode more slowly than natively supported images, the javascript decoding approach apparently breaks the browser's (Firefox's) color management. I think native support is needed for newer codecs to be viable for more than simple demos.
    - spider-mario 7y ago
      Chrome appears to interpret the canvas as sRGB and to convert from that, but that means that images decoded that way are effectively limited to sRGB until the canvas API allows specifying other colorspaces.

shotashota 7y ago

the article briefly mentions that its based on a decision tree. Does that it mean it doesn't parallelize well? Or does this fact not matter much?

jonsneyers 7y ago
FLIF doesn't parallelize well, but that's not really because of the MA trees, but just because the whole bitstream is inherently sequential. Modular mode in JPEG XL also has MA trees, but the bitstream is organized in a way that allows parallel decode (as well as efficient cropped decode).

mehrdadn 7y ago

Is AVIF lossless like FLIF?

Dylan16807 7y ago
It can be but it looks like it balloons a lot of files to do so.

kalleboo 7y ago

What it will take for something to overthrow JPEG is for both Google and Apple to adopt it. If Android, Chrome, iOS, macOS and Safari all support it (and the phones shoot in it natively like the iPhone does with HEIF right now), it will take over.

jhoechtl 7y ago
Think of it Google favoring sites with AVIF, JPEG XL, whatever they settle on in their page rank? Within half a year 80% of the web sites will have converted.

pmarreck 7y ago

Is this superior to HEIF and H.265 other than licensing being freer?

spider-mario 7y ago
It’s faster (especially to encode), and in my opinion, better tuned for high quality. H.265 can give a “usable” image in a relatively small file size, but it sometimes takes a surprising amount of additional bytes to get rid of the somewhat oversmoothed aspect, and that additional amount can vary a lot from one image to the next, so with the current implementations, you have little choice but to verify visually. At least, that’s my experience with the reference encoder. I haven’t had a chance to experiment with Apple’s implementation. In contrast, with JPEG XL, I can simply use the high quality setting once per image and be done with it, trusting that I will get a faithful image at a reasonable size.
- JyrkiAlakuijala 7y ago
  This is an insightful comment.

thdrdt 7y ago

Exactly what you are saying: FLIF is not new (2015) but is still not adopted in any browser I know. I also believe this was due to some license choices in the past. But in this time of responsive websites it is a great format! Just download the amount of pixels you need to form a sharp image and then skip loading the rest. I really hope this becomes mainstream one day.

qwerty456127 7y ago

> It'd be lovely to have photos / screenshots / gifs all able to share a common format. Given the way GIF is used nowadays the only reason it exists is it let's you put a video on the most of the places where you are only allowed to put pictures. For some weird reason many of such websites still won't let you upload an MP4 file despite they auto-convert the gifs you upload to MP4/AVC. From the technical point of view there hardly is a reason for GIF to be used at all.

GoblinSlayer 7y ago
Spinners are nothing but energy drain anyway. If there's no progress, spinner won't stop.
- exikyut 7y ago
  Objectively worse are infinite CSS-animations with opacity:0 set on them that Blink can't figure out are indeed invisible and don't need repainting at 60fps. Cue me noticing my CPU is at 100% and 69°C after about 2 minutes... (ThinkPad T400s are really bad at thermal management.)

sarink 7y ago

Would this really be lovely? Isn't there some value in having 3 distinct formats (still picture, moving picture, moving picture with audio)? Each one is a subset of the next, but they are 3 different things that can easily be identified by what they (only potentially, but probably) are.

cookiecaper 7y ago
It's a win from the implementation side because you can support all three use cases with one format, reducing code duplication and at least hypothetically leveraging the same improvements across the three use cases with no additional effort. The UX concern you're describing doesn't necessarily have to have anything to do with the implementation details themselves, as demonstrated by sites like imgur rebranding silent mp4/webms as "gifv". As long as the new format makes it reasonably easy to access data about its content (e.g., header field indicating animation/movement), there shouldn't be any issue with collapsing the use cases into a single implementation and simultaneously addressing the UX concern you mention.

dTal 7y ago

Worth noting that it's not really "new" as such, being over 4 years old. It still doesn't seem to have hugely caught on... That said, lossless codecs have it easier because you can freely transcode between them as the mood takes you, with no generation loss, so there's less lock-in. For example, FLAC is dominant in audio, but there are a variety of other smaller lossless formats which still see use. Nobody much minds.

rurban 7y ago
Because it was replaced by FUIF as a successor, then Google's PIK, then JPEG XL.

stevespang 7y ago

If the Big Boys are all supporting AVIF then that leads one to suspect it <may> have some legal backdoors for eventual patenting, or worse, already covered by some obscure patent(s) ? It appears the legal background needs more discussion and revealing . . . unfortunately we live in an age where Big Tech looks to benefit themselves first and everyone else last.

amelius 7y ago

> Always cool to see new visual compression libraries hit the scene. That said I think the hardest part isn't the math of it, but the adoption of it. The hardest part is figuring out which patents they infringe, and how to circumvent them.

hrgiger 7y ago

For the curious netflix has shared AVIF format images http://download.opencontent.netflix.com/?prefix=AV1/Chimera/AVIF/ http://download.opencontent.netflix.com/?prefix=AV1/Chimera/... Here are some supporting implementations: https://github.com/AOMediaCodec/av1-avif/wiki#demuxers--players https://github.com/AOMediaCodec/av1-avif/wiki#demuxers--play... If you want to check how it looks like on supported browser: https://kagami.github.io/avif.js/ https://kagami.github.io/avif.js/ I was also digging around and as OP mentioned found it interesting topic.

deleted 7y ago

[deleted]