16 ms·
The case for JPEG XL
- zackees 4y ago> A unique feature of JPEG XL is that it is possible to recompress existing JPEG images (of which there are a lot out there!) to a JPEG XL file that is on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file. Thank you.
- sedatk 4y agoBrowser support: - JPEG XL: none - HEIF: none - AVIF: all but Edge - WebP: all
- plantain 4y agoJPEG-XL is already implemented in ~95% of browsers in the wild (Chrome, Edge, Opera and Firefox), just only behind a flag.
- sedatk 4y agoAnd it'll stay unsupported until those flags come on by default.
- anthropodie 4y agoChrome Banishes Photo Format That Could Save Space on Your Phone https://www.cnet.com/tech/computing/chrome-banishes-photo-format-that-could-save-space-on-your-phone/ https://www.cnet.com/tech/computing/chrome-banishes-photo-fo...
- nine_k 4y agoThe point of the article is that Chrome removes the experimental, behind-a-flag support of JPEG XL, which dramatically decreases the reach of JPEG XL, so yo say.
- MagnumOpus 4y agoThat list seems desktop centric - more browsing happens on the mobile. Hence Safari is a glaring omission on your list... Until Safari for iOS implements JPEG-XL, it is sadly not ready for mass deployment.
- chrisco255 4y agoBrowser support for AVIF and Webp happened when? Browsers evolve over time.
- sedatk 4y agoI don't remember claiming otherwise. You just can't use it on web today, that's it.
- eslaught 4y agoI was a little surprised about AVIF, so I looked it up and it doesn't seem to be quite there yet (though it's getting there). macOS Safari requires Ventura, and no support yet on Edge. https://caniuse.com/avif https://caniuse.com/avif
- sedatk 4y agoYou're right I missed Edge, but Safari seems to have "partial support" whatever that means.
- alwillis 4y agoSafari 16 didn’t support animated AVIF but 16.1 does.
- jonsneyers 4y agoFirefox still doesn't support animated AVIF, or does it now?
- Nathanba 4y agothat looks really nice, very sad that Edge chooses to go another route here. They use chromium code... if Edge starts supporting AVIF I'll start using AVIF.
- peppermint_gum 4y agoThe funny thing about AVIF support in Chrome is that, unlike JPEG XL, there was no experimental period. It was enabled by default from the beginning (in Chrome 85).
- chungy 4y agoAVIF practically comes along "for free" by just having AV1 support in the first place.
- maxloh 4y agoWhy don't Edge support AVIF? Isn't it a downstream of Chromium?
- nine_k 4y agoI wonder what is the Mozilla's position on JPEG XL.
- izacus 4y agoMozilla is one of the founding members of AoM backing AVIF/AV1. They're shipping AVIF support enlabled. The JPEG-XL bug hasn't received any news or updates for at least a year now and the support is disabled on all stable builds (meaning: you can't even enable it with a flag since it's not compiled in). You can enable a flag on nightlies.
- jonsneyers 4y agoIt hasn't received news or updates because it has been locked. Basically Mozilla's position seems to be that they're not going to do anything on this front until Chrome does it first. I can only assume the decision makers at Mozilla feel the need to "prove their loyalty to the AOM", just like the Chrome codec devs, by blocking non-AOM codecs, in particular JXL.
- KingMob 4y agoOr, they just don't have the resources, market share, or interest to fight this battle. I can think of many better things FF should do other than try to push forward a new image format.
- JyrkiAlakuijala 4y agoIt is not a battle, everyone wants the same: to create the best experience for all the internet users by using free software. We can arrive to the best solution by listening, by creating and studying the evidence, and by discussion.
- hypothesis 4y agoSad joke was that they are waiting for an “alternative implementation”, yet I’m still shocked that Mozilla people are alluding to that elsewhere in this very thread. Unbelievable…
- Tomte 4y agoI'd have expected HEIF to be implemented in Safari, at the very least mobile Safari. Did Apple really not include their native image format on recent iPhones?
- alwillis 4y agoHEIF is the default format for the iOS Camera app and has been since at least 2018.
- Tomte 4y agoYes, exactly. So it's pretty much the standard image format on the iPhone. So I was wondering if/why it's not also part of Safari.
- pornel 4y agoAVIF is based on HEIF + free codec. Apple's HEIC is HEIF + commercial patent-encumbered codec libre browsers are not allowed to use.
- izacus 4y agoAs mentioned above, Safari 16 is shipping with AVIF support so Edge is the last holdout.
- Nathanba 4y agoAs simplistic as it may sound but Google probably removed it mostly because it's a chunk of c++ that they don't want around. I'm the last person to usually endorse a rewrite but in this case maybe they should consider a Rust port so browsers feel more comfortable including this. The point of an image format is to be adopted by everyone.. it's kind of beneficial if you make that usecase as attractive as possible. Personally I think Rust is actually hard to understand and for that reason dangerous too. But it definitely has some safety over c++.
- lifthrasiir 4y agoChromium is an extremely large C++ code base and I don't think they would reject libjxl only for that reason. That said, as an author of the first significant reimplementation of JPEG XL format (J40), I think a Rust decoder would be a good addition to the format and has a long-term plan to make one [1]. [1] https://github.com/lifthrasiir/j40/issues/10 https://github.com/lifthrasiir/j40/issues/10
- ZeroGravitas 4y agoSome on the Mozilla side did raise this as a specific issue. One interesting project would be a combined JPEG and JPEG XL decoder, written in rust which might even lead to a reduction in code size and better security since they have some overlap.
- hypothesis 4y agoThis is a valid argument, but which of the contenders are using Rust or similar security minded languages? WebP appears to be written in C++, perhaps because underlying video codec is also written in C++…
- JyrkiAlakuijala 4y agoWe wrote WebP in C -- in the creative phase of codec and format development I kept it in C++, the feasibility proto was initially launched in C++ (perhaps 0.2 version of the lossless coding, late 2011), but I ported it to C a few months after that and handed it over to the WebP production team (early 2012) who kept making improvements like streaming decoding
- gardaani 4y agoI hope Edge and Safari will enable JPEG XL, but not AVIF. AVIF has several disadvantages, for instance, it takes much longer to encode than JPEG XL and it doesn't support progressing decoding. Google just doesn't like formats created outside their own company. They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them).
- lifthrasiir 4y ago> They prefer WebP and AVIF (created by themselves), but dislike JPEG XL (not created by them). This is a common misconception; JPEG XL is jointly created by Cloudinary (which employs the author of FLIP/FUIF) and Google Research Zurich (which previously created PIK, and employs authors of Brotli and WebP lossless format as well) with an official blessing by JPEG (which mostly set the goal for the format). The only difference here is that the authors do not belong to the Chrome team.
- izacus 4y agoSafari has already shipped AVIF support with iOS 16 and macOS Ventura. Apple is a member of AoM backing AV1/AVIF formats, together with other browser vendors.
- todotask 4y agoGoogle Brunsli was adopted for JPEG XL. https://github.com/google/brunsli https://github.com/google/brunsli https://www.codercto.com/a/103418.html https://www.codercto.com/a/103418.html
- ksec 4y agoThis may have happened during Steve's era. Who tends to pick the best codec and fight for it. No under Tim Cook though. They sided with Google already.
- nine_k 4y agoThe scoop: a JPEG XL developer explains how JPEG XL is uniquely better than AVIF, webP, and PNG, and laments the Chrome team's decision to drop the experimental support for it. AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000.
- tgv 4y agoYou're seriously underselling the article.
- nine_k 4y agoI'm trying to entice reading it! :)
- zokier 4y ago> AFAICT, JPEG XL does not seem to have the licensing complications of JPEG2000. Well, there is this thing https://jpegxl.io/articles/rans/ https://jpegxl.io/articles/rans/
- vanderZwan 4y agoYou're technically correct, but: > Several variants of the coding procedure Asymmetric Numerical Systems (ANS) may be found in most modern codecs, such as AV1, Z-Standard compression, or even rANS in JPEG XL. ... this is hardly the fault of the JPEG XL developers though, that's the US patent system being ridiculous. Also, in the current discussion context that patent screws over any new compression format, not JPEG XL specifically. Note: general compression, not just image compression (ok, sure, QOI isn't affected. QOI also isn't relevant here). It's obviously a defensive patent anyway, because between AV1, zstd and JPEG XL Microsoft would have to fight an alliance of literally everyone else out there if they'd plan on suing anyone.
- derf_ 4y agoAV1 does not use rANS in any form. The quoted sentence is simply incorrect. However, any necessary patent claims owned by Microsoft, an AOM member, would be freely licensed to everyone for use in AV1 implementations if it actually did use rANS. Which it doesn't.
- hypothesis 4y agoOn one hand numbers do not mean much, but I think that releasing a 1.0 version of official library would at least help with morale and signal some completeness. I’m sure there are reasons making fresh 0.x releases even after creating a standard format, but it was a bit disappointing after years of waiting, even before this blow by certain browser maker.
- lifthrasiir 4y agolibavif is still not at 1.0 (in fact, 0.11.1 at the time of this writing). Having a 1.0 release is good, but not relevant to this matter.
- jonsneyers 4y agoAlso libwebp reached 1.0 only about 8 years after it was added to Chrome. So I don't think this is a major criterion. That said, we are aiming to reach the libjxl 1.0 milestone within a reasonable timeframe, i.e. somewhere in 2023, preferably first half.
- chungy 4y agoAnd Mozilla waited for libwebp to reach 1.0 before making the plunge to support it in Firefox. One of the main issues was that libwebp was willing and frequently made backwards-incompatible changes to the codec in the 0.x days; Google simply didn't care about breaking images, but Mozilla cared.
- jonsneyers 4y agoYes, that's a problem when a format is not standardized but controlled by a single entity. JPEG XL is standardized though, and backwards-incompatible changes are essentially impossible.
- JyrkiAlakuijala 4y agoBeautifully written article -- I couldn't agree more. From my personal point of view the biggest impact are: 1) e-commerce textures such as cloths are more faitfully represented -- more trust in e-commerce, more revenue 2) more equity for selfies, people-of-color skin is better represented in JPEG XL, selfies in general look more people like with less smoothing of skin performed at compression stage -- I'm a great friend of the idea that filtering should not be built into the compression so that all kinds of images can be transmitted 3) more compression, faster and cheaper to load 4) better progression -- unlike I believe AVIF does, JPEG XL progression does not impose more decoding cost for sequential, progression does not make compression density worse 5) thermal camera support -- I believe thermal cameras have huge ecological and cost optimization opportunities and more phones should have thermal cameras in them to facilitate the shift away from fossil fuels 6) small images -- thumbnails and sprites etc. do not necessarily need spriting with JPEG XL. That is a nice increase in system level simplicity. JPEG XL overhead is about 10-20 bytes whereas AVIF overhead seems to be 600 bytes or so. 7) 'it just works, no surprises' -- the worst case image quality degradation in any quality setting are much less severe and much less common than in other formats
- est 4y ago> people-of-color skin is better represented in JPEG XL wait what? What is this woodoo and why it itsn't the case for other image formats in which encodings color in RGB?
- DaiPlusPlus 4y agoPreface: It's difficult to write about stuff like this and I know reading it back to myself after will leave me wanting to redraft it 5 times over but it's 1am already. But, if this post is wrong/incorrect or is missing other factors that are too important to leave out then please let me know and I'll amend or even delete it. My focus is on the technical side of things. So anyway: > why it itsn't the case for other image formats in which encodings color in RGB? The term "RGB" doesn't mean anything w.r.t. gamut, gamma, dynamic-range, nor how necessarily non-linear transformations between color-spaces are performed. But all that's irrelevant: JPEG'S colour support is actually quite fine (...if you don't mind chroma subsampling), whereas the problem here relates to how JPEG decides what part of the image are important for high-quality preservation (more bits, more quality) than other areas (less bits, less quality). Obligatory ADHD relevant-yet-irrelevant diversion: this excellent (fun and interactive!) article about how JPEG works: https://parametric.press/issue-01/unraveling-the-jpeg/ https://parametric.press/issue-01/unraveling-the-jpeg/ (Caution: incoming egregious oversimplification of JPEG): Now, just imagine a RAW/DNG photo of the sky with some well-defined cumulus clouds in, and another RAW/DNG photo of equal pixel dimensions and bit-depth (so if they were *.bmp files they'd have identical size), except the second photo shows only a grey overcast sky (i.e. the sky is just one giant miserable old grey duvet that needs washing). Now, the _information-theoretic_ content of the cumulus clouds photo is higher than the overcast clouds photo; the clearly-defined edges of the cumulus clouds are considered "high-frequency" data while the low-constrast bulbous gradients that make-up the overcast photo are considered "low-frequency" data, and less overall information is required to reconstruct or represent that overcast sky compared to the cumulus sky. This relates to JPEG because JPEG isn't simply a single "JPEG algorithm", it's actually a sequence (or pipeline?) of completely different algorithms that each operate on the previous algorithm's output. The specific step that matters here is the part of JPEG that was designed with the knowledge that human vision perception doesn't need any high-frequency data in a scene where the subject is largely low-frequency data (i.e. we don't need a JPEG to preserve fine details in overcast clouds to correctly interpret a photo of overcast clouds, whereas contrarywise we do need JPEG to preserve fine-details that make-up the high-constrast edges between cumulus clouds and the blue sky behind them, otherwise we might think it's some other cloud formation with less well-defined edges (Altrostatus? Cirrostatus? Cirrus? I'm not a meteorologist - just someone on the spectrum using abusing analogies). So my point so-far is that JPEG looks for and preserves the details in areas of images (where high-constrast data is) while disregarding high-frequency data in an overall low-frequency scene where it thinks those details don't matter to us humans with our weird-to-a-computer visual perception system. I imagine by now I've made JPEG sound like a very effective image compression algorithm (well, it is...) - so where's the problem? ...well, consider that when a person has a low-level of melanin in their skin they will feature areas of high-contrast on their faces: their skin's canvas is light - while facial-features like folds, creases, crows' legs, varicose veins, spots, etc, are like the hard-edges of those cumulous clouds from earlier: the original (pre-compression) image data will feature a relatively high image constrast where those features lie, and JPEG will try to preserve the details of that constrast by using more bits. So that's neat: JPEG tries to ensure that the parts of us that of us that are detailed remain detailed after compression. ...but what if a person's face is naturally less...contrast-y? That's the problem: when a person simply has darker skin their faces will feature less contrast between the skin-parts of their face compared to the features of their face - as caught by a camera. So if a simplistic JPEG compressor is being run against a United Colors of Benetton coffee-table book or stills taken from the end of a certain Michael Jackson music video that I'm particularly fond of[3] then we will, as you can imagine, unfortunately, see the JPEG image files of people with darker skin will feature less definition and detail of their faces compared to the photos of people with lighter-skin, simply due to how areas of higher, and lower, contrast are _mechanically_ processed by JPEG. ...which means that sloppily applying JPEG[1] to photos of everyone might work great for people who have faces-with-naturally-high-contrast/high-frequency-information on them - but not-so-great for everyone else - and I think we can agree hat we can improve on that. ----------- Confounding things, the distribution of melanin in the JPEG development working group was not representative of the general population in the US at the time[5], let alone the rest of the world, which in-practice meant that less thought (if any) was paid to JPEG's stock handling of people with lower overall skin feature contrast (i.e. black people) - though no malice or ill-will or anything of the sort is required: like all of us (I assume...) they probably thought "these photographs of me (or people who generally look like me) processed by JPEG are good enough, it's been a long week, let's ship it and go for a pint" - without realising or appreciating that it wasn't "good enough" for large chunks of the population. At least, I hope that's the explanation... (and given Hanlon's Razor too). The situation can be compared to the... uh... colourful stories about the history of Kodak's colour film, its shortcomings, and the social-consequences thereof[2]. Or for something more recent: the misbehaving face-detecting webcams of the last decade that lead HP to make a certain public statement[3]. ----------- [1] I say carelesslessly because lots of tooling for JPEG, especially at the pro-level (think: Photoshop) gives you a lot of control over how much information-loss is allowed for each macroblock (e.g. Photohop's Save-for-Web dialog (the old, good one, not the new dumbed-down one) lets you use its own paintbrush tool to mask areas that should lose fewer bits (i.e. higher-quality) even if the JPEG compressor doesn't think there's much value in that part of the image. MSPaint, on the other hand, does not. [2] https://www.nytimes.com/2019/04/25/lens/sarah-lewis-racial-bias-photography.html https://www.nytimes.com/2019/04/25/lens/sarah-lewis-racial-b... [3] https://www.reuters.com/article/urnidgns852573c40069388000257693007c9b22/hp-our-webcams-arent-racist-idUS97608933020091222 https://www.reuters.com/article/urnidgns852573c4006938800025... [4] https://www.youtube.com/watch?v=F2AitTPI5U0 https://www.youtube.com/watch?v=F2AitTPI5U0 [5] I would like to mention that there was at least something for gender representation: the co-inventor of JPEG was a woman (no, I'm not referring to Lena.jpg) - Joan L. Mitchell, who sadly passed-away relatively young a few years ago: https://en.wikipedia.org/wiki/Joan_L._Mitchell https://en.wikipedia.org/wiki/Joan_L._Mitchell
- sfink 4y agoI'm not really familiar with the space, but the article kind of suggests another reason I could imagine not supporting JPEG XL: if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? I don't think having an existing library that all browsers could "just use" is a good argument. That just means that the implementation is the specification, no matter what the official spec says. Note that I'm not saying that this is a problem or that JPEG XL shouldn't be supported. I just don't know what the real situation is, and this article smelled a little like it might be sweeping some things under the rug. (And for the other other side, the justification in the bug also seemed lacking.) Anyone know more?
- xeeeeeeeeeeenu 4y agoThere are a few alternative decoder implementations in progress. I believe J40 is the most complete one: https://github.com/lifthrasiir/j40 https://github.com/lifthrasiir/j40
- lifthrasiir 4y ago> if it has the long list of advantages described, then how much of a single thing is it? Do you have to implement every feature in order to be considered supporting JPEG XL? Or would a browser implementing from scratch run the risk of splitting what the format means? You have a very good point. In fact I think this is the first time I ever seen such a question, which was also something I wanted to answer by making J40. Of course in the practical standpoint you should just use existing libraries, but I wanted to answer that from the library author's perspective. I'm happy to report that JPEG XL's design is better than I hoped and it successfully tried to do many things out of a reasonable number of components. This means that library authors can mostly implement those components and they will combine reasonably well. There are still some imperfect edges though. For example JPEG XL splits a full image into multiple tiles to faciliate parallel decoding, and the Table of Contents is used to locate individual tile data. But TOC requires a full entropy coding to decode, so you can't easily determine how many bytes are needed for decoding, say, 1/2 of the full image. Those kind of imperfections are harmless for JPEG XL's main use cases but still something I would definitely fix if I'm even given a chance (not to say that I'm a good person to do so).
- mastax 4y agoI had regarded the lossless re-compression as an interesting parlor trick, but I get it now. Coincidentally today I was testing how much we can shrink our archived videos. We have lots of videos recorded with the Intel hardware encoder in H264, so not even the state of the art of H264. I figured: pop it into handbrake, change the codec to H265 (X.265), and boom 30%+ reduction. No, the H265 file got 3X larger. Well the default handbrake quality might be higher than the original video, and now it's going to some spend bits trying to encode the artifacts in the source video, while adding artifacts of its own. Sure you can find a happy medium where the quality won't be too much worse and you reduce the file size in most cases. But it sure would be nice to be able to losslessly recompress those videos!
- vanderZwan 4y ago> But it sure would be nice to be able to losslessly recompress those videos! And you highlight a crucial thing here: being able to do so without fiddling with parameters for hours to fine-tune it or even just finding something that works at all.
- crazytalk 4y agoMost online video uses crazily overspecified h.264 bit rates for low complexity content. It's often possible to get 1080p well under 2 Mbit/s with little to no quality loss, and even lower by using 2 pass encoding where that's available. I'm not sure how things are with h.265 in a production setting, but at least for home use it seems to have much of the same flexibility
- formerly_proven 4y agoDo you work for Amazon Video or Netflix?
- JyrkiAlakuijala 4y agoI get nervous when I see motion artefacts on netflix. This means I'm pretty much always nervous when watching netflix. I use a 1 gbps home connection and pay for the most expensive option netflix has. I'd like to think that the whole concept of motion frames based prediction will disappear in future videos. Motion JPEG XL would be like in the movies where they have Motion JPEG 2000, but ~35-40 % more dense. We could add usual delta frames without motion without compromising quality criteria. This would get us in the 0.3 BPP range. 4k at 30 Hz would be 3840 x 2160 x 24 x 0.3 should need about 60 mbps (~ 7.5 MB/s), still doable for home internet speeds and would be visually lossless, a better experience than home movie streaming is today. (free startup idea) :-)
- gman83 4y agoWas there any momentum getting JPEG XL approved in browsers (not behind a flag) before Google decided not to support it? I barely heard about it at all. Perhaps if Google wants to create developer enthusiasm for some new feature they want to implement, they should first announce they're NOT going to be implementing said feature, then when the inevitable backlash happens, very publicly backtrack.
- dmitriid 4y agoGoogle don't need to resort to such tricks when they can just bludgeon everyone to death. Se how they forced support of VP9 and AV1: https://www.protocol.com/youtube-tv-roku-issues https://www.protocol.com/youtube-tv-roku-issues
- rob74 4y agoNot to mention WebP, which I guess is the elephant in the room when they say that JPEG XL "does not bring sufficient incremental benefits over existing formats".
- gruturo 4y agoAnd which is very unconvincing in real world use.... It benchmarks well, but "looks" crap. I really wish they had produced something better than that, if that's what we're going to be stuck with. It's sad.
- JyrkiAlakuijala 4y agoJPEG XL is the other way around: Okeyish/boring in usual PSNR, SSIM, VMAF benchmarks, great in benchmarks with DSSIM, SSIMULACRA2 and Butteraugli, but looks superb to humans.
- gruturo 4y agoAnd it addresses a very, very real use case of recompressing JPEGs without generation loss. Considering that a vast majority of all pictures being taken even today begin their life as JPEGs, that's very relevant.
- mastax 4y ago> One final significant benefit of JPEG XL is that it has a broad scope: while it is a great format for web delivery, this is not the only use case it was designed for. JPEG XL can also be used as a capture format, where it can play a role similar to current camera raw formats: high precision, high dynamic range, lossless or minimal lossy compression. It can also be used as an authoring format, supporting named layers, selection masks, multiple alpha channels. It can be used for printing use cases, supporting e.g. CMYK and spot colors. It can be used for medical or scientific applications, supporting high-precision lossless compression and multispectral imaging. And so on. It is a general-purpose format that covers many different use cases for digital imaging. So that's all impressive and useful and probably quite good, but my first reaction is that sinking feeling from being faced with unexpected complexity. Is the JXL format a nightmare internally? Is it a nightmare to use the library as an inexperienced app developer? Do you need to care about those unusual features if you just want to display an image? I expect that it's all fine, since what little I've heard has been good. If so, kudos to the designers because that's an ambitious feature list. It feels uncommon for a format of any kind to set out to be all things to all people and succeed.
- janwas 4y agoDisclaimer: I co-chaired the JPEG XL working group; opinions are my own. The JPEG XL format is most certainly not a nightmare internally. Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf https://aomediacodec.github.io/av1-spec/av1-spec.pdf, 101 for https://www.iso.org/standard/77977.html https://www.iso.org/standard/77977.html. Or code sizes: 6.6 MB uncompressed for libjxl (encoder+decoder), 9.5 MB for dav1d (decoder only) plus 34.2 MB for SVT-AV1 (encoder). Features such as spot colors are mostly just a matter of understanding a wide range of requirements; this particular one just boils down to an extra image layer.
- cesarb 4y ago> Compare the spec lengths: 681 pages for https://aomediacodec.github.io/av1-spec/av1-spec.pdf https://aomediacodec.github.io/av1-spec/av1-spec.pdf, 101 for https://www.iso.org/standard/77977.html https://www.iso.org/standard/77977.html. And here we immediately see one important difference between them: the first link is to a 681-page PDF, which opens immediately in my browser. The second link is to a place where one can buy access to what it says is a 101-page PDF, after paying more money than it would cost to buy a basic laptop.
- nigeltao 4y agoFrom the "Lossless Compression Performance" section of the article: > JPEG XL can do lossless image compression in a way that beats existing formats (in particular PNG) in all ways: it can be faster to encode, produces smaller files, and more... Does "in all ways" include any decode (not encode) speed numbers? Such numbers are dependent on the test suite, and I might be holding it wrong, but on my measurements, JPEG XL lossless encodes 10x slower and decodes 12x slower than PNG (the libpng implementation), and decodes 30x slower than PNG (the wuffs implementation). JPEG XL does admittedly win on compression ratio (smaller files), though. https://github.com/nigeltao/qoir/blob/main/doc/full_benchmarks.txt https://github.com/nigeltao/qoir/blob/main/doc/full_benchmar...
- jonsneyers 4y agoLossless encoding can be done with various trade-offs between speed and compression density. At one extreme we have fjxl, see e.g. https://twitter.com/LucaVersari3/status/1485971553892323333?t=BFVNYj33K-sXuJY50CS5Cw&s=19 https://twitter.com/LucaVersari3/status/1485971553892323333?.... This is an extremely fast lossless jxl encoder, which is about 100 times faster than PNG encoding (libpng) and compresses about 10% better. At the other extreme, there are the slowest settings of the reference encoder libjxl, which are 1000 times slower than libpng but compresses a lot better. As for decode speed: this depends on whether you consider single-threaded or multi-threaded performance. In single-threaded decode performance, it is hard to beat PNG since it is basically just gunzip. PNG is inherently sequential though (unless you apply trickery at encode time to make parallel decode possible), while JXL is by design decodable in parallel. We are anticipating that in the future, the number of cores available on typical hardware will only grow, so this difference will naturally lead to JXL becoming faster to decode in practice. The current reference software libjxl is quite optimized for the lossy case, but still has some room for improvement for the lossless case — in particular it does not have fast paths yet for the common case where the full precision of 32-bit per sample is not required. So in conclusion, I think it is safe to say that JPEG XL beats PNG in all ways.
- nigeltao 4y agofjxl is the "JXL_Lossless/f" lines in my full_benchmarks.txt link. It's about mid-table in terms of encode speed. I clocked it at about 10x faster than libpng, not 100x faster. If you look solely at encode speed, fjxl loses to fpnge (also listed in full_benchmarks.txt) so I'm not convinced yet that JPEG XL beats PNG in all ways. I believe that Apple have an unofficial PNG extension that facilitates multi-threaded decoding: https://github.com/w3c/PNG-spec/issues/45 https://github.com/w3c/PNG-spec/issues/45
- jokabrink 4y agoI think the solely reason why JPEG XL did not go off is simple: It had no lobby. No large tech company actively promotes it and so, many people hadn't heard of it. Ironically, the deprecation of it in chrome made me aware of it in the first place. Technically, JPEG XL may be a superior contestant. But from a 'social' point of view? Disastrous, especially considering it already has "JPEG" in it. (To be fair, its also quite young...) I really hope JPEG XL gets more traction because it seems like a really good successor to the old namesake.
- hypothesis 4y agoNow imagine that you saw a presentation couple years back with all the nice features that smart people packed in… and here is what it came to, parlor games basically. Maybe a nimbler PR approach would help, but then we know that standards like websql are shutdown over nothing, even though sqlite eating the world alive…
- rocqua 4y agoPersonally, the name always turned me off. I saw the option in photoshop when saving files, but my thinking went "jpg bad, jpg XL is a weird name, must be a minor incremental improvement over jpg".
- kasabali 4y agoWhy would you think "XL" would be minor improvement?
- jonsneyers 4y ago
- Heikete 4y agoThe thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind. Here in Poland most of the tech people use Firefox as that was the alternative when IE was a bad guy and Firefox continues to be a good browser. What was the advantage of Chrome which made people exchange one monopoly for another? PNG had also hard times in IE at first, as far as I remember. So instead of fighting for good chrome, shouldn't we just fight for more diversity in browserland?
- jbverschoor 4y agoFirefox was slow as hell and resource hungry Also, the ui doesn’t feel naive at all
- atemerev 4y agoNo UIs feel native these days, everybody invents their own UI kits.
- jbverschoor 4y agoSomewhat true. Just tried it, yet again. It looks like it improved. I might use it as my social media browser, so it's easier to focus / disable social media and HN on my main browser. Right click on text, there's no dictionary lookup menu item The border around input fields look weird
- atemerev 4y agoAdvertising and branding. Google is a search monopoly, and has (or used to have) the reputation of "we are making high-quality software". We have a web search monopoly, because our search engine is the best, so why not trust us for making the best browser too? Firefox has no search engine monopoly to advertise and build its brand upon.
- sangnoir 4y ago> The thing that I don't understand is why the world has switched over to Chrome leaving Firefox behind Reasons why I, a former Firefox promoter switched to Chrome: 1. Speed. Chrome was blazing fast compared to other browser 2. Stability: Chrome could have a tab crash without bringing down your entire browser. 3. Really good developer tools that were superior to Firebug. As a matter of fact, Chrome Dev tools were my gateway drug as I'd use Chrome for work and Firefox for personal browsing, and the gradually shifted entirely to Chrome.
- ux 4y ago> A unique feature of JPEG XL is that it is possible to recompress existing JPEG images (of which there are a lot out there!) to a JPEG XL file that is on average about 20% smaller, without introducing any loss. In fact, the bit-exact same JPEG file can be reconstructed from the JPEG XL file. I wasn't aware of this and this is actually crazy, and freaking brilliant from a migration point of view. I wonder how that was achieved. I didn't care so much about JPEG XL, now thanks to Google derping I want it everywhere.
- JyrkiAlakuijala 4y agoThe journey to JPEG XL started with guetzli (which started with butteraugli to guide loss in JPEG encoding) and brunsli. Guetzli is a great (but very very slow) JPEG encoder. Brunsli is a classic JPEG1 recompressor. We mixed those and got the first version of PIK. We added some forced format-level progression, adaptive quantization, filtering, larger DCTs, integerated HUIF as lossless/super-progressive coder, and adopted some WebP lossless features into HUIF (Select, 2d-LZ77, entropy clustering). The final version still had brunsli-like features and we surfaced those as a JPEG recompression system.
- sureglymop 4y agoAs a swiss person, all these names of common christmas cookies here are making me hungry.
- JyrkiAlakuijala 4y agoothers are real Swiss cookies, but butteraugli is a made up Pseudo-Swiss word based on voisilmäpulla, a Finnish sweet bread
- sureglymop 4y agoInteresting... Butteräugli does sound like a swiss cookie though. I can even imagine what it looks like based on the name.
- enimodas 4y agoTangentially, in his linked page "hall of shame" https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMULACRA_2_modelD.html https://jon-cld.s3.amazonaws.com/test/ahall_of_fshame_SSIMUL... , he argues humans prefer row A to row C. Personally in most cases I prefer row C. It may have less color accuracy, but is often a lot sharper, which in my eyes stands out a lot more.
- vanderZwan 4y agoDid you read the sentence right after he makes that claim? > At Cloudinary, we recently performed a large-scale subjective image quality assessment experiment, involving over 40,000 test subjects and 1.4 million scores. This isn't about your, my or Jon Sneyer's individual opinions on these photos, it's the consensus of 40,000 test subjects. And yeah, I agree with you that for a significant number of photos I disagree with the consensus. But given that we're both posting on HN we're both also likely the kind of people who like to prove other people wrong by actively looking for and overvaluing counterexamples, so also keep that in mind. Because to be honest, for a large number of photos I also agree with the consensus.
- JyrkiAlakuijala 4y agoPsychovisual image quality tests are difficult and complicated. Selection of the population, methods, guiding text, motivation, etc. can lead to strange things happening. As an example of the difficulties an academy leading corpora TID2013 has a reversal in quality between categories 4 and 5 -- highest quality images seem to get slightly worse quality ratings than the next highest quality images. I observed a leading image quality laboratory to produce substantially different results for the same codec when the person conducting the experiments changed. There are hard opinions if images should be reviewed one image pixel to one monitor pixel, or if images should be zoomed like they are in practical use, particularly on mobile. Should zooming be allowed? Should people be allowed to move closer to the monitor if they want as part of the viewing? etc. etc.
- vanderZwan 4y ago
- aabhay 4y agoThis is really sad. I was sincerely hoping for jxl to become a widespread standard. Especially things like formats for 3D materials that have both high but depth color information as well as depth information, we could have a single format that could encode the entire texture easily. Also space-saving storage, etc. We’re still pretty committed to using jxl as an internal standard for many things.
- account42 4y agoUnrelated to the content, but isn't it silly that browsers start hiding the scroll bar only for websites to implement their own ad-hoc reading progress bars.
- ayushnix 4y agoI find both solutions to be flawed. The traditional scrollbar introduces layout shift when going from one page without a scrollbar to a page with a scrollbar. The new overlay scrollbar is sometimes harder to click and activate, especially in Chromium. Firefox's overlay scrollbar seems to do the right thing. The reading progress bars are a distraction and probably harmful to one's attention span and reading ability. I guess scrollbar-gutter can fix the traditional scrollbar but then people have to give up using their fancy banners in headers. I'm (mostly) fine with Firefox's overlay scrollbar for now.
- account42 4y agoAt least on a desktop we have enough horizontal space to always display the vertical scrollbar, which solves all issues. But even without that, the layout difference between pages with or without scrollbar is so tiny that IMO its a nonissue. Mobile is a tricky tradeoff. There I am mostly used to Firefox, which has a tiny overlay scrollbar that is 50% grey making it almost invisibile in most cases.
- ayushnix 4y ago> But even without that, the layout difference between pages with or without scrollbar is so tiny that IMO its a nonissue. It annoyed to me enough to make me activate overlay scrollbar on Firefox and inject custom CSS with scrollbar-gutter on Chromium. Otherwise, when moving from a repo home page (without a scroll bar) to the another page (let's say the contents a folder with a scrollbar), the box containing the contents of the repo experiences layout shift. This is still an issue on GitHub and many other sites.
- iggldiggl 4y ago> Mobile [...] Firefox … and unfortunately it's not draggable, either.
- account42 4y agoAnother argument: JXL actually supports losless compression of RGB bitmaps and cjxl (the JXL reference encoder) actually supports color spaces correctly when converting from PNG unlike Google's WEBP, which only supports losless YUV compression and the conversion from RGB to YUV is not entirely lossless and cwebp (Google's WEBP reference encoder) doesn't support all the ways color spaces can be encoded in PNGs, resulting in washed out images in some cases. And what could also be an advantage for JXL is animation. WEBP does have animation support implemented in browsers but it came after the freature was enabled and doesn't have a separate mime type so you can't do fallback to .gif without user agent checks. If JXL support either ships with animations enabled or animated JXL gets a separate mime type in browsers it could make it actually useful.
- webmobdev 4y agoYeah, if I remember right, when I was converting some high resolution uncompressed TIFF images to lossless HEIF / HEIC on macOS preview, most of them looked off because colour space conversion was happening (I think from RGB to YUV). (Not to mention many actually failed to convert because none of the HEIF / HEVC encoder I tried could handle very large image sizes). I finally opted for JPEG2000 format to archive those images. I've been waiting for JPEG XL for sometime now to be ready - by my rough calculations, I may be able to get an extra 10 GB space by converting these images to JPEG XL, without any quality loss or issues.
- JyrkiAlakuijala 4y agoWebP lossless is also RGB lossless. I designed it and this was one of the main functional requirements I chose for it. Particularly, WebP lossless does not use YUV compression. It does (optionally) reduce component correlations by the 'subtract green' transform. It might be possible to construct an ICC profile in that formalism that would go close to YUV, but that is definitely not supported currently in cwebp.
- conaclos 4y agoOn the same website, another blog post [1] compares JPEG XL with other formats. [1] https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
- Lockal 4y agoBe careful with this website. Cloudinary is a developer of JPEG XL, is an affiliated party, so there is absolutely no reason to expect a fair comparison. Instead visit https://storage.googleapis.com/demos.webmproject.org/webp/cmp/2022_10_04/index.html#white-dune-mui-ne*1:1&AVIF-AOM=t&JXL=t&subset1 https://storage.googleapis.com/demos.webmproject.org/webp/cm... and you will see that JPEG XL has color fringing and ringing artifacts.
- account42 4y agoThere is some irony on calling out benchmarks from an affiliated party and then linking to benchmarks from an affiliated party of the competing format. > The source images were stripped of any metadata, EXIF, XMP, color profile etc. including the gAMA PNG chunk. Just so happens that cjxl correctly supports PNG color profile/gamma data while cwebp doesn't.
- Lockal 4y agoI'm not suggesting to look at the "benchmark" part of this page. Given that the creators of formats can approximate the result to synthetic metrics for as long as they want, these metrics are secondary to individual perception. Personally, I would have easily sacrificed SSIM just to avoid seeing the green sand on the border of the blue and yellow areas.
- bartimus 4y agoHDR is mentioned only once. Yet this should be the primary case for any new image standard. I'll repeat a comment I wrote here earlier: Our camera hardware supports HDR. RAW image formats support HDR. Our display devices support HDR. Videos support HDR. Smartphones can now record in HDR. All the hardware is there ready for the future. Yet due to (30 year old) software limitations we're still cutting off HDR data when saving our precious memories as JPEG. All whites become #ffffff. The white of paper. The color of Word's document background color. The gamut of color has expanded and we need image standards to expand with it.
- JyrkiAlakuijala 4y agoAdobe and Intel seem to share your thinking with HDR driving this generation of image formats. https://helpx.adobe.com/si/camera-raw/using/hdr-output.html https://helpx.adobe.com/si/camera-raw/using/hdr-output.html JPEG XL has HDR always built-in into its modeling, both SDR and HDR images are modeled exactly the same way and give the exactly same visual quality with the same encoding parameters. Compositing SDR and HDR materials does not need conversions between colorspaces -- everything is in absolute color XYB colorspace. Other codecs (AVIF, HEVC) need a different set of encoding parameters for obtaining the same visual quality when used for SDR or HDR. Compositing SDR and HDR materials necessarily needs color conversions, since they will have different normalizations. Knowing which HDR quality setting corresponds which SDR setting will become additional cognitive load for the users.
- RunSet 4y ago> Recently, the Chrome developers announced their decision to remove the behind-a-flag support for JPEG XL. Given that, is there any reason JPEG XL might be better for privacy / worse for advertising industry scumbags? I have no expectation that Google / Chrome will ever make any decision primarily with their users' best interest in mind.
- deskamess 4y agoThere really is no good justification for this decision. Perhaps unrelated but Google seems 'business tone deaf'. With every product release the first question on our minds is 'When will it get deprecated?' - and that is a legitimate question. Their support story is not that impressive. They do not seem to have the history/culture/DNA for support that MS or Amazon has. Their best customer is the browser - a customer that does not ask for support, only ads. I think they have prospered and will continue to for some time but they have to get a better non-browser customer support story. Ad revenue paved a runway so wide that potholes do not bother them. If the revenues keep coming down they will need a shift in attitude (management and developers).
- pornel 4y agoJXL developers are understandably upset about being a victim of Worse is Better. The Web platform is hardly cutting edge here. It took 10 years to add WebP across browsers, and it wouldn't have been added at all if it didn't cause web-compat issues for non-Chrome(ium) browsers. From browsers' perspective the question isn't "is the new codec better", but "are existing codecs so terrible that they need urgent replacement". Most people still use JPEG, not even WebP or AVIF yet.
- JyrkiAlakuijala 4y agoWith your logic we should quickly remove WebP and AVIF, and have an active discussion if JPEG XL is good enough to make it. Also port as much as possible from JPEG XL tech into traditional JPEG.
- pornel 4y agoThat's not what I was trying to say. You know that it's impossible to remove WebP from the web platform any more. I do think it'd be nice to have a plan for removal of AVIF from the platform, but I don't know if AV1 video will become unremovable. Porting of new features to the old JPEG has been attempted in JPEG XT, but it didn't take off. It sucks that the codec with the best quality/filesize ratio doesn't just win. There are many other factors beyond this, e.g. • There's a lot of inertia keeping old codecs alive, which is from "just works" that has been from merely being old and popular. There's a whole graveyard of JPEG-killers that have beaten it on features and compression. GIF isn't even "good enough" technically, and it still refuses to die, because it's just so old to be universally supported. JPEG XL hasn't done the legwork yet to be everywhere, and isn't old enough yet to be everywhere including old software. • Browser vendors' default resistance to ever-growing complexity of the platform, code size, and attack surface. I think JPEG XL's ability to be both non-Web editing format and Web format is actually working against it here, because the Web platform doesn't want non-Web features. Browsers haven't even implemented AVIF as specced, only a bare minimum subset. JPEG XL doesn't have a minimal subset.
- JyrkiAlakuijala 4y ago
- pdntspa 4y agoYay, more "fuck the long tail" from lazy-ass Google developers. Google has a gigantic pile of money. They can afford to keep JPEG XL support.
- ogogmad 4y agoTake note: This sort of abusive comment is not persuasive. If somebody spoke that way to me, I would not listen to their suggestions, if only out of sheer spite. Why is this manner of speaking so common?
- pdntspa 4y agoThis is how people actually talk. Maybe not in the gentrified ivory towers of large tech companies, but out here on the ground floor.... This "we think supporting option X is too much work" is just corporate cost-cutting translated into developer-speak that is persuasive to those with no concept of history or user-centricity People want options and they want diversity. How much maintenance is a JPEG XL decoder in the grand scheme of Chrome's codebase? Especially when it seems to be largely finished? Although maybe I should have put "lazy-ass product managers" instead.
- M1ch431 4y agoYou're ignoring what the commenter is addressing: a corporation, and a particularly insidious one at that. It's easy to feel powerless and frustrated in a world where corporations (in this case a blatant monopoly) make decisions that affect people's lives. Without a second thought, because they arbitrarily deem it harmful to their profits or wasting their human resources. Good will... serving the public interest? Only if it's profitable or works towards the corporation's collective interests. And it's not democratic: I can't propose or participate in a vote to overturn something that a corporation does or decides that affects my life. A Google employee couldn't even do that: Google is under no obligation to follow what their employees decide. I can adapt, change my habits, even boycott Google; but ultimately my power as a citizen is limited because I lack the most important elements to affect change in this world: very big piles of money and influence. It seems that Google's developers are merely cogs in the machine (see: the Stadia fiasco). So I'm sure the commenter was mainly directing their frustration to Google. If Google's employees had a voice, surely Google would have a support department that handles Google's various services? How would you feel if countless people are despairing because the service you developed/worked on isn't serving them properly? Locked out of your Gmail and recovery methods don't work? Google flagged your domain for so-called abuse? Take to Twitter if you're a celebrity or well-connected and beg for support, or if not: get fucked. Google is not a good company, and desperately needs regulated. This manner of speaking is common because not everybody is born with a silver spoon, or is able or willing to take on an enormous amount of debt to obtain a degree that may or may not pan out into a career that uplifts them out of poverty.
- fleddr 4y ago"We don't like to implement JPEG XL because this takes code, although barely so since we import a library. Also, we saw little usage in our own browser in which it is actually disabled by default."
- ZeroGravitas 4y agoIf I was king of the web, AVIF wouldn't have been added and JPEG XL would. Having said that, AVIF did get added and I don't think having some kind of process for adding new image formats beyond "it exists and is better" is a bad thing. Ideally all the big players would come together and settle on one. This kind of happened for AV1 video, so it's a shame that as a side effect of that AVIF got added before JPEG XL and split the potential momentum for a next generation image codec in two. That feels like a mistake that it's not too late to revert though.