macOS 14 will support JPEG XL • Hacker News Board

Re: macOS 14 will support JPEG XL

#101

Post by coldtea » Tue, Jun 06, 2023, 9:12 AM UTC

sparker72678 wrote: post #64

coldtea wrote: post #61

Earlier quoted context omitted.

> As a mirrorless photographer who wants to publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL. As if people would have the screen to properly watch them? Perhaps a handful of high-end laptop owners... Except if those are the intended audience. > image codecs are definitely a userspace thing and as a Windows or Linux user I never wait for my OS to support an image format, I j…

There are hundreds of millions of recent iPhones with outstanding OLED displays out there.

Is your audience iPhone users? Or is it an progressive enhacement style thing?

(Btw, there's nothing about this that's specific to mirrorless and wouldn't also apply to a DSLR with big dynamic range).

Re: macOS 14 will support JPEG XL

#102

Post by PaulHoule » Tue, Jun 06, 2023, 1:52 PM UTC

coldtea wrote: post #101

sparker72678 wrote: post #64

Earlier quoted context omitted.

There are hundreds of millions of recent iPhones with outstanding OLED displays out there.

Is your audience iPhone users? Or is it an progressive enhacement style thing? (Btw, there's nothing about this that's specific to mirrorless and wouldn't also apply to a DSLR with big dynamic range).

I'll go on the record and say that, unlike audio, where I'd be very concerned about the quality of speakers, I am not so concerned about the screen quality where my photographs are displayed. That is, even my Android Go device is "good enough" in that if you really need to see more detail you can zoom in.

A better comparison with audio would be the terrible quality of a 64 kbps Mp3 file which is going to sound awful on the cheapest bluetooth speakers or a $5000 set of speakers compared to 128 kbps Mp3 which sounds OK superficially but falls apart when compared to the source CD, or higher bit rates which are close to transparent. Many images for the web are highly compressed but nobody really notices.

My current boggle w/ screens is actually what to do with "high color gamut" screens like the one on my iPad. I am into red-cyan anaglyph images where the most important thing is getting separation between the left and right channels.

https://en.wikipedia.org/wiki/Anaglyph_3D

The green in a high color gamut display is more saturated than the sRGB primary so when you ask for sRGB green you get some red and blue mixed in which is an absolute disaster for a stereogram.

The answer to this is to master a high color gamut image just for those devices and serve everyone else an sRGB. I will get around to it one day but it's been a higher priority for me to deal with the same problem in print, where the green on my printer is very saturated but also very dark and the color management system blends in some red to make it brighter. Turning off color management works but really I should be blending in some red into green areas of the left image because that will make the colors closer to the original and also help with stereo imaging by reducing the difference in brightness between the left and right channels.

Re: macOS 14 will support JPEG XL

#103

Post by account42 » Tue, Jun 06, 2023, 2:00 PM UTC

cjawdb wrote: post #65

jez wrote: post #31

Earlier quoted context omitted.

> I sincerely hope this might make Chrome change its mind. I take this to suggest that Chrome actively decided against implementing JPEG XL? Did they consider supporting it and reject support for it, or has it simply not been prioritized, but still might be prioritized one day? If the decision was intentional: did they state a reason why?

This is the terrible explanation they gave for dropping support: https://bugs.chromium.org/p/chromium/issues/detail?id=117805... "Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue expe…

WebP and libwebp/cwebp is such a clusterfuck. Lossless mode isn't even visually lossless because cwebp doesn't understand how PNGs encode color space information. Default lossy settings are extremely garbage for darker (parts of images) images - a problem that has plagued video codecs (which is what webp is based on) for a long time. Animated webp is ridiculously inefficient compared to webm and really shouldn't be a thing at all in favor of allowing silent+looping videos in image tags. And of course initial webp browser implementations don't even support animated webp but still claim support for image/webp so you can't even do progressive enhancement from gif to animated webp without hardcoding which browsers support what.

At this point it should really just be deprecated in favor of JPEG XL. And let's skip AVIF completely please.

Re: macOS 14 will support JPEG XL

#104

Post by account42 » Tue, Jun 06, 2023, 2:02 PM UTC

DannyBee wrote: post #74

derefr wrote: post #34

Earlier quoted context omitted.

They did all the work required to implement it, sat around for a few months, and then removed it , before anyone else even noticed it was there / had a chance to start integrating it. My personal conspiracy theory is that some Google engineer who works on Chrome, came up with "JPEG XL support" as a feature they could work on, pushed it through to prod, patted themselves on the back, and forgot about it; but this was…

The number of people in this thread pretending they have more expertise about this, and spreading random conspiracy theories about WebP, is impressive. Actually, Google employs 2 of the 3 main authors of the JPEG XL spec, and the main contributors to libjxl. Also, it wasn't a few months, and others had explicitly said no. You can argue it was a dumb decision, but like, can we at least get facts straight instead of ma…

Companies participating in standards bodies while actively sabotaging the standards is nothing new.

Re: macOS 14 will support JPEG XL

#105

Post by account42 » Tue, Jun 06, 2023, 2:08 PM UTC

vetinari wrote: post #100

jeffbee wrote: post #23

Earlier quoted context omitted.

Can you explain to the rest of us what about JPEG XL applies to that use case? If you asked me to store lossless, 16-bit (per channel, or monochrome, I am assuming) images I would suggest TIFF.

TIFF is a container, it can have payload with different compression schemes, lossy or lossless. Including JXL.

TIFF can be used as a container. It also comes with its own (relatively shitty) compression methods which is probably what you'd end up using if you wanted 16-bit TIFFs today.

And TIFF as a container for JXL would no less require JXL adoption than plain JXL.

Re: macOS 14 will support JPEG XL

#106

Post by saltminer » Tue, Jun 06, 2023, 2:12 PM UTC

PaulHoule wrote: post #102

coldtea wrote: post #101

Earlier quoted context omitted.

Is your audience iPhone users? Or is it an progressive enhacement style thing? (Btw, there's nothing about this that's specific to mirrorless and wouldn't also apply to a DSLR with big dynamic range).

I'll go on the record and say that, unlike audio, where I'd be very concerned about the quality of speakers, I am not so concerned about the screen quality where my photographs are displayed. That is, even my Android Go device is "good enough" in that if you really need to see more detail you can zoom in. A better comparison with audio would be the terrible quality of a 64 kbps Mp3 file which is going to sound awful…

> Many images for the web are highly compressed but nobody really notices.

Or they do but they just assume that's the way things are. They don't know why an image that's been reposted from Facebook to Twitter to Instagram to Reddit to Imgur and back a dozen times has artifacting and color banding, and as long as they can still get the gist of the image, it doesn't matter to them. Besides, it's not like they can just ask the platform to magically fix the image, so they just don't think about it.

In many cases, the original high quality source has been lost to 404s and unpaid webhosting bills. The original is probably still on someone's hard drive, but it's unlikely to be remembered, much less surface again, so compressed messes are all that's left.

With JPEG XL, many of those compressed messes would be much closer to the original image due to its extremely strong generational loss resilience (see the webm attachment to [0]).

JPEG XL is a massive step forward for images on the web for a number of reasons, but it has especially massive benefits when it comes to preserving image quality across the web. And this is especially true when you consider that you can reversibly reencode the billions of existing JPEGs on people's drives and on the web as JPEG-XLs losslessly for 20+% space savings [0].

[0]: https://bugs.chromium.org/p/chromium/issues/detail?id=117805...

Re: macOS 14 will support JPEG XL

#107

Post by account42 » Tue, Jun 06, 2023, 2:20 PM UTC

adgjlsfhk1 wrote: post #91

zamadatix wrote: post #8

Earlier quoted context omitted.

Could you explain how so? JPEG XL seems cool enough but what about e.g. AVIF makes it "just a passive delivery format" instead of a general-purpose image format? It handles color spaces, lossless, lossy, up to 12 bit, up to 4:4:4/RGB, transparency, and animation at a good quality/size ratio so what's so drastically different about JPEG XL to move them to separate categories?

the tldr is that video formats are relationship mediocre for images because the tradeoffs you make to compress an image that will be seen for 1/60th of a second are different than those for a static image.

Your point is not wrong in general but I want to nitpick that webp and avif are based on video compression techniques for I-frames which while themselves only shown for a single 1/FPS duration will impact a longer time slice of the video as other frames will reference them.

Re: macOS 14 will support JPEG XL

#108

Post by vbezhenar » Tue, Jun 06, 2023, 2:25 PM UTC

computerbuster wrote: post #56

vbezhenar wrote: post #20

Earlier quoted context omitted.

Does it really matter? These days decoding image with JS or Wasm should be fine. It's not video.

https://giannirosato.com/blog/post/nvenc-v-qsv/ This site has WASM-decoded JXL images using JXL.js. Native support would be much faster, & trying to decode much larger images with JXL.js doesn’t work very well.

What do you mean by "much faster"? Those images are opened pretty much instantly both in desktop chrome and in iOS chrome. If you didn't mention that they're JXL, I would never notice that.

Re: macOS 14 will support JPEG XL

#109

Post by account42 » Tue, Jun 06, 2023, 2:29 PM UTC

DannyBee wrote: post #73

cjawdb wrote: post #68

Earlier quoted context omitted.

More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp. The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity…

You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere. "and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp." Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl. The main autho…

> Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?

It's not the expertise of your employer that is in question but the morals.

Re: macOS 14 will support JPEG XL

#110

Post by cjawdb » Tue, Jun 06, 2023, 3:02 PM UTC

account42 wrote: post #103

cjawdb wrote: post #65

Earlier quoted context omitted.

This is the terrible explanation they gave for dropping support: https://bugs.chromium.org/p/chromium/issues/detail?id=117805... "Thank you everyone for your comments and feedback regarding JPEG XL. We will be removing the JPEG XL code and flag from Chromium for the following reasons: - Experimental flags and code should not remain indefinitely - There is not enough interest from the entire ecosystem to continue expe…

WebP and libwebp/cwebp is such a clusterfuck. Lossless mode isn't even visually lossless because cwebp doesn't understand how PNGs encode color space information. Default lossy settings are extremely garbage for darker (parts of images) images - a problem that has plagued video codecs (which is what webp is based on) for a long time. Animated webp is ridiculously inefficient compared to webm and really shouldn't be a…

100% agree. I'd say JXL is going to be the closest thing we get to a universal image format for quite some time. Almost completely superior to JPEG/PNG/GIF/WebP/etc. and clearly superior to AVIF in basically every way except very low bitrates and animation (which... just use HTML5 video with AV1 webms, what are you even doing?).

Oh, and adoption rates, but considering JXL's standard was finalized less than a year ago and it's already gotten support in so many things and from so many large companies, I really don't see any way that it fails other than Google abusing their monopolistic position in the browser engine space. The people arguing against adding support for a brand new codec because it doesn't magically have 100% support is circular reasoning and feels very disingenuous considering WebP and AVIF were never held to the same standard.