[PaulHoule]

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. In trials I've done, AVIF works well for a throwaway splash image for a blog but compression results are not so impressive compared to JPEG or WEBP if you want the image to hold up under close inspection.

On the other hand there is something that seems almost infantile about image support in the "operating system" being pivotal. If you read a review of a new MacOS in ArsTechnica you might get the idea that 99% of an OS is about what the buttons look like but in terms of the computer science definition, 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 just install the codec and code away.

[lucideer]

You're using the term "OS" but you're not talking about OSes you're talking about kernels.

The OS is what comes with the computer or gets installed in the default setup if you're installing yourself. Most of it is userspace.

Distros like Arch & Gentoo allow you to build a custom OS which in doing so blurs the definition quite a lot, but ultimately when people say "macOS" that term includes quite a lot of userspace things. Bundled software is absolutely a core part of every popularly used definition of the word "OS".

[kps]

As an ‘operating system’ OS X includes user space tools like the Finder and Quick Look in particular where vendor support is helpful.

[asddubs]

also crucially, safari

[cameldrv]

Yes image codecs are a user space thing, but a Mac or iOS app probably loads images using the Swift Image or UIImage class and passes it a filename, and then these same objects get passed to the display widgets to render. If the UI toolkit that ships with the OS supports a format, it will just work with most all of the apps that use the system UI toolkit.

[colechristensen]

There’s just not a lot left besides user experience and appearance for an OS to do.

Of course kennels and operating systems are highly complex and represent a ton of work… but what is left to impress with a press release?

My OS does everything I can imagine needing it to and the only thing I can imagine wanting it to do going forward is more or less just maintenance (UX/UI excluded)

[woah]

Dumb question, but why is OS or browser support necessary? Couldn't an HTML canvas element and some JS that can parse the file format display any kind of image that you might want?

[spiralpolitik]

On MacOS/iOS the ImageIO framework handles encoding and decoding images. Adding support for your image format to that framework means everything else just works once the image is decoded.

Another framework, CoreImage, provides generic operations to filter and transform images decoded by ImageIO. This provides hardware acceleration and other good stuff that make things like CSS transforms super fast and efficient.

While it can be done in JavaScript it would be much much slower, less efficient, and kill your battery.

[Scaevolus]

There's a JS/WASM polyfill for JXL, but it involves some fragile hacks like MutationObserver and canvas writes, has worse performance than native code, and tends to crash Chrome.

[DaiPlusPlus]

Why would MutationObserver be necessary to display a static image in a <canvas>?

[coldtea]

Yes, if you don't care for loading speed, battery life, and the fans blazing...

[majora2007]

Canvas has hard caps on the size it can be as well and when resizing an image to a fixed size, there is a lot of hard edges as you need to implement your own smoothing. Image tag is more flexible and versatile.

[JyrkiAlakuijala]

HDR and progression are difficult to do right now. Possible interplay with CPU/GPU in rendering is difficult. JS is executed later than html is parsed.

[ianlevesque]

A canvas element is not as performant as an image element.

[PaulHoule]

When I am serious about images it is all about high performance: upgrading to better data compression (1) speeds up the network and server and reduces (2) network and (3) storage costs. (4) Decompression of the image is another bottleneck and a soft decoder is itself something to download and compile locally.

If you use a high-powered device you might not appreciate that performance of a low-end Android device hasn't really improved since 2017. I test with an Android Go device that does pretty well if you feed it scaled images but would struggle with the soft decoder.

The native implementation of the decompressor can be much better than one in WebAssembly in that it can use SIMD units on the CPU and many other tricks, including special purpose hardware. That's why Apple is so keen to say that an image format is now supported in the OS, because they codesign the hardware, the OS and the file formats to take advantage of all that.

[ShadowBanThis01]

Why down-mod this straightforward question?

Come on, people.

[est]

> publish photos on the web that look like they came out of a mirrorless camera I want JPEG XL

Any comparision photos out there?

[coldtea]

>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 just install the codec and code away.

That's how you get half the apps supporting them (if you're lucky) and others not, and generally a hell of a time...

[sparker72678]

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

[coldtea]

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).

[PaulHoule]

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.

[saltminer]

> 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...