Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Request: Re-open JPEG XL issue

bugs.chromium.org

Post reply on HN
Print view View original

141–150 of 164 posts

Re: Request: Re-open JPEG XL issue

#141

Post by chungy »

wpm wrote: post #139
chungy wrote: post #81

Earlier quoted context omitted.

Dreadful where? In this day and age, WebP is supported by every browser, I can browse them comfortably in my file manager and basically every image-related program can open and edit them (I'm running GNOME on Arch). Where is it lacking? I'm not a fan of WebP, mind, but the idea that support for it is dreadful is strange to me.

I think was less than a year ago that OBS got support for webp. Just about the same for Photoshop. Plenty of software still doesn’t support it or support it well. Glad your experience has been good. Personally, the fact that it was Googles idea means I’m going to hold it at arms length, if not avoid it entirely. The web should be built on open standards.

I was using WebP-lossless for quite a few years, for the subset of images I had that fit within WebP's limitations (being the 16383×16383 dimensions and 32 bpp color depth). I've recently converted everything to JPEG XL. Old JPEGs got losslessly transformed, and both PNGs and WebP-lossless into lossless JPEG XL.

Seems to be a similar level of "works everywhere" for me, with the exception of web browsers this time.

Re: Request: Re-open JPEG XL issue

#142

Post by alexflo »

karim79 wrote: post #55
PaulHoule wrote: post #30

Earlier quoted context omitted.

I switched to WebP about a year and a half ago. I’d been watching for a long time and it had finally reached the point where support was universal enough that I could not publish a JPEG. WebP has the big advantage that the quality setting is meaningful, you can set it at a certain level and then encode thousands of images and know the quality is about the same. This is by no means true about JPEG, if you are trying t…

> Years back I was concerned about the size of a large JPEG collection and recompressed them which was a big mistake because many of the images were compressed too hard. Distortion metrics[0] such as MS-SSIM, MS-SSIM*, SIMM, MSE, and PSNR can be used to define a cut-off or threshold for deciding the point at which the image is "compressed enough" by using one or more of those algorithms and predefining the amount of…

Actually this isn't accurate, Kraken.io doesn't use any SSIM-related algorithms, it just blindly applies some standard compression regardless of the image's content.

If you're looking for a tool that really smartly optimizes the images (by using SSIM) that is https://shortpixel.com/online-image-compression

Re: Request: Re-open JPEG XL issue

#143

Post by account42 »

CharlesW wrote: post #105
PaulHoule wrote: post #48

Earlier quoted context omitted.

It's a Jedi mind trick. The compression artifacts in the self-shadows of the red bit of the car to the left of the driver's head look awful to me. It's true that the compression artifact blends in pretty well and you might think the car really looks like that but personally I can't unsee things like that once I look at them in comparison. The thing is that it is that play of reflections and shadows that makes an expe…

> It's a Jedi mind trick. All compression is. :^) The additional twist is that our eyes/brains do a great job at glossing over compression artifacts that we're used to. When you expand the image, you can change the formats on both sides for A/B testing. Comparing "JPEG - 20.7 kB" to "AVIF - 18.2 kB" is an enlightening like-vs-like size comparison. I'd be happy to do an AVIF encode of a large uncompressed/losslessly c…

> Comparing "JPEG - 20.7 kB" to "AVIF - 18.2 kB" is an enlightening like-vs-like size comparison.

You can't extrapolate that comparison to higher bitrates though - so unless your use case doesn't require preserving image detail (i.e. the images might as well not be there), both formats are inadequate at that size.

Re: Request: Re-open JPEG XL issue

#144

Post by account42 »

cubefox wrote: post #76
PaulHoule wrote: post #9

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…

Here are visual comparisons between AVIF and JPEG XL on some test images with various bitrates / quality levels: https://afontenot.github.io/image-formats-comparison/#end-of... It seems AVIF has better compression at lower bit rates. At high bit rates they seem similar. AVIF especially shines for pictures with large homogeneous surfaces like the sky. However, AVIF is missing some important features, such as progressi…

Compare the AVIF with the original and you see how bad it is. You need to make the comparison at a bitrate where at least one of the format gives acceptable results.

Re: Request: Re-open JPEG XL issue

#145

Post by JyrkiAlakuijala »

CharlesW wrote: post #37
PaulHoule wrote: post #9

As a photographer I am looking forward to it. I process photos in ProPhoto RGB and I’m in the process of switching up my process to always publish images to the web as Display P3 which can be done just fine in JPEG and WEBP by attaching a color profile. Display P3 is moderately larger than the old standard sRGB; you are trading some color resolution in the “mainstream” area for more saturated greens and reds. 4K TV’s…

> And my experience is that AVIF falls down at that, it does not really save bits compared to JPEG and WEBP at high quality. In all the comparisons I've seen, it's not even a contest. "I picked this image because it's a photo with a mixture of low frequency detail (the road) and high frequency detail (parts of the car livery). Also, there are some pretty sharp changes of colour between the red and blue. And I like F1…

I don't enjoy seeing compression artefacts or blur or other loss of detail.

I don't want the internet to look like that F1 car to save a few milliseconds or $0.0000001 for the company sending the pic to me.

I certainly don't want my family photos to look like that.

I don't want the photographs on the internet to become much faster, much cheaper and much worse. I'd like them to become a bit faster, a bit cheaper, but also more crisp, vivid, emotionally engaging, and realistic.

Re: Request: Re-open JPEG XL issue

#146

Post by JyrkiAlakuijala »

cubefox wrote: post #121
networked wrote: post #111

Earlier quoted context omitted.

A recent comment ( https://news.ycombinator.com/item?id=36286548 ) made me notice chroma contamination in low-BPP JPEG XL in this comparison. Since then, I have been leaning towards adopting AVIF for medium-low-quality pictures, especially of people. (People will be unhappy if their teeth are yellowed in post-production.) I am not so sure about AVIF and the sky. A reply to the comment I have linked shows an example w…

I also noticed more chroma contamination in JPEG XL, and overall more "ringing" artifacts. Yeah, AVIF seems to remove noise fairly aggressively, or what it assumes to be noise. I think it looks pretty good in this sky example, although not overly faithful. It's less good when the removed "noise" is actual high frequency detail, e.g. on the fur of animals. But what I meant with AVIF being good at homogeneous surfaces…

The 'Large' is still relatively low quality -- you can observe this by 3x zooming and comparing to original.

You can easily see that AVIF blurs (beautifies faces) and removes properties of the red cloth in the 'end-of-show' image.

Internet average image quality is higher than the 'Large' setting, so those names are not representative of actual internet use. Camera and image processing use is even of much higher quality.

Re: Request: Re-open JPEG XL issue

#148

Post by JyrkiAlakuijala »

coldpie wrote: post #40
brucethemoose2 wrote: post #2

So, all it takes to consider a small community requested change in Chromium is a massive protest from thousands of users, small businesses, and Fortune 500 companies for almost a year... Or maybe they are just trying to keep feature parity with Safari.

Adding new image format support to a web browser is not a small change.

it adds 185 kB of compressed binary size -- probably by compressing the graphics that come along Chromium will 10x counter the added weight and it will actually save size

Re: Request: Re-open JPEG XL issue

#149

Post by JyrkiAlakuijala »

Sakos wrote: post #132
trunnell wrote: post #112

Scanning the comments here and I don't see anyone addressing the elephant in the room: PATENTS. After a bit of searching, it's unclear what degree of "patent risk" comes with JPEG XL. JPEG historically was subject to patent troll lawsuits until the patent expired in 2006. Please note that it's not enough for there to be a "royalty-free reference implementation" of JPEG XL, even if it's licensed with Apache 2.0, becau…

Apparently Microsoft was granted this patent on rANS in early 2022 ( https://patents.google.com/patent/US11234023B2/en ) and Google deprecated JPEG XL support late 2022. JPEG XL uses rANS, so I think there's some likelihood that this motivated Google to change their focus. Google didn't mention anything about this in their reasoning, but would they have mentioned patent issues publicly if that were the real reason? G…

JPEG XL doesn't use the kind of rANS that Microsoft has patented.

JPEG XL decides the codes at encoding time and does context modeling the same way as WebP lossless and Brotli, by deciding which entropy codes to use explicitly.

Microsoft's rANS patent is supposedly centralized around updating rANS codes at decoding time (based on past symbols). This is slightly more efficient for density, but much slower and may negate the speed benefits that rANS brings. For practical implementations JPEG XL/Brotli way is quite a bit better.

Re: Request: Re-open JPEG XL issue

#150

Post by JyrkiAlakuijala »

snickerbockers wrote: post #16

I'm just reading through the wikipedia page on this for the first time. Does JPEG XL allow encoders to switch between the DCT and modular modes on a per-macroblock basis, or is it just on a per-channel basis? If it's the former then I can see this offering a lot of utility over other image formats because you'd be able to disable the DCT on high-contrast macroblocks and finally be done with all those god-awful "check…

JPEG XL has 10 8x8 transforms and 9 larger transforms (IIRC).

Two of the 8x8 transforms are extremely local. One is called IDENTITY and the other DCT2x2. It is very difficult to produce ringing artefacts when using these transforms.

When going to higher quality settings in libjxl, it tends to favor the DCT2x2 quite a bit.

This is in VarDCT -- not modular coding.

Post reply on HN