WebP is so great except it's not (2021) • Hacker News Board

Re: WebP is so great except it's not (2021)

#401

Post by conaclos » Sat, Dec 16, 2023, 2:57 PM UTC

aidenn0 wrote: post #264

LeoNatan25 wrote: post #223

Earlier quoted context omitted.

No, in both cases, use something that is better than JPEG and Webp: JPEG XL.

The thing that I like the best about jxl is how consistent the reference encoder is. If I need to compress an entire directory of images, cxjl -d 1.0 will generate good looking images at a pretty darn small size. Using mozjpeg (SPEG), or openjpeg (JPEG 2000) or cwebp, and I want to get even close (in bpp) to what cjxl does on the default I have to use different settings for b&w vs color and line-art vs photos.

The last time I checked, it was not possible to re-encode a JXL image into a JPEG image. Is this now supported?

Re: WebP is so great except it's not (2021)

#402

Post by bzzzt » Sat, Dec 16, 2023, 4:09 PM UTC

djha-skin wrote: post #221

bzzzt wrote: post #200

Earlier quoted context omitted.

I have to zoom in to really notice that. But both the jpg and webp have distortion - webp slightly more. Both have difficulty with edges.

I think we're talking about two different things. You're not noticing the forest for the trees. I'm talking about big huge macro effects that become more apparent when you zoom out, not less. There is a difference in the gradients of color. One hasn't the guy looking backlit and one doesn't.

At default zoom the image is 20% of the width of my monitor so it's hard to see artefacts. When zoomed in the posterization is noticeable but jpeg at 85% is about as bad as webp. I don't see any substantial difference in lighting.

Re: WebP is so great except it's not (2021)

#403

Post by hot_gril » Sat, Dec 16, 2023, 5:19 PM UTC

Izkata wrote: post #311

My issue with webp is that when it's animated, it seems random whether it gets treated as an image file like a gif or a video file. Any webp I save I have to convert to a real image file to ensure I can view/use it outside of a browser.

Webp is like usb-c in a way, multiple different capabilities in one package. Might sound good on paper, but gets annoying.

Re: WebP is so great except it's not (2021)

#404

Post by 8n4vidtmkvmk » Sun, Dec 17, 2023, 6:56 AM UTC

skelpmargyar wrote: post #381

Unfrozen0688 wrote: post #341

Earlier quoted context omitted.

Not true. Monitors now are 1440p or 4k. Even at work for me. The "issue" is that monitors last a LONG time. And thats good. We dont touch them or fiddle with them. They tend to just work. Phones and shit we keep dropping and breaking, then the battery gets bad. Also for gaming you may even want 1080p 200hz monitor for high refresh rate and FPS over pixel density.

You also can't write software bad enough that you're forced to upgrade your monitor due to poor performance.

You almost can. The Windows Terminal app has a performance issue on gsync monitors. I think it's being treated like a game but the app only renders at 60 fps or something, maybe lower, which I guess forces the whole screen to refresh at that rate which causes mouse stutter

Re: WebP is so great except it's not (2021)

#405

Post by maigret » Mon, Dec 18, 2023, 8:04 AM UTC

tommica wrote: post #27

bawolff wrote: post #11

I dont get it. The author seems to care highly about image quality, but also wants to squeeze out as many bytes as possible? Bandwidth is cheap. If we are talking about photography as art, why would you be trying to scrap a few kb off in the first place?

Because not all countries have cheap or unlimited bandwidth

Also planes don't, so it's not a poor vs rich topic as many seem to make it be.

Re: WebP is so great except it's not (2021)

#406

Post by skhameneh » Mon, Dec 18, 2023, 10:56 PM UTC

I first browsed the article on mobile without adjusting my display brightness (generally set to low for eye comfort) and it took significant effort to see the issues.

I then turned my brightness to 50% and immediately saw browser rendering issues the author may not have experienced themselves. The differences in various contexts are massive. It may be useful to take photos of my screen rendering the various artifacts at varied brightness. There are clearly some rendering optimizations (in different contexts) that create some horrible artifacts.

Re: WebP is so great except it's not (2021)

#407

