13 ms·
Instead of using a new PNG standard, I'd still rather use JPEG XL just because it has progressive decoding. And you know, whilst looking like png, being as smal
by e-topy 1y ago
Instead of using a new PNG standard, I'd still rather use JPEG XL just because it has progressive decoding.
And you know, whilst looking like png, being as small as webp, supporting HDR and animations, and having even faster decoding speed.
https://dennisforbes.ca/articles/jpegxl_just_won_the_image_wars.html https://dennisforbes.ca/articles/jpegxl_just_won_the_image_w...
- jchw 1y agoJPEG XL definitely has advantages over PNG but there is one serious seemingly insurmountable obstacle: https://caniuse.com/jpegxl https://caniuse.com/jpegxl Nothing really supports it. Latest Safari at least has support for it not feature-flagged or anything, but it doesn't support JPEG XL animations. To be fair, nothing supports a theoretical PNG with Zstandard compression either. While that would be an obstacle to using PNG with Zstandard for a while, I kinda suspect it wouldn't be that long of a wait because many things that support PNG today also support Zstandard anyways, so it's not a huge leap for them to add Zstandard support to their PNG codecs. Adding JPEG-XL support is a relatively bigger ticket that has struggled to cross the finish line. The thing I'm really surprised about is that you still can't use arithmetic coding with JPEG. I think the original reason is due to patents, but I don't think there have been active patents around that in years now.
- bawolff 1y ago> The thing I'm really surprised about is that you still can't use arithmetic coding with JPEG. I was under the impression libjpeg added support in 2009 (in v7). I'd assume most things support it by now.
- jchw 1y agoBelieve it or not, last I checked, many browsers and some other software (file managers, etc.) still couldn't do anything with JPEG files that have arithmetic coding. Apparently, although I haven't tried this myself, Adobe Photoshop also specifically doesn't support it.
- superjan 1y agoArithmetic coding decodes 1 bit at a time, usually in such a way that you can’t do two bits or more with SIMD instructions. So it will be slow and energy inefficient.
- adgjlsfhk1 1y agothis isn't necessarily true. zstd uses an ans which is a type of arithmetic coding which is very efficient to decode
- superjan 1y agoNice to learn about. It’s good to know the field has progressed, however the context focused on JPEG, where my point does apply.
- astrange 1y agoDeompression is limited by memory bandwidth IME, which means that more efficient compression is (almost) always more power-efficient too. (I don't have numbers for this, but it was generally agreed by the x264 team at one point.)
- kps 1y ago> Nothing really supports it. Everything supports it, except web browsers.
- jchw 1y agoJPEG-XL is supported by a lot of the most important parts of the ecosystem (image editors and the major desktop operating systems) but it is a long way away from "everything". Browsers are the most major omission, but given their relative importance here it is not a small one. JPEG-XL is dead in the water until that problem can be resolved. If Firefox is anything to go off of, the most rational explanation here seems to just be that adding a >100,000 line multi-threaded C++ codebase as a dependency for something that parses untrusted user inputs in a critical context like a web browser is undesirable at this point in the game (other codecs remain a liability but at least have seen extensive battle-testing and fuzzing over the years.) I reckon this is probably the main reason why there has been limited adoption so far. Apple seems not to mind too much, but I am guessing they've just put so much into sandboxing Webkit and image codecs already that they are relatively less concerned with whether or not there are memory safety issues in the codec... but that's just a guess.
- swiftcoder 1y agoApple also adopted JPEG-XL across their entire software stack. It's supported throughout the OS, and by pretty much every application they develop, so I'm guessing they sunk a fair bit of time/money into hardening their codec
- floxy 1y ago> >100,000 line multi-threaded C++ W. T. F. Yeah, if this is the state of the reference implementation, then I'm against JPEG-XL just on moral grounds.
- lifthrasiir 1y agoOnly because it's both the reference encoder and decoder, and the encoder tends to be a lot more complex than the decoder. (Source: I have developed a partial JPEG XL decoder in the past, and it was <10K lines of C code.)
- Zardoz84 1y agoYou can use a polyfill.
- greenavocado 1y agoThat's because people have allowed the accumulation of power and control by Big Tech. Features in and capabilities of end user operating systems and browsers are gate kept by a handful of people in Big Tech. There is no free market there. Winners are picked by politics, not merit. Switching costs are extreme due to vendor lock in and carefully engineered friction. The justification for WebP in Chrome over JPEG-XL was pure hand waving nonsense not technical merit. The reality is they would not dare cede any control or influence to the JPEG-XL working group. Hell the EU is CONSIDERING mandatory attestation driven by whitelisted signed phone firmwares for certain essential activities. Freedom of choice is an illusion.
- google234123 1y agoWebp is a lot older than jpg xl, right?
- spookie 1y agoIt was behind a feature flag and then removed? I guess that's where the skepticism comes from
- 01HNNWZ0MV43FF 1y agoIt's also because supporting features is work that takes time away from other bug fixes and other features
- IshKebab 1y ago> I kinda suspect it wouldn't be that long of a wait Yeah... guess again. It took Chrome 13 years to support animated PNG - the last major change to PNG.
- Scaevolus 1y agoEvery new image codec faces this challenge. PNG + Zstandard would look similar. The ones that succeeded have managed it by piggybacking off a video codec, like https://caniuse.com/avif https://caniuse.com/avif.
- jchw 1y agoWhy would PNG + ZStandard have a harder time than AVIF? In practice, AVIF needs more new code than PNG + ZStandard would.
- junon 1y agoI'm just guessing, but bumping a library version to include new code cam integrating a separate library might be the differentiating factor.
- jchw 1y agoThe zstd library is already included by most major browsers since it is a supported content encoding. Though I guess that does leave out Safari, but Safari should probably support Zstd for that, too. (I would've preferred that over Brotli, but oh well.)
- eru 1y agoBtw, could you 'just' use no compression on this level in the PNG, and let the transport compression handle it? So on paper (and on disk) your PNG would be larger, but the number of bits transmitted would be almost the same as using Zstd? EDIT: similarly, your filesystem could handle the on-disk compression. This might work for something like PNG, but would work less well for something like JPG, where the compression part is much more domain specific to image data (as far as I am aware).
- jchw 1y agoIf there is a particular reason why that wouldn't work, I'm not aware of it. Seems like you would eat a very tiny cost for deflate literal overhead (a few bytes per 65,535 bytes of literal data?) but maybe you would wind up saving a few bytes from also compressing the headers.
- breve 1y ago> but there is one serious seemingly insurmountable obstacle It can be surmounted with WebAssembly: https://github.com/niutech/jxl.js/ https://github.com/niutech/jxl.js/ Single thread demo: https://niutech.github.io/jxl.js/ https://niutech.github.io/jxl.js/ Multithread demo: https://niutech.github.io/jxl.js/multithread/ https://niutech.github.io/jxl.js/multithread/
- qcnguy 1y agoMaybe for websites like Instagram that consist primarily of images. For everywhere else you have to amortize the cost of the download over the savings for the number of images in an average browsing session, as browsers segment the cache so you can't assume it will be available locally hot.
- riedel 1y agoActually I wonder, why in general not more decoders are just put into webassembly and are actually kept 'hot' on demand. Couldn't this also be an extension? Wouldn't that reduce the attack surface? I remember a time when most video and flash was a plugin. People would download the stuff. On the other hand using a public CDN at least would keep the traffic down for the one hosting the website.
- qcnguy 1y agoBrowser makers could easily let resources opt out of cache segmentation and then if everyone agreed on a CDN, or a resource integrity hash of a decoder, the wasm could be hot in the cache and used to extend the browser without Chrome needing to maintain it or worry about extra sandboxing. They don't do it because they don't want people extending the web platform outside their control.
- fluidcruft 1y agoAs I understand it JPEG XL has a lot of interest in medical imaging and is coming to DICOM. After it's in DICOM, whichever browser supports it best will rule hospitals.
- umvi 1y agoHa, yeah right, hospitals are still running IE11 in some places in the US
- philipallstar 1y agoYes, you're right. It'd be lovely to not need to install a DICOM viewer plugin thing.
- ryao 1y agoJPEG XL support will probably resemble JPEG 2000 support after enough time has passed: https://caniuse.com/jpeg2000 https://caniuse.com/jpeg2000
- account42 1y agoExcept JXL has actual value unlike J2K which wasn't that much more efficient than JPEG and much slower.
- ryao 1y agoSo far, it is following the same pattern. Safari adopts it, no one else does and then one day, Safari drops it. It is currently on step 2. When step 3 occurs, the cycle will be complete.
- JyrkiAlakuijala 1y agoexcept DNG, ProRAW, DICOM, GDAL, TIFF, Apple's and Microsoft's operating systems, Linux distros, and Windows support JPEG XL otherwise the same
- ryao 1y agoLook at the caniuse.com links. It is following the same pattern as JPEG 2000 in those charts. That is a fact.
- BrenBarn 1y agoIt's better when the way it works is "this is format is good, therefore we will support it" rather than "people support this format, therefore it is good".
- deleted 1y ago[deleted]
- a-french-anon 1y ago>he thing I'm really surprised about is that you still can't use arithmetic coding with JPEG Or AVC YUV44 with Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1368063 https://bugzilla.mozilla.org/show_bug.cgi?id=1368063). Fortunately, AV1 YUV444 seems to be supported.
- JyrkiAlakuijala 1y agoPNG with ZStandard or Brotli is much worse than WebP lossless.
- bawolff 1y agoDoesn't PNG have progressive decoding? I.e. adam7 algorithm
- layer8 1y agoIt does, using Adam7: https://en.wikipedia.org/wiki/Adam7_algorithm https://en.wikipedia.org/wiki/Adam7_algorithm The recently released PNG 3 also supports HDR and animations: https://www.w3.org/TR/png-3/ https://www.w3.org/TR/png-3/
- bawolff 1y ago> The recently released PNG 3 also supports HDR and animations: https://www.w3.org/TR/png-3/ https://www.w3.org/TR/png-3/ APNG isn't recent so much as the specs were merged together. APNG will be 21 years old in a few weeks.
- layer8 1y agoTrue, but https://news.ycombinator.com/item?id=44802079 https://news.ycombinator.com/item?id=44802079 presumably holds the opinion that APNG != PNG, so I mentioned PNG 3 to counteract that. Animated PNGs being officially PNG is recent.
- duskwuff 1y agoAdam7 is interlacing, not progressive decoding (i.e. it cannot be used to selectively decode a part of the image). It also interacts extremely poorly with compression; there is no good reason to ever use it.
- adzm 1y agoWeb browsers already have code in place for webp (lossless,vp8) and avif (av1, which also supports animation), as well as classic jpeg and png, and maybe also HEIC (hevc/h265)... what benefit do we have by adding yet another file format if all the use cases are already covered by the existing formats? That said, I do like JPEG-XL, but I also kind of understand the hesitation to adopt it too. I imagine if Apple's push for it continues, then it is just a matter of time to get supported more broadly in Chrome etc.
- Dylan16807 1y agoAvif is cute but using that as an excuse to not add jxl is a travesty. At the time either one of those could have been added, jxl should have been the choice. The biggest benefit is that it's actually designed as an image format. All the video offshoots have massive compromises made so they can be decoded in 15 milliseconds in hardware. The ability to shrink old jpegs with zero generation loss is pretty good too.
- eviks 1y agoThe benefits are better quality, higher speed, and more features like progressive decoding. JXL is a single multi-trick pony unlike the others Good summary https://cloudinary.com/blog/time_for_next_gen_codecs_to_dethrone_jpeg https://cloudinary.com/blog/time_for_next_gen_codecs_to_deth...
- porphyra 1y agoI don't like progressive decoding. Lots of people don't realize that it's a thing, and complain that my photo is blurry when it simply hasn't loaded fully yet. If it just loaded normally from top to bottom, it would be obvious whether it has loaded or not, and people will be able to more accurately judge the quality of the image. That's why I always save my JPEGs as baseline encoding.
- eviks 1y agoIs there no good progress indicator that gets you the best of both worlds - instant image recognition and the ability to wait and get better quality?