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

Guetzli: A New Open-Source JPEG Encoder

research.googleblog.com

Post reply on HN
Print view View original

21–30 of 135 posts

Re: Guetzli: A New Open-Source JPEG Encoder

#21

Post by mattpavelle »

jacobolus wrote: post #9
mattpavelle wrote: post #6

I'll run some of my own experiments on this today, but I'm initially concerned about color muting. Specifically looking at the cat's eye example, in the bottom of the pupil area there's a bit of green (reflection?) in the lower pupil. In the original it is #293623 (green) - in the libjpeg it is #2E3230 (still green, slightly muted). But in the Guetzil encoded image it is #362C35 - still slightly green but quite close…

In general if you want to avoid any color changes in blobs a few pixels in size, you’ll want to take it easy on the compression, and take the hit of a larger file size in trade. I suspect that if you give this algorithm twice the file size as a budget, that green color will come back.

I agree, giving more file size may get us our colors back. And after some experimentation I'd like to be able to confirm something a bit abstract like, "Guetzli is good for reducing artifacts by sacrificing color" or some such snippet.

It would definitely have its uses as such. Or maybe it's great all around and I just found one bad example?

Re: Guetzli: A New Open-Source JPEG Encoder

#22

Post by johansch »

wolf550e wrote: post #20
d--b wrote: post #19

Why spend a lot of time improving jpeg instead of spending time promoting a HEVC-based standard like that one? http://bellard.org/bpg/

Because patents.

And slowness of cross-browser deployment. Both for stupid and very valid reasons.

As an example of the latter:

I think Opera Mini (which I ran the development of for its first decade) still has somewhere around 150-200 million monthly unique users, down from a peak of 250M. Pretty much all of those users would be quite happy to receive this image quality improvement for free, I think. (Assuming the incremental encoding CPU cost isn't prohibitive for the server farms.) Opera Mini was a "launch user" of webp (smartphone clients only) for this particular reason.

Many of those users devices are Nokia/Sony Ericsson/etc J2ME devices with no realistic way of ever getting system-level software updates. They are still running some circa 2004 libjpeg version to actually decode the images. It's still safe because the transcoding step in Opera Mini means that they aren't exposed to modern bitstream-level JPEG exploits from current web, but it underscores why any improvements targetting formats like JPEG is still quite useful.

Opera Mini for J2ME actually includes a very tiny (like 10k iirc) Java-based JPEG decoder since quite a few devices back then didn't support JPEG decoding inside the J2ME environment. It's better than having to use PNG for everything, but because it's typically like 5x-10x slower than the native/C version even in a great JVM of the time it really only makes sense to use as a fallback.)

Re: Guetzli: A New Open-Source JPEG Encoder

#23

Post by mtgx »

d--b wrote: post #19

Why spend a lot of time improving jpeg instead of spending time promoting a HEVC-based standard like that one? http://bellard.org/bpg/

If anything, they would spend the time to make it AV1-based, which apparently was expected to come out this month:

http://www.streamingmedia.com/Articles/Editorial/-110383.asp...

http://aomedia.org/about-us/

Re: Guetzli: A New Open-Source JPEG Encoder

#24

Post by E6300 »

SloopJon wrote: post #15

The Github README says, "Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer." What's the current thinking on progressive JPEGs? Although I haven't noticed them recently, I don't know whether they're still widely used.

As a user, I dislike progressive images because of the ambiguity regarding when they've finished loading.

Re: Guetzli: A New Open-Source JPEG Encoder

#25

Post by TD-Linux »

theandrewbailey wrote: post #18
SloopJon wrote: post #15

The Github README says, "Guetzli generates only sequential (nonprogressive) JPEGs due to faster decompression speeds they offer." What's the current thinking on progressive JPEGs? Although I haven't noticed them recently, I don't know whether they're still widely used.

I use progressive JPEGs if they have a smaller filesize, which is true most of the time.

mozjpeg also generates progressive JPEGs by default, for the same reason.

Re: Guetzli: A New Open-Source JPEG Encoder

#26

Post by ktta »

mtgx wrote: post #23
d--b wrote: post #19

Why spend a lot of time improving jpeg instead of spending time promoting a HEVC-based standard like that one? http://bellard.org/bpg/

If anything, they would spend the time to make it AV1-based, which apparently was expected to come out this month: http://www.streamingmedia.com/Articles/Editorial/-110383.asp... http://aomedia.org/about-us/

Nope, they pushed the expected release date to end of this year[1]. I was really hoping it would come out this month too, then I realized we won't see much adoption till 2019. 2018 will be spent with a couple releases of software decoders, and some adoption, and 2019 is when the hardware decoders will released. Which is when we can expect everyone to more to AV1.

But I'm still skeptical because HEVC might be more widespread with hardware decoders everywhere and people might just not care enough to move to the new standard. Unless MPEG-LA exploits its dominance really bad with license fees, then we can expect MPEG codecs to die off. Although I think x264 will still live.

[1]: https://fosdem.org/2017/schedule/event/om_av1/attachments/sl...

(4th slide. This codec will be standardized after the experiments are removed and it is frozen to test software.)

Re: Guetzli: A New Open-Source JPEG Encoder

#27

Post by theandrewbailey »

d--b wrote: post #19

Why spend a lot of time improving jpeg instead of spending time promoting a HEVC-based standard like that one? http://bellard.org/bpg/

Install base. JPEG has already been promoted and is everywhere. If it's not a pain to better use what's already out there, why would one want to support another format (with all its code bloat, security, and legal implications) indefinitely?

Re: Guetzli: A New Open-Source JPEG Encoder

#28

Post by TD-Linux »

JyrkiAlakuijala wrote: post #7
corybrown wrote: post #5

Very cool. I'm not an expert, but does JPEG generally have a ton of flexibility in compression? Why so much difference in sizes?

Three main methods: 1) YUV420 vs YUV444. Guetzli practically always goes for YUV444. 2) Choosing quantization matrices. 3) After normal quantization, choose even more zeros. JPEG encodes zeros very efficiently. When doing the above, increase the errors where it matters least (certain RGB values hide errors in certain components, and certain types of visual noise hides other kind of noise).

Step 3), choosing more zeros, can be generalized with trellis quantization, which does a search for the best values to encode for each block for the best distortion-per-rate score, where distortion can be any metric (edit: apparently guetzli does some sort of whole frame search for this). mozjpeg does trellis with effectively the PSNR-HVS metric. Because the other two steps are only one setting that affects the entire picture, I do wonder how Guetzli would perform if it was just a wrapper around mozjpeg.

Re: Guetzli: A New Open-Source JPEG Encoder

#30

Post by TD-Linux »

iainmerrick wrote: post #11
corybrown wrote: post #5

Very cool. I'm not an expert, but does JPEG generally have a ton of flexibility in compression? Why so much difference in sizes?

Yes, JPEG encoding has a ton of flexibility. You rearrange each block of pixels using the discrete cosine transform, which tends to pack more significant values towards one corner, and then you have lots of freedom over how to quantize those values. See https://en.wikipedia.org/wiki/JPEG#Quantization On top of that, you could tweak the quantized values themselves to make them more compressible.

There's less flexibility than you might think - you get only one choice of quantizer and quantization matrix for the entire frame. So pretty much your only option is to twiddle the values themselves. This is usually done with trellis quantization, such as in mozjpeg. Guetzli seems to implement something simpler that just sets increasing numbers of coefficients to zero (based on my cursory reading of the source code).
Post reply on HN