Post by aidenn0 » Tue, Dec 19, 2023, 6:37 AM UTC

conaclos wrote: post #401

aidenn0 wrote: post #264

Earlier quoted context omitted.

The thing that I like the best about jxl is how consistent the reference encoder is. If I need to compress an entire directory of images, cxjl -d 1.0 will generate good looking images at a pretty darn small size. Using mozjpeg (SPEG), or openjpeg (JPEG 2000) or cwebp, and I want to get even close (in bpp) to what cjxl does on the default I have to use different settings for b&w vs color and line-art vs photos.

The last time I checked, it was not possible to re-encode a JXL image into a JPEG image. Is this now supported?

It's possible to encode any image format to any other; I'm not sure what they has to do with my comment though

Re: WebP is so great except it's not (2021)

#408

Post by JyrkiAlakuijala » Mon, Dec 25, 2023, 12:13 PM UTC

mceachen wrote: post #366

Findecanor wrote: post #262

Earlier quoted context omitted.

> Re-encoding from a lossy compressed source will make quality worse. JPEG-XL is supposed to reencode old JPEG files into 20% smaller files without quality loss though. In context, Google has been holding JPEG-XL back by removing support for it from Chrome and refusing to reinstate it, claiming that it did not have good enough "incremental benefits compared to existing formats" such as webp.

Careful with the JPEG-XL re-compression, though--depending on how you're re-encoding, jxl may use SSIM to evaluate for visual losslessness, and the whole point of TFA is that SSIM is blind to posterization, but (some) humans aren't. Disk space is cheap. It's most likely not worth the 20% compression to lose your original images (and possibly lose metadata as well--it's quite hard to robustly retain all vendor-specifi…

We overprovision low frequencies dramatically to avoid posterisation. JPEG XL development was never driven by SSIM, only butteraugli + human viewing. I reviewed manually every quality affecting change during its research and development.

Re: WebP is so great except it's not (2021)

#409

Post by JyrkiAlakuijala » Mon, Dec 25, 2023, 12:15 PM UTC

quikee wrote: post #390

mceachen wrote: post #366

Earlier quoted context omitted.

Careful with the JPEG-XL re-compression, though--depending on how you're re-encoding, jxl may use SSIM to evaluate for visual losslessness, and the whole point of TFA is that SSIM is blind to posterization, but (some) humans aren't. Disk space is cheap. It's most likely not worth the 20% compression to lose your original images (and possibly lose metadata as well--it's quite hard to robustly retain all vendor-specifi…

JXL has Guetzli lossless JPEG compressor integrated into the standard so it produces reversible and completely standard compliant JXL images that are 15-20% smaller size. Reversible in sense that you can still convert the image back the original JPEG, that is bit exact file as the input JPEG was (it takes care of all the metadata also - it has to). Also if you decide to forgo the reversibility you can get a bit more…

The lossless thingy is Brunsli. In the last meters of the standardization, Brunsli in JPEG XL was replaced with "Brunsli 2.0", the more natural formalism in JPEG XL format, allowing for a smaller spec and decoder as well as parallel decoding.

Guetzli is a slow high quality jpeg encoder. One can use jpegli for that need nowadays, 1000x faster...

Re: WebP is so great except it's not (2021)

#410

Post by JyrkiAlakuijala » Mon, Dec 25, 2023, 12:54 PM UTC

gruturo wrote: post #358

jsnell wrote: post #277

Earlier quoted context omitted.

What you're ignoring is that WebP is from the year 2010. JPEG XL is from 2022. Incidentally, JPEG XL is also a Google project, making your ranting about how bad they're at image formats pretty funny.

Hi! I'm aware that JXL partially originates from Google's PIK - and also Brunsli??, but I had indeed forgotten that WebP started in 2010, wow, 13 years old already. I'll therefore correct my statement: "How could Google do worse than that??? When basically rezipping (with a modern algo) the existing DCT macroblock bytestream of a 18 year old codec beats your new codec, you should just trash it." Also, Stuffit's SIF f…

I didn't compare with stuffit. If it's better than JXL recompression, perhaps they had put more focus on lossless recompression. Perhaps they had less realtime constraints in decoding speed.