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

121–130 of 135 posts

Re: Guetzli: A New Open-Source JPEG Encoder

#121

Post by i336_ »

JyrkiAlakuijala wrote: post #83
londons_explore wrote: post #80

Earlier quoted context omitted.

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

> In a future version we move away from the FFT

Do you have any idea when that will land in the open? Say, before 2018? Or maybe a little sooner?

Re: Guetzli: A New Open-Source JPEG Encoder

#122

Post by i336_ »

JyrkiAlakuijala wrote: post #59
nothis wrote: 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.

Very nice.

One question: as the top-level comment in this thread noted, this algorithm may be specialized to certain kinds of images.

Can you release info about the kind of images/datsets this approach will pathologically fail with? That would be really really awesome.

Re: Guetzli: A New Open-Source JPEG Encoder

#123

Post by i336_ »

TD-Linux wrote: post #38
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.

I think this paper was part of it, which showed that the advantages of fractal image compression could equivalently be achieved with smooth wavelets and efficient representation of zerotrees, except with a lot more speed and flexibility (sorry no PDF): https://www.researchgate.net/publication/5585498_A_wavelet-b...

> sorry no PDF

No directly-linkable PDF :P

https://news.ycombinator.com/item?id=12374235

Re: Guetzli: A New Open-Source JPEG Encoder

#124

Post by acdha »

boxerab wrote: post #119
acdha wrote: post #92

Earlier quoted context omitted.

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.

shameless plug for my JPEG 2000 codec: https://github.com/GrokImageCompression/grok . Performance currently around 1/3 Kakadu

Heh, yes - I've been following that since you announced it. It'd be really nice if we could start getting the OSS toolchain onto a JP2 implementation with decent performance — I think jasper really soured the reputation for many people.

Re: Guetzli: A New Open-Source JPEG Encoder

#126

Post by tannhaeuser »

purerandomness wrote: post #63
tannhaeuser wrote: post #44

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.

Doesn't Safari support JPEG2000?

Re: Guetzli: A New Open-Source JPEG Encoder

#127

Post by i336_ »

i336_ wrote: post #121
JyrkiAlakuijala wrote: post #83

Earlier quoted context omitted.

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

> In a future version we move away from the FFT Do you have any idea when that will land in the open? Say, before 2018? Or maybe a little sooner?

Very confused as to why this was downvoted?

Re: Guetzli: A New Open-Source JPEG Encoder

#128

Post by jose_cambronero »

phaker wrote: post #69
JyrkiAlakuijala wrote: post #45

Earlier quoted context omitted.

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. :)

+1 I would be very interested in reading about butteraugli, if there is anything documented.

Re: Guetzli: A New Open-Source JPEG Encoder

#129

Post by Prodibi_Olivier »

dmitrygr wrote: post #2

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

To share my experience, I tried today with a 50mpx image: it took me 1 full hour and it constantly used 10% of my CPU. But the quality was great (even sharper?)!

Re: Guetzli: A New Open-Source JPEG Encoder

#130

Post by tinus_hn »

morecoffee wrote: post #97
userbinator wrote: post #77

Earlier quoted context omitted.

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?

PDFs are packaged Postscript. Postscript is a Turing complete language and the output of a script is a page.

PDFs with JPEG2000 images contain a Postscript library to decode these images. That is the code that gets to show them.

Post reply on HN