[HN Gopher] JPEG-XL vs. AVIF and Others: 27 Images Compared
___________________________________________________________________
JPEG-XL vs. AVIF and Others: 27 Images Compared
Author : computerbuster
Score : 80 points
Date : 2023-03-18 19:56 UTC (3 hours ago)
(HTM) web link (giannirosato.com)
(TXT) w3m dump (giannirosato.com)
| pixelesque wrote:
| I recently tried out HIEF and AVIF to try and save high
| resolution panorama images to, and discovered that AVIF currently
| doesn't support images > 8K, despite saving the resolution in
| 32-bit ints, which is a bit disappointing in 2023. (Limits
| inherited from the fact it's basically a video codec).
|
| Also annoying was the fact I actually had to debug libavif to
| work out what the problem was, as `avifEncoderAddImage()` would
| just return a generic error that wasn't helpful when the
| dimensions were too big, but `avifRGBImageAllocatePixels()` and
| `avifImageRGBToYUV()` didn't complain about the dimensions
| beforehand.
| wongarsu wrote:
| >Limits inherited from the fact it's basically a video codec
|
| It's also disappointing for a video codec released in 2018. For
| context, in 2019 Sony released an 16k screen. Granted, that was
| a home cinema screen, and 16k displays will be a niche product
| for the forseeable future, but it's also not something
| unimaginably large.
| adgjlsfhk1 wrote:
| I doubt this will ever make sense. An 8k screen that is full
| field of view is already big enough that the pixels aren't
| visible.
| wongarsu wrote:
| An 8k screen has about 33 million pixels. The first google
| result claims that the human eye contains about 91 million
| rods (and 4.5 million cones). So just from a sensor-pixel
| vs image-pixel standpoint, there are gains beyond 8k. From
| the top of my head, going up to about 32k is meaningful if
| you account for the fact that what you're really catering
| to is central vision: the 2-5deg of visual field where most
| of your cones are packed together, giving you much higher
| resolution for the point you're looking at.
|
| And of course that's assuming that the viewer is static. If
| you assume that viewers can move to a point where the
| screen is bigger than their field of view (say a large
| display in a museum) or that the viewer can zoom the video
| (just as we routinely zoom images today) there are even
| fewer limits to reasonable resolutions.
| ttoinou wrote:
| How is 32 bits not enough ?
| CodesInChaos wrote:
| Is that a limitation of the format itself, or just a limitation
| of libavif?
| redox99 wrote:
| Mozilla and Google dropping JPEG-XL support because "too much
| complexity". Software engineers using "too much complexity" as an
| excuse for something they don't want to do is such a classic
| move.
|
| Browsers are already absurdly complex, and are constantly
| receiving HTML, CSS and JS features that significantly increase
| complexity. Are we really to believe that adding support for a
| certain image format, which is basically as modular as it gets
| (decode the file into a buffer), is too much complexity?
|
| Obviously, this is a case of them showing favoritism toward
| codecs based on the IP owners of those codecs.
| [deleted]
| leshokunin wrote:
| Unclear why Google would straight up reject an open standard.
| Considering their browser market share, jt feels like they can
| just kill a standard.
| zamadatix wrote:
| Mozilla's statement gives a good summary of takes form both
| ends and why they decided their position was neutral
| https://github.com/mozilla/standards-positions/issues/522#is...
| edflsafoiewq wrote:
| Unfortunately this basically means JPEG-XL is dead.
| wongarsu wrote:
| dead for the web. I still store various images in JPEG-XL,
| have support for it in my image-viewer of choice, can use
| it in Python's pillow (with a decoder plugin) and lots of
| other things I use to modify images.
|
| I still have to occasionally convert some images back to
| jpeg, but the savings from storing all of them in jpeg-xl
| instead is worth it to me (and avif support is spotty in
| the same areas, it is only really ahead in browsers and
| photoshop)
| recuter wrote:
| X-JPEG-XL, bereft of pixels.
| pmarreck wrote:
| > Overall, we don't see JPEG-XL performing enough better than
| its closest competitors (like AVIF) to justify addition on
| that basis alone
|
| The progressive enhancement feature alone could be quite
| amazing, and its competitors don't offer that- No more
| thumbnail generation! Its competitors can't offer that! Do
| they realize how many security holes everyone's use of
| "ImageTragick" generates, and how much caching infrastructure
| is devoted to images?
|
| also, how does he fail to see this as a potential competitive
| advantage over browser competitors?
| Eisenstein wrote:
| > Do they realize how many security holes everyone's use of
| "ImageTragick" generates
|
| Can you expound on this?
| [deleted]
| Slix wrote:
| Is there a patent, copyright, or royalty reason why JPEG-XL isn't
| championed for the web? It would be awful to have another format
| that can't be used in certain Linux distros or browsers.
| gsich wrote:
| Google doesn't want it so they FUD against it.
| vetinari wrote:
| Or: parts of the internets are salty, because Google didn't
| get the message that nowadays it is mandatory to support
| their shiny toy in Google's product.
|
| Well, Chrome doesn't support bunch of things, and the world
| didn't end. The usual topic is, that is supports too many
| things actually, more than it should.
| jbverschoor wrote:
| Nope. It's the best thing out there atm. It's just big tech
| wanting to control the IP
| mort96 wrote:
| Or is it their desire to be slightly careful about which
| image formats they have to support in perpetuity? With AVIF
| you get to re-use a bunch of your AV1 decoding code too. And
| the reference JPEG-XL decoder is _still_ on version 0.x, with
| no sign that they 'll make a stable release any time soon.
|
| Why everyone is all up in arms about the fact that the
| industry is _finally_ standardizing on a good royalty-free
| image format is beyond me.
| danielheath wrote:
| JXL offers re-encoding of existing jpeg at smaller size
| with no quality loss, and has an efficient progressive
| mode.
|
| As the head of tech for a site with a few tb of user-
| supplied jpeg files (which are thumbnailed), I can see the
| appeal...
| jbverschoor wrote:
| Not just no quality loss. Byte-for-byte identical
| Eisenstein wrote:
| If something is 'byte-for-byte identical' wouldn't it be
| the same size?
| adgjlsfhk1 wrote:
| It's byte for byte identical once you expand to an array
| of pixels. The storage format uses more advanced
| (lossless) compression, but the pixels that come out are
| identical.
| edflsafoiewq wrote:
| When you transcode back to JPEG, the JPEG is byte-for-
| byte identical to the original JPEG. But if you decode to
| pixels you do not always get identical results as the
| JPEG because the JPEG standard does not specify bit-exact
| decoding and different decoders may differ slightly.
| Dylan16807 wrote:
| AVIF doesn't do everything, and a codec that's designed to
| encode video frames will always be limited compared to a
| pure image codec. It especially has trouble with lossless.
|
| If we were picking a single royalty-free image codec for
| the 2018-2026 range, it should be JXL.
| dvhh wrote:
| Sound more like a chicken and egg issue, look like "big tech"
| are mostly using the format for archival purpose.
|
| As Mozilla put it, adopting a new format increase the attack
| surface ( that is already quite large ) of a browser, they
| can not simply take the reference decoder and integrate it
| into their codebase, they also have to use resources toward
| maintaining it. Firefox currently integrate jxl support
| behind an experimental flag, but that could mean the feature
| is in testing and could be deprecated in order to better
| allocate their resources.
| jbverschoor wrote:
| Jxl can be byte for byte identical as the original jpeg at
| an around 80% iirc. Google isn't interested in perfect
| archiving, they'd rather have lossy compression, which you
| can also do.
|
| Why can't they take the reference decoder?
|
| As for the attack surface, why would their own codes be
| less vulnerable?
|
| They don't tend to support each other's codecs either, not
| because of attack surface
| [deleted]
| brucethemoose2 wrote:
| The Chromium dev who rejected JXL works on AOM code. The manager
| who commented on it also participated in some articles about the
| benefits of AV1.
|
| JPEG XL could be twice as efficient as AVIF everywhere, and every
| blog on the internet could benchmark it, and I suspect it still
| wouldn't make a difference.
| [deleted]
| [deleted]
| [deleted]
| Dwedit wrote:
| Note that AVIF is badly broken in Gimp. Save an image as AVIF,
| then load it again. Decompose the Luma and Chroma. You will see
| that the chroma is on a perfect 2x2 pixel grid, as if it was
| upscaled using _nearest neighbor_ upscaling.
|
| This does not happen for JPEG.
| sroussey wrote:
| "And others" in the title does not include HEIC: "HEIC is being
| excluded because it sucks".
| MBCook wrote:
| That really annoyed me. The blog post tries to do a lot to
| appear scientific and objective, then just tosses something out
| without testing due to personal opinion.
|
| They also mention it's not free. That would be ok. Just say
| your test is image quality of _free_ image formats.
|
| But that statement just undermined the trust I had in the
| author up to that point.
| ianlevesque wrote:
| Given how widely deployed HEIC is I would be curious to know
| objectively how it fares even if there are practical reasons
| to not choose it.
| computerbuster wrote:
| You're probably right that I shouldn't have been so rash, I'm
| sorry for the omission & my despondent attitude toward HEIC.
| My enthusiasm is sullied by the presence of royalties & a
| non-existent web presence because of these royalties which I
| consider reasonable (where JXL's lack of web presence is
| questionable). In the future, I may do a similar test and
| include HEIC, but currently I believe it fares worse than
| AVIF almost across the board. I'd be willing to see whether
| or not I'm correct in saying this, though.
|
| I should include that under "Takeaway," I do say that " ...
| this is a non-scientific test," & it shouldn't be considered
| objective despite the use of metrics. While I find
| SSIMULACRA2 correlates very well with what my eyes see with
| these images & most other images, 27 landscape/architecture
| images aren't enough to draw any objective conclusions here &
| I'd need to do more testing in the future to produce
| research-quality work.
| jandrese wrote:
| I think that line was being a bit cheeky. It seems to be
| excluded for the same reason JPEG2000 is: it's patent
| encumbered.
| No1 wrote:
| JPEG2000's patents have expired, there's no reason to exclude
| it due to patents at this point.
| computerbuster wrote:
| I think the most interesting takeaway here is that while JXL
| continues to face unfair treatment from web browser vendors,
| jpegli is a really fascinating development that performs very
| closely to AVIF at high quality in the dataset. I'd like to test
| jpegli with the XYB colorspace in the future to see how much
| better it is compared to RGB, but even with the RGB handicap it
| still looks very promising.
| timbit42 wrote:
| If image types were implemented the way they are on the Amiga OS,
| we wouldn't be having this conversation about whether jpeg-xl
| will be supported in a web browser.
|
| When you add a jpeg-xl.library, every app on the system instantly
| supports loading and saving that image format.
| Asooka wrote:
| Windows already has a codec system. Chrome just doesn't use it.
| No matter how perfect a system service you have, if the premier
| web browser doesn't use it, it doesn't matter.
| peppermint_gum wrote:
| Some will blame Google for the demise of JPEG XL, but I think
| that's a red herring. JPEG XL includes Google technologies such
| as Pik and Guetzli/Brunsli. Some of the JXL developers are Google
| employees. Google doesn't have a profit motive to promote one
| format over another. Their upper management most likely isn't
| even aware that JPEG XL exists. It also doesn't explain why
| Mozilla and Apple are favoring AVIF too.
|
| Nonetheless, there's no question that JPEG XL was sabotaged. AVIF
| was enabled by default in Chrome the day it was implemented, JXL
| had to go through an experimental period. At some point, Mozilla
| developers were told to stop working on improving their JXL
| implementation and they couldn't even merge already developed
| patches.[1]
|
| Google's justifications for the removal were baffling. They said
| there's "not enough interest" despite all the hype, all the major
| companies requesting JXL support.[2] They claimed JXL doesn't
| bring "sufficient benefits", despite the numerous advantages,
| such as lossless JPEG recompression. They published their
| flawed[3] benchmarks _weeks_ after they made the decision to
| remove JPEG XL.
|
| BTW, the removal happened immediately after Adobe announced they
| are supporting JPEG XL in one of their products. Almost as if
| they realized that JXL may be gaining too much support and it's
| time to pull the plug.
|
| So who's behind this if not Google? To me, the most likely
| suspect is AOM, the Alliance for Open Media. The people who are
| involved in AOM also the ones who make the decisions in the
| browsers. What are their motives? I don't know, pettiness? Maybe
| they just want _their_ format to win.
|
| [1] - https://phabricator.services.mozilla.com/D119700#3977128
|
| [2] -
| https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
|
| [3] - https://cloudinary.com/blog/contemplating-codec-comparisons
| tpolzer wrote:
| Some people try to spin this as a Google vs open standards,
| while it's mostly a Google devs vs. some other Google devs
| situation:
|
| If you look at
| https://github.com/libjxl/libjxl/graphs/contributors,
| ~everybody except Jon Sneyers is a Google employee (I think the
| AVIF ratio is similar, but I didn't check).
|
| So the question isn't about which format is better, but who won
| internal politics and it's clearly the AVIF folks - for reasons
| which aren't really possible to tell from the outside.
| ThrowawayTestr wrote:
| Sure is comforting to know that office politics ruins
| everything, including technical innovation.
| PaulHoule wrote:
| I did a small amount of eval work and was not impressed with AVIF
| when it came to compressing photos I took with my DSLR that I
| wanted to present as a "photo I took with my DSLR" that is the
| core of the content. That's a different scenario that a splash
| image for a landing page, but I was really quite disappointed.
| zagrebian wrote:
| > The Chromium team shouldn't have the absolute authority to
| shoot down would-be standards like this
|
| I'm not sure that "the Chromium team" is a real thing. Chromium
| is a cross-company project. People from different companies and
| different teams work on it together. Google has a Chrome team.
|
| edit: I'm not familiar with the Google JPEG-XL situation, but
| generally speaking, it should be possible to ship a feature in
| Chromium without Google's involvement because there are three
| non-Google Blink API owners (last time I checked).
| fabrice_d wrote:
| Even if you manage to land features in Chromium without
| approval from Google employees, that will not help much. If
| Google doesn't want the feature they will disable it in Chrome,
| which is what matters for adoption.
| computerbuster wrote:
| As I mentioned in the article, Thorium is a Chromium-based
| browser that fully supports JPEG-XL. Here's the libjxl patch
| that can be ported to other Chromium-based browsers:
| https://github.com/Alex313031/thorium-libjxl
___________________________________________________________________
(page generated 2023-03-18 23:01 UTC)