Live data from Hacker News

Lepton image compression: saving 22% losslessly from images at 15MB/s

blogs.dropbox.com

161–170 of 196 posts

Re: Lepton image compression: saving 22% losslessly from images at 15MB/s

#162
> To encode an AC coefficient, first Lepton writes how long that coefficient is in binary representation, by using unary. [...] Next Lepton writes a 1 if the coefficient is positive or 0 if it is negative. Finally, Lepton writes the the absolute value of the coefficient in standard binary. Lepton saves a bit of space by omitting the leading 1, since any number greater than zero doesn’t start with zero.

The wording almost implies that this is novel, but it is actually Gamma coding [1], which in the signal compression community is often called Exp-Golomb coding [2]. I wonder why this is not acknowledged, considering that they mention the VP8 arithcoder instead.

[1] https://en.wikipedia.org/wiki/Elias_gamma_coding

[2] https://en.wikipedia.org/wiki/Exponential-Golomb_coding

Re: Lepton image compression: saving 22% losslessly from images at 15MB/s

#163
post #57
post #49

Earlier quoted context omitted.

I don't think they're compressing this and decompressing it client side. At least I didn't get that impression from the article. You're correct ofc, download costs = 10 months of storage.

> I don't think they're compressing this and decompressing it client side. The speed quotes made it sound like client-side was a concern. Why would you go to all the effort of devising a new image compression format saving 20%+ storage and on the wire, and not have it decompressed client-side, especially when you control the client?

My rough understand, as someone who works at Dropbox and knows some of the people who worked on this (but isn't directly involved), is that this currently only runs on our servers. The perf requirements are primarily that we don't want to slow down syncing / downloads significantly - and also want to keep the CPU cost under control. As is, the savings in storage space should easily pay for the extra compute power required.

Re: Lepton image compression: saving 22% losslessly from images at 15MB/s

#164

Earlier quoted context omitted.

> FLIF is a novel lossless image format which outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR in terms of compression ratio. > 74% smaller than lossless JPEG XR compression. > Works on any kind of image

It also loads progressively and has a novel feature that lets a client determine how much detail to render, then stop loading any more data, all while using the same file. http://flif.info/example.html

This would be a totally awesome feature if the quality of a truncated FLIF came anywhere close to files tailored to that size in “real“ lossy formats. Unfortunately, according to that example page, truncated FLIF falls far behind. It might find a niche where data reduction and scale reduction fall together (the last example)

Re: Lepton image compression: saving 22% losslessly from images at 15MB/s

#165

Very interesting. But it's not clear to me how estimating the DC components makes it guaranteed lossless

You store the delta to the estimate. If the estimate is bad (e.g. because someone designed content for maximum surprise of the estimator function), compression rate goes down, not quality.

Re: Lepton image compression: saving 22% losslessly from images at 15MB/s

#169

Does anyone know how this compares to jpegoptim? https://github.com/tjko/jpegoptim I'm hitting the limits in my OneDrive account and jpegoptim seemed to reduce my photos quite a bit.

jpegoptim has lossless and lossy modes. In lossless mode it preserves all pixels, but it doesn't preserve the file itself. Lossless jpegoptim is comparable to Lepton. In general, Lepton can tends to give better improvements, because it uses a different output file format. How much better depends on your input files, you should try both.

I'd say 22% for Lepton and 5% for jpegoptim, based on fading past memories of mine.

Post reply on HN