Slashdot Mirror
Dropbox Open Sources New Lossless Middle-Out Image Compression Algorithm (dropbox.com)
Dropbox announced on Thursday that it is releasing its image compression algorithm dubbed Lepton under an Apache open-source license on GitHub. Lepton, the company writes, can both compress and decompress files, and for the latter, it can work while streaming. Lepton offers a 22% savings reductions for existing JPEG images, and preserves the original file bit-for-bit perfectly. It compresses JPEG files at a rate of 5MB/s and decodes them back to the original bit at 15MB/s. The company says it has used Lepton to encode 16 billion images saved to Dropbox, and continues to utilize the technology to recode its older images. You can find more technical details here.
This headline sounds a lot like a press release from Pied Piper, the fictional company in the TV show "Silicon Valley".
From TFA: "Lepton decode rate when decoding 10,000 images on an Intel Xeon E5 2650 v2 at 2.6GHz"
Is this actually a "middle-out" compression, or is that just a joke? Do we know what the Weissman score is?
It can both compress *and* decompress.
I'm all for companies open-sourcing cool algorithms. But not a great choice on the name. There are already several products out there called 'Lepton'. There's a software CMS, and also FLIR's thermal sensors are branded 'Lepton'. (Worth noting - Lepton IS an actual word so it probably won't qualify for Trademark protection. But an Apple Music vs. Apple Computer like scenario is not impossible to conceive.)
Encoding the image with the coefficients is not the lossy part. The lossy part is when you ditch the coefficients which contribute little to the image, and when you downsample the chroma.
After reading their blurb, it looks like the middle-out thing was a bit of a joke Their use of the term 'middle-out' is not unreasonable but refers to something much more specific, and less fundamental, than what seemed to be depicted in the TV show. Their 'middle' is the just the place where two squares of the image meet.
The
They are basically just bringing the entropy coder from JPEG2000 into JPEG... Why the heck not just fully re-encode the images in lossless JPEG2000 instead? There is a good reason why the DWT was used instead of DCT on JPEG2000, it is because it yields higher coding efficiency. It is also why JPEG2000 is the standard format for digital cinema (yes, movies are coded intra-only with JPEG2000).
So you are an idiot. If you run a JPEG through Lepton the ORIGINAL file (from Lepton's point of view) is the JPEG. Not the Nikon raw file which it has now knowledge of.
This isn't a "better than JPEG" format. It's a "store existing JPEG files your users upload & use more efficiently" format. Flickr, for instance, could theoretically save 22% of its disk space using this.
This isn't about restoring a JPEG file back into its original RAW format. The information lost from converting RAW to JPEG is gone. There is no way to get that back.
This is about storing JPEG files more efficiently. DropBox is in the business of providing cloud storage, and it is in their best interest to keep their costs as low as possible. The more they can compress data for their customers, the more efficiently they use their infrastructure. Some files such as text documents are easy to compress. Some files such as JPEG files are difficult to compress, especially with lossless algorithms.
For DropBox, this allows them to store the LEP representation of a JPEG file instead of the actual JPEG file. This saves them approximately 22% of their storage needs. They can then decompress it on the fly whenever a user tries to read the original JPEG file, essentially trading savings in storage costs for a bit of extra CPU demand. As long as the compression is lossless and the user sees acceptable performance, there is no user impact.
Depending on the cost of extra CPU cycles vs. the cost of reduced storage, and the relative mix of JPEG files vs. other data files, this could save DropBox quite a bit of money.
It's not a file format, it's a compression algorithm that happens at the data storage level. This is similar to compressing a hard drive -- the files are individually compressed, but the file formats are the same, and the OS handles the compression/decompression seamlessly so that the applications don't even know they're accessing compressed versions of the file formats they normally use.
You can keep all your JPEGs, and with the open-source license, compress the contents of a drive or partition with this algorithm and save maybe 20% or so of the space the JPEG files took up. Not worth it for most people but photographers and image sites might save a lot of money using this.
I think he meant Phil Katz who wrote PKZIP.
If they're smart (and they are) the decompression will happen on the user's computer, in the web browser/native client.
Making it (almost) a free lunch for dropbox.
Look, they clearly state that the operate at the level of JPEG-files. So, where is the confusion coming from? They are analyzing JPEG files and using features of that format to compress the already compressed files further.
Which I, honestly, find very impressive.
The reproduce JPEG files in a bit-by-bit faithful fashion. And the have tested in on 16 million (or was it billion) files where it worked without problems plus they don't replace user files unless they have checked that it decodes correctly. I presume that the process is actually transparent to the Dropbox user.
I don't see the problem that you have with this, sorry.
Good work lads!
Or more likely they'll build it into their clients and do the compression on the user's side, saving them on both disk space and bandwidth.
Depending on the cost of extra CPU cycles vs. the cost of reduced storage, and the relative mix of JPEG files vs. other data files, this could save DropBox quite a bit of money.
Better yet, do it in the client at no CPU cycle cost to Dropbox, and also reducing data transport. Dropbox controls the desktop, mobile, and web clients, so this would be easy to do, and could revert to server-side translation from LEP to JPG for e.g. API clients etc.
What resolution, bit depth, and JPEG encoding/compression methods did those images have? How compressible were those images with something generic like LZMA2?
JPEG2000 suffered from the same problem JPEG initially did - it was slow. I remember downloading the first sample JPEG images in the early 1990s. An 800x600 image took about 20 seconds to decode on my PC back then. JPEG2000 had a similar problem, though it was asymmetric. Over 1 min to encode a 3504x2336 image from my DSLR, about 5-15 seconds to decode.
JPEG didn't have any competitors, and the growth of the Internet and Web made smaller-size picture files very important in the coming years Couple that with the rapid development of digital cameras in the late 1990s, and the use of photos on the web exploded. So as computers became faster, the decode time approached zero and JPEG eventually became the standard.
JPEG2000 faced rapidly increasing network speeds, decreasing storage costs, and a large growth in digital video. So even though computer became faster, it didn't really matter since it took less time to transmit the larger image file over the now-faster network than it took to decompress a JPEG2000 image on the now-faster computer. You could easily buy a bigger HDD to compensate for the larger size of other image formats, and you did so anyway to store all the videos you were recording.
This is largely the reason JPEG has hung on despite being over 20 years old (even MPEG2 was displaced by MPEG4 and now by h.264/h.265). Compared to modern storage capacities and network speeds, JPEGs are small enough that making it 22% smaller just doesn't matter. Unless you're a massive storage company dealing with billions of JPEG files.
It is because the idiots in JPEG 2000 committee did everything to keep people, especially web browser development teams away from that excellent format.
Now 4K monitors and ultra resolution phones around, watching web developers struggle with 5-6 different files of same photo, I really feel pity. That was a solved problem, both multiple bandwidth& resolution and the compression rate.
There is a reason we deal with JPEG files today, ask JP2 committee. Even MS stayed away from it fearing the patents.
PR? The code is on github, and imho a very nice accessible explanation of their algorithm is in the linked article. They developed some neat software to save money by essentially modernizing JPEG to compress beyond the 8x8 blocks it was designed to use and, having done that, are now letting other people use it too. What is with your crabby, paranoid attitude? Instead of being an asshole, you could just, you know, build the code yourself and experiment with it, rather than sneering at a gift horse. This is exactly the use case for open source software.
Although I would prefer if they explained the sampling methodology for their images, they do present a few simple scatterplots of (de-)compression performance as a function of original JPEG file size. It's not as in-depth as xiph.org foundation's stuff, but it's a hell of a lot more than a PR piece.
"They were pure niggers." – Noam Chomsky