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

91–100 of 135 posts

Re: Guetzli: A New Open-Source JPEG Encoder

#91

Post by divbit »

londons_explore wrote: post #64
londons_explore wrote: post #53

This seems to be optimizing for a "perceptual loss function" over in https://github.com/google/butteraugli/blob/master/butteraugl... Looking at the code to that, it looks like 1500 lines of this: double MaskDcB(double delta) { PROFILER_FUNC; static const double extmul = 0.349376011816; static const double extoff = -0.894711072781; static const double offset = 0.901647926679; static const double scaler = 0.38008609502…

Upon more investigation, these numbers are certainly machine generated. Here is an example: A constant lookup table is used for determining the importance of a change vs distance. Seperate tables are used for vertical and horizontal distances (I guess eyes might be slightly more sensitive to vertical edges than horizontal ones?). Those tables are wildly different in magnitude: static const double off = 1.410337371404…

See fig. 2.1 here:

http://disp.ee.ntu.edu.tw/meeting/%E7%B6%AD%E6%AF%85/An%20In...

and also read here:

https://en.wikipedia.org/wiki/YUV

That is my quick guess on how to roughly derive the constants (because it is new, probably there are some fancy modifications tho :) )

Re: Guetzli: A New Open-Source JPEG Encoder

#92

Post by acdha »

userbinator wrote: post #77
purerandomness wrote: post #63

Earlier quoted context omitted.

JPEG2000 died a bitter patent death.

Actually, it's alive and well in the form of embedded images in PDFs, where it's known as JPXFilter. Most of the ebooks (scans) I've downloaded from archive.org use it. If it didn't have any huge advantage I doubt they would've chosen it over standard JPEG. The real problem, as far as I can see, is that JPEG2000 is really slow to decode due to its complexity.

Modern implementations are decent but there's no open source implementation in that class. OpenJPEG is improving but it's much slower than Kakadu (which is what CoreImage uses) or Aware.

Re: Guetzli: A New Open-Source JPEG Encoder

#94

Post by awalton »

vladdanilov wrote: post #12

I'm working on a similar thing ( http://getoptimage.com ). While Guetzli is still visually better and a bit smaller in file size, it's terribly slow and requires a lot of memory. But it's a great experiment. So much knowledge has been put into it. I believe using a full blown FFT and complex IQA metrics is too much. I have great results with custom quantization matrices, Mozjpeg trellis quantization, and a modificati…

> it's terribly slow and requires a lot of memory.

...and generates a solution that uses far less bandwidth, especially after thousands or millions of hits, which is the real point of the exercise.

Cloud computing companies love this. They've got a lot of bored hardware to put to use. It's absolutely no surprise to see solutions like this coming from Google. Spending a dollar of compute time to save $1000 in bandwidth is a no-brainer win for a company with a million servers.

Re: Guetzli: A New Open-Source JPEG Encoder

#95

Post by cjhanks »

londons_explore wrote: post #64
londons_explore wrote: post #53

This seems to be optimizing for a "perceptual loss function" over in https://github.com/google/butteraugli/blob/master/butteraugl... Looking at the code to that, it looks like 1500 lines of this: double MaskDcB(double delta) { PROFILER_FUNC; static const double extmul = 0.349376011816; static const double extoff = -0.894711072781; static const double offset = 0.901647926679; static const double scaler = 0.38008609502…

Upon more investigation, these numbers are certainly machine generated. Here is an example: A constant lookup table is used for determining the importance of a change vs distance. Seperate tables are used for vertical and horizontal distances (I guess eyes might be slightly more sensitive to vertical edges than horizontal ones?). Those tables are wildly different in magnitude: static const double off = 1.410337371404…

Yeah, this looks like an optimizer wrote the program. I presume the code was tested against natural images... so it might not be appropriate for all image types.

Re: Guetzli: A New Open-Source JPEG Encoder

#96

Post by ktta »

mtgx wrote: post #61
ktta wrote: post #26

Earlier quoted context omitted.

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

I would've preferred it if AV1 was 2x better than HEVC, but I don't think even HEVC was 2x better than h.264. So if they can achieve at least 50% in all tests against HEVC, it may be a good enough improvement to the point where companies like Netflix, Amazon, Facebook and Twitter adopt it, as well as tv show and movie torrent uploads (which has its own impact on codec adoption). Plus, YouTube is a given, and it's nic…

I agree that HEVC isn't a game changer.

I actually prefer x264 encoded video even though it results in much larger file sizes. Although HEVC has lower bitrate for supposedly same quality, my needs aren't constrained enough where I have to go for HEVC.

I hope AV1 doesn't lower the quality aspect since it is focused on being a primarily streaming codec with most of the companies being streaming focused (Google, Netflix, Amazon and Vidyo) and them focusing on better compression rate.

If I recall correctly HEVC was also meant to be a streaming codec and I feel like that lead to the lower quality compared to h264. It just doesn't feel that sharp although it is supposed to be 1080p. The blurring aspect is especially bad.

I don't think AOMedia guys will blow it though. I feel like they have a lot more expertise since there are people from multiple codecs (VP9, Daala, etc.) contributing to this.

Re: Guetzli: A New Open-Source JPEG Encoder

#97

Post by morecoffee »

userbinator wrote: post #77
purerandomness wrote: post #63

Earlier quoted context omitted.

JPEG2000 died a bitter patent death.

Actually, it's alive and well in the form of embedded images in PDFs, where it's known as JPXFilter. Most of the ebooks (scans) I've downloaded from archive.org use it. If it didn't have any huge advantage I doubt they would've chosen it over standard JPEG. The real problem, as far as I can see, is that JPEG2000 is really slow to decode due to its complexity.

The PDF reader is pretty interesting, because don't modern browsers ship with PDF readers? To decode the embedded JPEG2000s, the browser has to be able to decode them right?

Re: Guetzli: A New Open-Source JPEG Encoder

#99

Post by vladdanilov »

awalton wrote: post #94
vladdanilov wrote: post #12

I'm working on a similar thing ( http://getoptimage.com ). While Guetzli is still visually better and a bit smaller in file size, it's terribly slow and requires a lot of memory. But it's a great experiment. So much knowledge has been put into it. I believe using a full blown FFT and complex IQA metrics is too much. I have great results with custom quantization matrices, Mozjpeg trellis quantization, and a modificati…

> it's terribly slow and requires a lot of memory. ...and generates a solution that uses far less bandwidth, especially after thousands or millions of hits, which is the real point of the exercise. Cloud computing companies love this. They've got a lot of bored hardware to put to use. It's absolutely no surprise to see solutions like this coming from Google. Spending a dollar of compute time to save $1000 in bandwidt…

At the image upload rate nowadays, there's a place for a practical solution, and for any external company, that kind of cloud computing will cost a fortune.

Re: Guetzli: A New Open-Source JPEG Encoder

#100

Post by vladdanilov »

21 wrote: post #36
vladdanilov wrote: post #12

I'm working on a similar thing ( http://getoptimage.com ). While Guetzli is still visually better and a bit smaller in file size, it's terribly slow and requires a lot of memory. But it's a great experiment. So much knowledge has been put into it. I believe using a full blown FFT and complex IQA metrics is too much. I have great results with custom quantization matrices, Mozjpeg trellis quantization, and a modificati…

Would it be possible to accelerate Guetzli on a GPU?

It's block-based so definitely yes.
Post reply on HN