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

151–160 of 164 posts

Re: Request: Re-open JPEG XL issue

#151

Post by JyrkiAlakuijala »

worrycue wrote: post #124
izacus wrote: post #82

Earlier quoted context omitted.

The fact that JXL is a new convenient crusade for people that hate on Chrome. You'll notice that noone is screaming at Mozilla for the same choice.

I am. It’s worse than Chrome in a way frankly in that JPEGXL is only supported in the Nightlies behind a flag. However Mozilla has not completely dropped the feature like Google.

Mozilla's JPEG XL feature request is closed in a way that not possible to add comments or express interest.

Chromium's JPEG XL feature request is marked wontfix but still possible to comment or express interest (star the bug).

Re: Request: Re-open JPEG XL issue

#152

Post by JyrkiAlakuijala »

gulikoza wrote: post #27
purpleblue wrote: post #14

Can someone summarize the issue with JPEG XL? Is this something that really matters? I've seen this mentioned a couple of times in the last few days but I don't see what the big deal is, is it really that necessary?

JPEG is 30 years old so we need something more modern (better compression, less visual artifacts, web optimized, etc...). There already was a plan to change it with JPEG 2000, but it failed, obviously, as we still use jpegs. Now several formats are competing, most notably AVIF (which is basically just single AV1 video compressed frame) and JPEG XL. JPEG XL might be slightly better in some cases (as AVIF is based on a…

Google Research is developing and maintaining JPEG XL, including a Chromium patch, without having expressed future maintenance cost worries.

Re: Request: Re-open JPEG XL issue

#153

Post by account42 »

Please can we have browsers not advertise support via Accept heders or tag support this time until they actually support all features so that those don't become useless for progressive enhancement of anything that isnt a static lossy image.

Re: Request: Re-open JPEG XL issue

#154

Post by account42 »

PaulHoule wrote: post #30
stavros wrote: post #23

Earlier quoted context omitted.

We haven't even switched to WebP yet, and it's already obsolete? What hope is there for anything?

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…

a) This is a property of the encoder, not of the image format.

and

b) Like any other video codec-based format, webp overcompresses dark areas in images so no, you can't rely on consistent quality across collections of arbitrary images.

Re: Request: Re-open JPEG XL issue

#155

Post by account42 »

buttersbrian wrote: post #36
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…

This image is helpful to see how they all kinda stack up, feature wise. https://archive.smashing.media/assets/344dbf88-fdf9-42bb-adb...

There is plenty of wrong or misleading information here:

- What is the cross supposed to mean for PNG compression of photographic images? PNG can compress photographic images just fine and for some applications (where you want lossless) it used to be a good choice.

- PNG has animation support, even if everyone except Firefox tried to

- While WEBP and AVIF support lossless compression and animation, those features are not available in all browser versions that support static lossy webp/avif images.

Re: Request: Re-open JPEG XL issue

#156

Post by JyrkiAlakuijala »

pornel wrote: post #13
FoxBJK wrote: post #10

Earlier quoted context omitted.

I think Google's answer to that is WebP.

If anything, it'd be AVIF. WebP is obsolete. It's still based on VP8 codec, which in video has been replaced by VP9 long time ago. AVIF is based on AV1, which is a successor to VP10. So WebP is a few generations behind in the VPx lineage, and is no match for modern codecs.

AVIF was a quick hack originally by Netflix by placing an AV1 frame into a HEIC container. I believe it was done in a few weeks of work.

AV1 was largely based on VP9/VP10 and was developed by a team working in Chrome organization.

JPEG XL main mode (VarDCT) and the JPEG recompression is largely developed by Google Research.

WebP as a format was based on VP8, a video codec built by On2 Technologies. On2 was bought by Google in 2010 -- a year before Google published WebP. The transparency and lossless encoding as well as non-video keyframe-by-keyframe animation were designed at Google. The On2 VP8 codec used initially in WebP lossy was not that suitable (too many artefacts) for photography transmission. Jeff Muizelaar wrote a great blog post about this. The codec for WebP were redesigned (without format) changes at Google, and kept improving significantly until around 2015 when it reached pretty good maturity.

(Personally, I don't like what it does to highly saturated dark colors, such as dark forests or dark red textures, but it is much much better than it was.)

Re: Request: Re-open JPEG XL issue

#157

Post by cubefox »

JyrkiAlakuijala wrote: post #146
cubefox wrote: post #121

Earlier quoted context omitted.

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 quali…

No, I think Internet average quality is a lot lower than AVIF or JPEG XL at "large". Instead of using such a high bitrate to save a small amount quality, it makes much more sense to use a low bit rate with a significantly higher resolution, and end up with the same file size.

Even cameras often have relatively little detail per pixel, since they do interpolate a lot of information due to the usage of Bayer filters (which record only one primary color per pixel instead of full RGB values), and because anything with less than perfect lighting will be somewhat noisy and blurry anyway.

Re: Request: Re-open JPEG XL issue

#158

Post by JyrkiAlakuijala »

cubefox wrote: post #157
JyrkiAlakuijala wrote: post #146

Earlier quoted context omitted.

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 quali…

No, I think Internet average quality is a lot lower than AVIF or JPEG XL at "large". Instead of using such a high bitrate to save a small amount quality, it makes much more sense to use a low bit rate with a significantly higher resolution, and end up with the same file size. Even cameras often have relatively little detail per pixel, since they do interpolate a lot of information due to the usage of Bayer filters (w…

I made quite a bit of unpublished effort to understand the average quality. Web almanac media chapter is showing average jpeg bpp density. In my collection median quality as reported by image magic is 85 and roughly 2–2.5 BPP.

Re: Request: Re-open JPEG XL issue

#159

Post by JyrkiAlakuijala »

gsich wrote: post #21
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…

JPEG has 12-bit somewhere in the standard, not sure on where it's implemented.

jpegli can encode and decode 12 bits out of 8 bit jpegs. Or 10-12 bits, more when smoother, less when noisier.

Re: Request: Re-open JPEG XL issue

#160

Post by JyrkiAlakuijala »

chungy wrote: post #78
x4e wrote: post #75

Earlier quoted context omitted.

Darktable supports it under JPEG2000: https://docs.darktable.org/usermanual/4.0/en/overview/suppor... (Darktable also supports JPEG XL)

JPEG2000 is a different format, just as JPEG XL isn't the same as original JPEG.

12 bit jpeg is a different format in practice. Better to move forward than adding support for a new ancient format.

Also, jpegli can support 10+ bits within the old compatible "8 bit" formalism.

Post reply on HN