View Full Version : Dropbox open sources 'Lepton' - an image compression competitor to JPEG


hajj_3
14th July 2016, 18:25
We are pleased to announce the open source release of Lepton, our new streaming image compression format, under the Apache license.

Lepton achieves a 22% savings reduction for existing JPEG images, by predicting coefficients in JPEG blocks and feeding those predictions as context into an arithmetic coder. Lepton preserves the original file bit-for-bit perfectly. It compresses JPEG files at a rate of 5 megabytes per second and decodes them back to the original bits at 15 megabytes per second, securely, deterministically, and in under 24 megabytes of memory.

more info: https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/
Source code: https://github.com/dropbox/lepton

Jamaika
14th July 2016, 19:49
I'm not convinced . Is it still the standard JPG?
Lack the examples of pictures, because they aren't in lossless mode.

nevcairiel
14th July 2016, 22:43
I'm not convinced . Is it still the standard JPG?
Lack the examples of pictures, because they aren't in lossless mode.

It doesn't need pictures, its "only" a streaming compression of ordinary JPEGs, ie. it takes a JPEG file and makes it smaller for transfer or storage, and you have to un-compress it back to its original JPEG, and then decode the JPEG.

Its not a new image format, its just a compression algorithm for JPEG images.

BadFrame
14th July 2016, 23:26
Looks really interesting, I've used PackJPG which does the same thing (also does lossless mp3 compression), will try this out and compare.

Jamaika
15th July 2016, 05:37
I see. This may otherwise.
Can anyone recommend compression algorithm lossy / lossless for APNG images? It could use to post on the forum.

BadFrame
15th July 2016, 20:45
I did a quick test on 1gb of jpegs from various sources, PackJPG was ~2% better in compression, however Lepton took less than half the time to compress and was ~6 times faster in decompression, so overall it's a great improvement.


Can anyone recommend compression algorithm lossy / lossless for APNG images? It could use to post on the forum.

I think your best bet is Zopfli-png as it is the best (as in compression ratio) PNG compressor, and AFAIK handles APNG, be aware that it's very slow though.

dave.98dslkfjh3
21st July 2016, 21:36
I see. This may otherwise.
Can anyone recommend compression algorithm lossy / lossless for APNG images? It could use to post on the forum.

APNG is a botched together format and is tough to optimize well.

As BadFrame said, Zopfli-png is your best bet for just a compression algorithm, but it will not handle apngs at all (it will take the first frame and compress it).

I find it's much easier to individually compress the frames, then reassemble the apng. I use scriptpng to compress pngs usually, which uses a combination of kzip/pngout, zopfli, and other compressors. At one point, scriptpng supported apng, but it looks like the author took it out and I don't have a backup of that version anymore from way back in 2011.

To assemble the compressed png frames, a guy wrote a program for me called pngseq2apng and apng2pngseq. If you use an apng assembler to assemble all of the frames, it does a crap job at compression, but usually does a good job at optimization.

Jamaika
22nd July 2016, 03:38
APNG is a botched together format and is tough to optimize well.
OK, but why I changed the theme compression JPG to APNG?
From my way of deduction if someone says he has a better compression ratio through new implementation "Lepton" it had to discard the old packer libzip.
I use old APNG Assembler, who wrote that it is impossible to modernize libzip. There is no update v1.2.7. So I ask about the new technologies packers for PNG. Maybe somewhere they are.

dave.98dslkfjh3
23rd July 2016, 00:03
OK, but why I changed the theme compression JPG to APNG?
From my way of deduction if someone says he has a better compression ratio through new implementation "Lepton" it had to discard the old packer libzip.
I use old APNG Assembler, who wrote that it is impossible to modernize libzip. There is no update v1.2.7. So I ask about the new technologies packers for PNG. Maybe somewhere they are.

It's important to note that "Lepton" and "PackJPG" create a brand new file format from the JPG. It's essentially like changing image.jpg to image.zip. You can take the image out of the zip file, but you can't view it in the zip file without first extracting it.

