Live data from Hacker News

Guetzli: A New Open-Source JPEG Encoder

research.googleblog.com

81–90 of 135 posts

Re: Guetzli: A New Open-Source JPEG Encoder

#82
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/

bpg will never get anywhere due to being patent encumbered.

There is no way we will start paying royalties to show images on the web.

Re: Guetzli: A New Open-Source JPEG Encoder

#83

Earlier quoted context omitted.

It is old school: 100000+ cpu hours of Nelder-Mead method (+common tricks) to match butteraugli to a set of 4000 human rated image pairs created with an earlier version of Guetzli and specially-built image distortion algorithms.

How did you protect against overfitting? How about local maxima? Some of your constants look surprising to say the least. Most notably: * The gamma value of 0.38 (when most studies suggest 1.5 - 2.5 for human eye gamma) * The significant difference in the vertical and horizontal constants (when as far as I know human eyes are equally sensitive to most distortions independant of angle).

There was a large variety of regularization and optimization techniques used. An embarrassingly large amount of manual work went into both.

In this use the gamma is the inverse of something close to 2.6. Butteraugli needs both gamma correction and inverse gamma correction.

The FFT co-efficients only look weird, but they should actually lead to a symmetric result if our math is correct. In a future version we move away from the FFT, so I don't encourage anyone to actually debug that too much.

Re: Guetzli: A New Open-Source JPEG Encoder

#84
post #49

As the author of the original libjpeg (back in 1991), I think this has been a long time coming! More power to Google.

Impressive :) What are you on these days ? image codecs still ?

No -- computer security -- which is a fascinating field. There are arms races here between the good people and the bad people. It isn't clear that the forces of good are winning. It is a Red Queen problem.

The original libjpeg code was written to try and change the Usenet News binary pictures groups over from GIF to JPEG (so that more images would fit down the rather narrow transatlantic pipe that I had at the time). The choice of license turned out to be a good one (it predated the GPL V2) -- who knows what would have happened if we (the precursor to the IJG) had chosen that one.

Re: Guetzli: A New Open-Source JPEG Encoder

#85

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…

I've seen this done in signal processing domain - someone goes to Matlab, creates a filter or other transformation there and then presses a button and it spits out a bunch of C code with constants looking like that. So they probably did that same thing.

Re: Guetzli: A New Open-Source JPEG Encoder

#86
post #75
post #36

Earlier quoted context omitted.

Would it be possible to accelerate Guetzli on a GPU?

It appears that FFT can be GPU accelerated. Nvidia has cuFFT which claims to be 10x faster.

I'd expect this to behave quite differently to cuFFT: the transforms are likely to be small (either length 8 1D FFTs, or 8x8 2D FFTs) and thus synchronisation overhead is likely to dominate if one was to try to parallelise within a transform (other than via SIMD). However, this small size does mean that the transforms can be written out to have "perfect" data transfer and branching behaviour, so that they parallelise well at JPEG's natural parallelisation granularity (the 8x8 pixel blocks).

Re: Guetzli: A New Open-Source JPEG Encoder

#87
post #67

Earlier quoted context omitted.

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.

Can vouch for Kraken.io -- I've just begun using it to optimize ~50k+ interior architectural images so fidelity is important to me and my users. I'm about a third of the way done with the project and am saving just about 40% in size on average.

Re: Guetzli: A New Open-Source JPEG Encoder

#88

Is JPEG2000 with progressive/resolution-responsive transcoding still a thing or is HTML the way to go for responsive images (or maybe WepP)?

JPEG2000 died a bitter patent death.

Any time you watch a movie at the cinema, JPEG 2000 is in use, decoding the film.

Re: Guetzli: A New Open-Source JPEG Encoder

#89
post #54

Earlier quoted context omitted.

So... machine learning? (Sorry for buzz-wording)

It is old school: 100000+ cpu hours of Nelder-Mead method (+common tricks) to match butteraugli to a set of 4000 human rated image pairs created with an earlier version of Guetzli and specially-built image distortion algorithms.

[deleted]

Re: Guetzli: A New Open-Source JPEG Encoder

#90
post #2

Cool, but neither the article nor the paper ( https://arxiv.org/pdf/1703.04416.pdf ) mention just how much slower it is.

Worth noting that a great deal of lossy image compression methods currently in use were developed in the mid to late 1990s, when a 90 MHz Pentium was an expensive and high end CPU. Spending CPU time to do the one time compression of a lossless image to lossy is not as expensive in terms of CPU resources as it used to be.
Post reply on HN