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

61–70 of 135 posts

Re: Guetzli: A New Open-Source JPEG Encoder

#61

Post by mtgx »

ktta wrote: post #26
mtgx wrote: post #23

Earlier quoted context omitted.

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 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 nice to hear that even Apple may adopt it and that Apple is actually going back on promoting HEVC support.

Re: Guetzli: A New Open-Source JPEG Encoder

#62

Post by mistercow »

onion2k wrote: post #35

Sort of related, but what's the story with fractal image compression? When I was at university (~20 years ago) there was a lot of research going in to it, with great promises heralded for web-based image transfer. There was a Netscape plugin that handled them. They seemed to just disappear in the early 2000s.

It's been a while sense I read about fractal image compression, but way back when, I read quite a bit about it. The impression I got about the algorithms I read about was that a) the term "fractal" seemed like a bit of a stretch, and b) they were a neat hack for building and exploiting a statistical model of an image, but the promises that were getting thrown around were pretty overblown. My guess is that these techniques would be blown out of the water by modern CNN-based methods.

Re: Guetzli: A New Open-Source JPEG Encoder

#64

Post by londons_explore »

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.4103373714040413;  // First value of Y lookup table
    static const double off = 11.38708334481672;   // First value of X lookup table
However, later on, when those tables are used, another scale factor is used (simplified code):

    static const double xmul = 0.758304045695;
    static const double ymul = 2.28148649801;
The two constant scale factors directly multiply together, so there is no need for both. No human would manually calculate to 10 decimal places a number which had no effect. Hence, my theory is these numbers have been auto-generated by some kind of hill climbing type algorithm.

Re: Guetzli: A New Open-Source JPEG Encoder

#65

Post by alexcroox »

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…

Any plans for a Wordpress plugin like TinyPNG has? We use that currently but TinyPNG's JPG output leads to visible pixilation.

Re: Guetzli: A New Open-Source JPEG Encoder

#67

Post by karim79 »

alexcroox wrote: post #65
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…

Any plans for a Wordpress plugin like TinyPNG has? We use that currently but TinyPNG's JPG output leads to visible pixilation.

Try out the https://kraken.io plugin. Kraken.io's optimization is more about fidelity to the original than maximising file size savings.

Re: Guetzli: A New Open-Source JPEG Encoder

#69

Post by phaker »

JyrkiAlakuijala wrote: post #45
TD-Linux wrote: post #34

Earlier quoted context omitted.

There is no block to block prediction other than DC prediction, so is this effect due to your distortion function spanning multiple blocks? Same for cross YUV channels, because your metric is in RGB space? edit: second read-through I found the paper [1] which explains it. The answer is basically "yes", where the large scale distortion function is basically activity masking. Normally this would be implemented with del…

This comes through the internal use of butteraugli -- and depending the quantization decisions on butteraugli. Butteraugli uses a 8x8 FFT, but computes this every 3x3 pixel creating coverage at block boundaries. In later stages of butteraugli calculation values are aggregated from an even larger area. Block boundary artefacts are taken into account by this and impact quantization decisions. Butteraugli operates neith…

Do you have / plan a paper describing butteraugli itself?

It seems like that's where most of the magic lies. Also peculiarities of human vision are one of my oddball interests, after compression of course. :)

Post reply on HN