libzip is based on zlib/gzip which is a standard reference for the deflate data compression algorithm which uses LZ77 and huffman coding. PNG uses deflate, so you can use whatever encoder you want to compress the IDAT of the pngfile. Zopfli (https://en.wikipedia.org/wiki/DEFLATE#Encoder_implementations) is a relatively new deflate encoder by Google that sacrifices encoding speed for space, and is likely on par or similar to kzip (http://advsys.net/ken/utils.htm), another deflate encoder.

PNGs only work when they're encoded under deflate, which is old and not the best data compression algorithm. LZMA (7z) and LZSS (rar) are much better than LZ77 (zip) but we can't use those due to png's limitations.

Apng Assember (http://apngasm.sourceforge.net/) is an OK program that does optimize the image you create by discarding unnecessary data, but then it compresses with either zlib, 7zip or zopfli and ignores any custom compression you had already done on it.

If you want lossy pngs, the only way to do that is through quantization. NeuQuant, Xiaolin-Wu, and octree-split are among the better quantization methods out there. PngQuant (https://pngquant.org/) has some form of quantization that's pretty good, though I don't know what it actually uses, though I do know it uses Floyd-Steinberg dithering. The default Median Cut quantization method found in GIMP is pretty awful in my opinion.

Here's (http://css-ig.net/png-tools-overview) a big description of pretty much all the png tools out there. Note that it's only pngs, not apngs.

The only way to improve on Apng Assembler would be to assemble the png without compression and compress each frame individually.

burfadel
23rd July 2016, 08:23
JPG format is really quite an ancient format, it started out in 1992. If using the latest compression formats like x265 (applied on a still image) the file size is significantly smaller for the same quality. JPG was intended to be superseded by JPEG-2000, from 2000 :), but it never made ground. Considering its age it's not suprising that compression improvements can be made with Lepton. JPG images are compressed anyway, Lepton just improves on this in a lossless manner.

Bloax
24th July 2016, 02:07
"Copyright (c) 2006...2016, Matthias Stirner and HTW Aalen University"
Who's the guy behind PackJPG? Matthias Stirner.

It's PackJPG, except seemingly with some speed/memory usage improvements (seemingly) alongside some compatibility issues with large images.

Motenai Yoda
24th July 2016, 04:10
JPG format is really quite an ancient format, it started out in 1992. If using the latest compression formats like x265 (applied on a still image) the file size is significantly smaller for the same quality. JPG was intended to be superseded by JPEG-2000, from 2000 :), but it never made ground. Considering its age it's not suprising that compression improvements can be made with Lepton. JPG images are compressed anyway, Lepton just improves on this in a lossless manner.

JPEG define only how the data has to be decoded, not how encode it, or which data.

You can't assume actual x264 sports the same quality of the h.264 reference encoder of 2003

also JPEG-2000 fail for many others causes too

burfadel
24th July 2016, 08:39
JPEG define only how the data has to be decoded, not how encode it, or which data.

You can't assume actual x264 sports the same quality of the h.264 reference encoder of 2003

also JPEG-2000 fail for many others causes too

Of course, my point is the JPG format itself is outdated. Even with different JPG encoders, JPG decoders still need to be able to decode it despite their age, as long as they support the JPG spec (progressive or not etc).

Encoders for JPG have improved, just like encoders for h.264 like x264 have improved, but you are still limited by the JPG specification just like x.264 is limited by the h.264 specification. If you go any further, then it's no longer h.264!

JPEG-2000 did fail for many reasons I know, but it was stretching the limits at the time in many ways. It used wavelets instead of DCT. Wavelets were looked into again for h.265 originally, but it was still too complex to be considered viable at the time apparently.

In any case, a new format is required to get over the limitations of the JPG format. One way to look at it is how h.265 compares to MPEG-2.

Jamaika
24th July 2016, 09:19
I'm sorry but for me JPEG Lepton is a farce.
Converter can be downloaded ...
https://github.com/dropbox/lepton/releases
... but the image after the conversion is non-standard and can't be open. Are they so excited?:(
[mjpeg @ 00000000025b3fe0] bits 173 is invalid0KB sq= 0B f=0/0
[image2 @ 000000000077d400] decoding for stream 0 failed
[image2 @ 000000000077d400] Could not find codec parameters for stream 0 (Video: mjpeg, none(bt470bg/unknown/unknown), lossless): unspecified size
Consider increasing the value for the 'analyzeduration' and 'probesize' options
Input #0, image2, from 'image001a.jpg':vq= 0KB sq= 0B f=0/0
Duration: 00:00:00.04, start: 0.000000, bitrate: 95412 kb/s
Stream #0:0: Video: mjpeg, none(bt470bg/unknown/unknown), lossless, 25 tbr, 25 tbn, 25 tbc
[mjpeg @ 00000000025cdec0] mjpeg: unsupported coding type (c7)
[mjpeg @ 00000000025cdec0] mjpeg: unsupported coding type (cd)
[mjpeg @ 00000000025cdec0] mjpeg: unsupported coding type (ca)
[mjpeg @ 00000000025cdec0] bits 173 is invalid
nan M-V: nan fd= 0 aq= 0KB vq= 0KB sq= 0B f=0/0

Nevilne
24th July 2016, 15:52
You're basically complaining that you can't open a zip file with jpeg viewer

On topic pretty sure everyone stopped caring about saving some small amount of space/bw with non-jpeg long time ago.

raffriff42
24th July 2016, 17:39
This small amount of space saving doesn't matter too much for a normal user - but if you're DropBox, and most of your expenses are storage-related, and you can't reencode your customer's images as jpeg2000 etc (because you promised them you wouldn't), then even a 2% reduction in size can affect your profit margin.

Nice of them to open source this thing, since the people most interested in it would be their competition...

dave.98dslkfjh3
25th July 2016, 01:28
"Copyright (c) 2006...2016, Matthias Stirner and HTW Aalen University"
Who's the guy behind PackJPG? Matthias Stirner.

It's PackJPG, except seemingly with some speed/memory usage improvements (seemingly) alongside some compatibility issues with large images.

I guess I should have done the bare minimum of research, lol.

This small amount of space saving doesn't matter too much for a normal user - but if you're DropBox, and most of your expenses are storage-related, and you can't reencode your customer's images as jpeg2000 etc (because you promised them you wouldn't), then even a 2% reduction in size can affect your profit margin.

Nice of them to open source this thing, since the people most interested in it would be their competition...

Are they planning on the users doing this, or is this going to be directly on their storage end? All jpgs will be stored on Dropbox servers as lepton archives and decompressed to be delivered to the customer?

I'll be honest: adding support to image viewers for PackJPG or Lepton archives so they don't have to be decompressed prior to opening is something I would personally want. If the dropbox application syncs a lepton archive and decompresses it back to a regular jpg, that's an awesome way for them to reduce bandwidth from my cell phone taking a picture and delivering it to my computer.

raffriff42
25th July 2016, 13:08
Seems to be a back-end thing only, right now. DropBox Tech Blog (https://blogs.dropbox.com/tech/2016/07/lepton-image-compression-saving-22-losslessly-from-images-at-15mbs/)
We have used Lepton to encode 16 billion images saved to Dropbox, and are rapidly recoding our older images. Lepton has already saved Dropbox multiple petabytes of space...