This really looks great. I really wish the author(s) could provide a detailed overview of the human vision model algorithm being implemented, what it is doing and why, so we could reproduce an implementation, may be even provide improvements? Otherwise amazing work.
Guetzli: A New Open-Source JPEG Encoder
111–120 of 135 posts
Re: Guetzli: A New Open-Source JPEG Encoder
#112I'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…
Google's implementation may be slower, but it's open source.
Re: Guetzli: A New Open-Source JPEG Encoder
#113Earlier quoted context omitted.
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).…
Were you already security saavy before or did you learn on the spot ? It's as exciting as scary, and I wouldn't touch it with a ten foot pole :)
(thanks for the answer btw)
Re: Guetzli: A New Open-Source JPEG Encoder
#114How relevant to web pages is this?
The blog makes it sound like that's the target but the paper has this line:
"Our results are only valid for high-bitrate compression, which is useful for long-term photo storage."
Do the author's think the size/quality benefits still show up when targetting lower bitrates/qualities that are more common on the web? Do they intend to try to prove it?
Re: Guetzli: A New Open-Source JPEG Encoder
#115How relevant to web pages is this? The blog makes it sound like that's the target but the paper has this line: "Our results are only valid for high-bitrate compression, which is useful for long-term photo storage." Do the author's think the size/quality benefits still show up when targetting lower bitrates/qualities that are more common on the web? Do they intend to try to prove it?
Quality-wise, Guetzli is applicable to about 50% of the JPEG images in the internet. The other half is stored with lower than 85 quality, and Guetzli declines to attempt to compress to that quality.
Another limitation is that Guetzli runs very slowly. This gives a further limiting axis: Guetzli in its current form cannot be applied to a huge corpus of images. Perhaps this covers half of the images on the internet.
So, let's say that Guetzli is 25% relevant to the web pages.
Re: Guetzli: A New Open-Source JPEG Encoder
#116The 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.
As a user, I love progressive images because I can see the whole image very fast. (I don't have to wait for it)
Re: Guetzli: A New Open-Source JPEG Encoder
#117How does it compare to mozjpeg?
Re: Guetzli: A New Open-Source JPEG Encoder
#118Earlier 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…
Nothing to be embarrassed about, you got results. Results are what matters in the end.
This is even more the case with software. If this cost 20 or 20 million man hours is irrelevant in the long run because eventually it will be used enough to offset costs if it is as good as every one says. Of course short term cost hurt now, but sounds like you still had computers do much of the heavy lifting.
Re: Guetzli: A New Open-Source JPEG Encoder
#119Earlier 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.
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
Re: Guetzli: A New Open-Source JPEG Encoder
#120I am not an expert, but AFAIK JPEG is a lossy format. The comparison is purely based on the size, and I couldn't find anything in the paper about data loss compared to other encoders. Can someone please explain why is this a fair comparison?