[HN Gopher] macOS 14 will support JPEG XL
___________________________________________________________________
macOS 14 will support JPEG XL
Author : biggestfan
Score : 162 points
Date : 2023-06-05 19:23 UTC (3 hours ago)
(HTM) web link (twitter.com)
(TXT) w3m dump (twitter.com)
| masswerk wrote:
| Finally, a good reason to upgrade (again).
| slig wrote:
| Is there a specific reason why this has to be a OS update
| thing? I know that it's likely that they don't update the emoji
| font outside major OS updates so people have an extra reason to
| update.
| twotwotwo wrote:
| I hope it shows up in Safari and that this sign of interest from
| others gets it a second shot in Chrome.
|
| Just the JPEG recompression is arguably worth the price of entry;
| it's less savings than AVIF, of course, but it's easier to adopt
| _now_ , where re-encoding everything as AVIF is a much larger
| hump to get over. Its other modes provide some real benefits for
| users for very-high-quality and lossless images as well as any
| situation where progressive display helps. For folks producing
| images, is much easier to fit in than AVIF for anyone who needs
| to encode a lot on the CPU.
| amoerie wrote:
| As a radiology software developer: please please let JPEG XL
| become a thing. I sincerely hope this might make Chrome change
| its mind. JPEG XL is a game changer for 16 bit lossless images.
| The technical landscape for these kinds of images today is
| barren.
| bick_nyers wrote:
| Ex-radiology software developer here, and seconded! J2K is
| good, but here are some advantages of JXL in the context of
| medical imaging:
|
| - 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)
| jez wrote:
| > 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?
| csnover wrote:
| From April: https://arstechnica.com/gadgets/2023/04/free-
| software-group-...
|
| Discussed several times previously on HN:
|
| https://news.ycombinator.com/item?id=35589179
|
| https://news.ycombinator.com/item?id=33399940
|
| https://news.ycombinator.com/item?id=33563378
| derefr wrote:
| 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 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.
| asddubs wrote:
| it was also only ever hidden behind a flag
| vbezhenar wrote:
| Does it really matter? These days decoding image with JS or
| Wasm should be fine. It's not video.
| bick_nyers wrote:
| Video is not lossless, a second of high quality video might
| be a total of 5 megabytes.
|
| 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.
| crazygringo wrote:
| Images are opened and used in a lot of places that aren't
| browsers.
| kstrauser wrote:
| I am suuuper ignorant on the subject, but is this something
| that could replace DICOM?
| PaulHoule wrote:
| 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.
| kps wrote:
| As an 'operating system' OS X includes user space tools like
| the Finder and Quick Look in particular where vendor support
| is helpful.
| asddubs wrote:
| also crucially, safari
| lucideer wrote:
| 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".
| woah wrote:
| 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?
| ianlevesque wrote:
| A canvas element is not as performant as an image element.
| PaulHoule wrote:
| 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.
| cameldrv wrote:
| 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.
| jeffbee wrote:
| 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.
| lonjil wrote:
| I think they want better compression. JXL has excellent
| lossless compression.
| [deleted]
| captainmarble wrote:
| Google always need a push from another tech giants to do
| something right like chatgpt did.
| qingcharles wrote:
| And Google just (sadly) pulled support from Chrome.
|
| Your move, Google.
| iamakulov wrote:
| Relevant thread, for those who're curious:
| https://bugs.chromium.org/p/chromium/issues/detail?id=117805...
| pacetherace wrote:
| Can't it be enabled via an extension? Similar to how media
| players support third party codec.
| iamakulov wrote:
| Not really.
|
| AFAIK (correct me if I'm wrong!) first-party and third-party
| codecs in media players are kinda equal: you load a file, and
| the media player picks which codec to delegate that file to.
| You can't do that in with a Chrome extension - the extensions
| can manipulate HTML and run custom JS, but that's more or
| less it (plus some basic browser-level stuff like work with
| tabs and intercept network requests).
|
| This doesn't mean an extension isn't possible at all - eg
| there's https://github.com/zamfofex/jxl-crx/ that detects JXL
| images and decodes them with JS - but that's slower.
|
| Plus the bigger issue is adoption. You want _all_ users to
| get your JPEG XL images, not just the 0.1% of users that
| installed the extension.
| [deleted]
| zamadatix wrote:
| Firefox came to the conclusion they didn't really care too so
| it's not just Google that is iffy about it. With Apple pushing
| it now... maybe that will change things in the long run?
| chungy wrote:
| With the only justification being "nobody wanted it", a plainly
| false statement.
|
| WebP isn't good enough. AVIF isn't good enough. JPEG XL is good
| enough.
| bitwize wrote:
| Now that Apple supports it, people will want it.
| Gigachad wrote:
| Their justification was more that adding it would be
| committing a lot of hardware and software vendors to support
| it which would be very expensive for not enough gain.
| lonjil wrote:
| > Their justification was more that adding it would be
| committing a lot of hardware
|
| Which is completely nonsensical. Hardware support is
| meaningless for web images.
| pgeorgi wrote:
| Hardware accelerated handling was one of the arguments
| used to oppose a WASM based implementation that sites
| could use at will to prove that there's demand for JPEG-
| XL support (and that the Chrome team provides, by the
| way).
| jbverschoor wrote:
| Google is using the wrong tricks to keep marketshare.. I'm
| not even sure if they know it
| kps wrote:
| Excellent. JPEG XL is a usable general-purpose image format, not
| just a passive delivery format like WebP and AVIF.
| zamadatix wrote:
| 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?
| kps wrote:
| I think 12-bit colour stops it being adopted for 'master'
| images intended for editing. The current top comment says
| that 16-bit depth is a requirement for radiology. Also, I've
| read that its lossless encoding is often very poor -- larger
| than PNG.
|
| (I didn't downvote, BTW; it's a reasonable question.)
| ajconway wrote:
| AVIF does not support progressive encoding.
| zamadatix wrote:
| Assuming you meant "de"coding: it does, albeit I like JPEG
| XL's more. To me, that point seems an argument for things
| being the other way around anyways (i.e. general-purpose
| but not a good delivery format).
| Dylan16807 wrote:
| > Assuming you meant "de"coding
|
| Is there something wrong with the other phrasing? You
| need to have a progressively encoded image before you can
| decode it progressively.
| ajconway wrote:
| I stand (partially) corrected:
| https://github.com/AOMediaCodec/libavif/pull/640
___________________________________________________________________
(page generated 2023-06-05 23:02 UTC)