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.
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".
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)
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.
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.
Come on, people.
Any comparision photos out there?
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...
(Btw, there's nothing about this that's specific to mirrorless and wouldn't also apply to a DSLR with big dynamic range).
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.
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...
- Better compression ratios
- Ability to modify effort of lossless compression (good for real time transcoding)
- Multi-threaded encode and decode
- Far superior progressive decoding (great for low bandwidth scenarios, just stream in the lossless quality over time)
If things with Apple go well and JPEG XL is supported natively on macOS, iOS and iPadOS this fall, it would be on its way to becoming a thing.
After all, 2 billion devices isn't nothin’.
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?
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 experimenting with JPEG XL
- The new image format does not bring sufficient incremental benefits over existing formats to warrant enabling it by default
- By removing the flag and the code in M110, it reduces the maintenance burden and allows us to focus on improving existing formats in Chrome"
The issue on the Chromium tracker is now one of the most-starred and most-commented-on of all time because people from all over came to tell Google that they're insane, from Intel to Adobe to Facebook to Krita to Cloudinary to Shopify to Serif/Affinity to the VESA DisplayHDR Chairman.
It may also be worth noting that the author of commit to remove support from Chromium appears to be a WebP co-author, having given talks about WebP and being the primary contributor to libwebp.
https://chromium-review.googlesource.com/c/chromium/src/+/40...
At this point it should really just be deprecated in favor of JPEG XL. And let's skip AVIF completely please.
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.
You say that now, try doing that between 2020 all the way to 2022 you get attacked by AOM Strike Force.
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 all done without first getting sign-off from whoever at Google is trying to push for WebP to be a thing. When that person or group noticed "Chrome now supports JPEG XL", they got that support ripped out.
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 making up random stories?
There people in this thread arguing they have no idea what they are doing and have no expertise, while they simultaneously employ the spec authors to work on it and are one of the two primary contributors to the reference library.
A bit silly and incongruous.
Just because someone does something you don't like doesn't make them stupid or wrong. You'd be much better off if you would gather facts first, listen to the perspectives of others, and then respond.
> There people in this thread arguing they have no idea what they are doing and have no expertise, while they simultaneously employ the spec authors to work on it and are one of the two primary contributors to the reference library.
Google is not a monolith. The JXL people are at Google Research Zurich, while the people who decided to not include JXL in Chrome are members of the Chrome team. The Chrome team obviously does not employ the people over in Zurich, nor do they presumably control what they work on.
And much like Microsoft, I will put any research arm of a company as a separate company.
[1] http://storage.googleapis.com/avif-comparison/index.html
JPEG XL has gained broader industry interest than any of the previous attempts to replace JPEG.
I think someone is very hurt that their web p pet project has earned more hate than love
Discussed several times previously on HN:
https://news.ycombinator.com/item?id=35589179
Yes It was intentional.
They stated AVIF is as good if not better than JPEG XL.
And TIFF as a container for JXL would no less require JXL adoption than plain JXL.
A mammogram on the other hand, might be 300 images of lossless 4k resolution, which could clock in at about 2 gigabytes. That could be per breast in a given study, and a study could have prior mammograms attached as well.
You will hit memory limits, so you need to be able to unload and load data intelligently and quickly.
Especially handy that it wouldn't require a new file format. It only requires the encoder to support variable compression. (I know Photoshop supported this for JPEG many decades ago.)
Foveated compression sounds like a super cool idea I've never thought about before.
Before that, you would need to get radiologists onboard with the idea of something being "diagnostically lossless" (think visually lossless), which is currently a hard sell (some promising research does exist on this)!