Live data from Hacker News

Google unkills JPEG XL?

tonisagrista.com

201–210 of 283 posts

Re: Google unkills JPEG XL?

#201
post #183
post #152

Earlier quoted context omitted.

> and another that wanted to create the platform on which Microsoft Word could be built. Apparently they failed. The web version of Word is still far from having feature parity. Of course doc is one of those everything and the kitchen sink formats, so implementing it on top of a platform that was originally intended to share static documents is kind of a tall order.

that's just microsoft not being good. Google Docs exists and is pretty good.

OnlyOffice is HTML5-based too

Re: Google unkills JPEG XL?

#202
One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched.

Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG.

Only know this because we have tens of PBs in their DICOM store and stand to save a substantial amount of $ on an absurdly large annual bill.

Native browser support is on our wishlist and our contacts indicate the chrome team will get there eventually.

Re: Google unkills JPEG XL?

#203
post #156

It looks very likely chromium will be using jxl-rs crate for this feature [0]. My personal suspicion is that they've just been waiting for it to good enough to integrate and they didn't want to promise anything until it was ready (hence the long silence). [0] https://issues.chromium.org/issues/40168998#comment507

That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are. PS: I'm a bit too sle…

> The only thing I'm not sure about is why they decided to reopen it.

It's almost certainly due to the PDF Association adding JPEG XL as a supported image format to the ISO standard for PDFs; considering Google's 180 on JPEG XL support came just a few days after the PDF Association's announcement.

Re: Google unkills JPEG XL?

#204
Good, but mass adoption is a lot slower in sites than in browsers it seems. It's like pulling teeth making sites to actually support even AVIF which is already widely supported in browsers. A ton of inertia even on sites like GitHub and GitLab. Try using AVIF on Wikipedia? Tough luck.

Imagine how long it will take for JPEG XL that didn't even reach wide browsers support yet.

Side note - comparing JPEG XL and AVIF features wise is sort of pointless if AVIF will continue to evolve based on AV2 and etc.

Re: Google unkills JPEG XL?

#205
post #192
post #156

Earlier quoted context omitted.

That was Mozilla's stance. Google was thoroughly hostile towards it. They closed the original issue citing a lack of interest among users, despite the users themselves complaining loudly against it. The only thing I'm not sure about is why they decided to reopen it. They may have decided that they didn't need this much bad PR. Or someone inside may have been annoyed by it just as much as we are. PS: I'm a bit too sle…

It wasn't just a blatant lie for lack of interest, they also went out their way to benchmark it and somehow present it as inferior to AVIF.

IIRC they benchmarked it as "not much better" than AVIF, not inferior.

Re: Google unkills JPEG XL?

#206
post #97

Earlier quoted context omitted.

no one asked, but FYI in English it is more commmon to say "for several years" instead of "since some years" :)

German speakers usually have very good English, but this is one of their tells.

Could also be French speakers. They would say "J'utilise le format .avif depuis quelques années." I think the "depuis" throws off the French speakers when they translate that literally as "since some years" instead of "for some years".

Another common tell: I wake up in the morning in the US/Pacific time zone, and see the European writers on HN using "I have ran" instead of "I have run".

Re: Google unkills JPEG XL?

#207
post #22

A full-resolution, maximum-size JPEG XL image (1,073,741,823 × 1,073,741,824): Uncompressed: 3.5–7 exabytes Realistically compressed: Tens to hundreds of petabytes Thats a serious high-res image

An image of earth at very roughly 4cmx4cm resolution? (If I've knocked the zero's off correctly)

Each pixel would represent roughly 16cm^2 using a cylindrical equal-area projection. They would only be square at the equator though (representing less distance E-W and more distance N-S as you move away from the equator).

No projection of a sphere on a rectangle can preserve both direction and area.

Re: Google unkills JPEG XL?

#208
post #29

Earlier quoted context omitted.

The only practical way to work with such large images is if they are tiled and pyramidal anyway

what does pyramidal mean in this context?

JPEG and friends transforms the image data into the frequency domain. Regular old JPEG uses the discrete cosine transformation[1] for this on 8x8 blocks of pixels. This is why with heavily compressed JPEG images you can see blocky artifacts[2]. JPEG XL uses variable block size DCT.

Lets stick to old JPEG as it's easier to explain. The DCT takes the 8x8 pixels of a block and transforms it to 8x8 magnitudes of different frequency components. In one corner you have the DC component, ie zero frequency, which represents the average of all 8x8 pixels. Around it you have the lowest non-zero frequency components. You have three of those, one which has a non-zero x frequency, one with a non-zero y frequency, and one where both x and y are non-zero. The elements next to those are the next-higher frequency components.

To reconstruct the 8x8 pixels, you run the inverse discrete cosine transformation, which is lossless (to within rounding errors).

However, due to Nyquist[3], you don't need those higher-frequency components if you want a lower-resolution image. So if you instead strip away the highest-frequency components so you're left with a 7x7 block, you can run the inverse transform on that to get a 7x7 block of pixels which perfectly represents a 7/8 = 87.5% sized version of the original 8x8 block. And you can do this for each block in the image to get a 87.5% sized image.

Now, the pyramidal scheme takes advantage of this by rearranging how the elements in each transformed block is stored. First it stores the DC components of all the blocks the image. If you just used those, you'd get an image which perfectly represents a 1/8th-sized image.

Next it stores all the lowest-frequency components for all the blocks. Using the DC and those you have effectively 2x2 blocks, and can perfectly reconstruct a quarter-sized image.

Now, if the decoder knows the target size the image will be displayed at, it can then just stop reading when it has sufficiently large blocks to reconstruct the image near the target size.

Note that most good old JPEG decoders supports this already, however since the blocks are stored one after another it still requires reading the entire file from disk. If you have a fast disk and not too large images it can often be a win regardless. But if you have huge images which are often not used in their full resolution, then the pyramidal scheme is better.

[1]: https://en.wikipedia.org/wiki/Discrete_cosine_transform

[2]: https://eyy.co/tools/artifact-generator/ (artifact intensity 80 or above)

[3]: https://en.wikipedia.org/wiki/Nyquist%E2%80%93Shannon_sampli...

Re: Google unkills JPEG XL?

#209

"in favor of the homegrown and inferior AVIF" I am using .avif since some years; all my old .jpg and .png files have been pretty much replaced by .avif, in particular fotos. I am not saying .avif is perfect, but IMO it is much better than .jpg or .avif. I could have gone .webp or perhaps jpeg-xl but at the end of the day, I am quite happy with .avif as it is. As for JPEG XL - I think the problem here is ... Google. G…

For making compact high-quality jpeg files, consider trying jpegli[1], it does an impressive job.

More specifically, if I try a bunch of AVIF quantization options and manually pick the one that appears visually lossless, it beats jpegli, but if I select a quantization option that always looks visually lossless with AVIF, jpegli will win the average size, because I need to use some headroom for images that AVIF does less well on.

1: https://github.com/google/jpegli

Re: Google unkills JPEG XL?

#210

One of the cooler and lesser known features of JPEG XL is a mode to losslessly transcode from JPEG while achieving ~20% space reduction. It’s reversible too because the original entropy coded bitstream is untouched. Notably GCP is rolling this out to their DICOM store API, so you get the space savings of JXL but can transcode on the fly for applications that need to be served JPEG. Only know this because we have tens…

If it's reversible, why not just store as JPEG XL and then convert back when it's served? Does it take a lot of processing time?
Post reply on HN