HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
dropbox
lepton
C++2016–2026
dropbox / lepton · Archived

lepton

Lepton is a tool and file format for losslessly compressing JPEGs by an average of 22%.

Data & DatabasesLibraries & SDKs
Explore on GitHubRead Hacker News discussions
18Distinct people
20Mentions
0Explicit recommenders
5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Lepton is a tool and file format for losslessly compressing JPEGs by an average of 22%.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:03:16 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year20 dated mentions

Observed mentions: 2016-07-14 17:07:27 UTC to 2026-10-07 17:40:36 UTC.

02468102016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 9 mentions; 2 submissions, 7 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC927
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC000
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC101
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC101
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC101
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC101
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC101
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC303

What Hacker News says

20 sources
magicalhippo·Sep 14, 2026
JPEG is a lossy frequency-space compression stage followed by a lossless Huffman coding stage. The second stage is quite generic as such, essentially compressing a stream of bits. So you can relatively easily replace the second stage with something better. And since it's lossless you can easily go back. Dropbox[1] and others have exploited this for reducing storage requirements, converting back on-demand so the client doesn't notice. https://github.com/dropbox/lepton
In The case against JPEG XL
lifthrasiir·Apr 22, 2025
That's the portability bit the presenter mentions, and is a very important concern in practice. But how about recompression? For example many PNG files are suboptimally compressed partly because PNG is an old format and also because many softwares have been too dumb to produce a well-optimized PNG. In that case we may benefit from a transparent recompression, which may be done either by using a better library like libdeflate or by internally using a separate format that can be quickly transformed from and back to PNG. In fact Dropbox did so for JPEG files [1]. When I'm saying "so much better" I was thinking about such opportunities that benefit end users. [1] https://github.com/dropbox/lepton
In Data Compression Nerds Hate This One Trick [video]
keithwinstein·Jan 18, 2019
Hi folks -- study PI here. Happy to answer any questions. We're working on a paper for submission to a research conference soon, so every viewer gives us helpful data for the system to learn in-situ and improve its performance over different kinds of Internet connections and congestion situations. (We are randomizing connections to get either our in-development algorithm or a bunch of competing ABR and congestion-control schemes so we can properly evaluate, so if you get a stall or bad quality...... we'll blame that.) All the source code is at https://github.com/StanfordSNR/puffer and is or will be released with an open-source license. The study is led by my doctoral student Francis Yan, along with Sadjad Fouladi, Hudson Ayers, Chenzhi Zhu, and my colleague Philip Levis. The goal is to train video-streaming algorithms (bitrate selection a
Read the rest
nd congestion control) online, continually, in situ, to minimize stalls and deliver the best picture quality across a diverse range of real-world Internet connections and users. This is from some of the same people who brought you Salsify (functional video compression for lower-latency real-time video: https://snr.stanford.edu/salsify), Lepton (distributed/parallel JPEG compression: https://github.com/dropbox/lepton), Mosh (functional terminal emulation for mobility: https://mosh.org), Remy (machine learning for congestion control; http://mit.edu/remy), and the Pantheon of Congestion Control (https://pantheon.stanford.edu). There are some unusual details of the Puffer system to make experimentation easier (and, we hope, performance better): the ABR algorithm is server-side, and video is streamed continuously over a WebSocket and the client gives asynchronous feedback, instead of using DASH HTTP request/replies. The tcp_info struct (including the delivery rate estimate) from the congestion-control layer is plumbed through to the ABR, and to the neural network that tries to predict "how long will it take to send a video chunk of length y," so it's weakly cross-layer. The "transmission-time predictor" is probabilistic instead of simply producing a point estimate. We encode with libx264 and then measure the SSIM of every encoded chunk to calculate a reward for each possible stream (instead of making the assumption that more bitrate is better -- the correlation is not so good when you consider different times in the same video). And we encode 10 variants of each channel, so more than typical. And everything is done at 60 fps. Of course some of these details mean these algorithms are not going to be deployed any time soon on a production CDN or streaming service, but the hope is to demonstrate the value of some of the ideas in an academic setting for future commercial deployment. The use of WebSockets, MSE, and Opus is why this doesn't work on Safari or on iOS. FAQ here: https://puffer.stanford.edu/faq/ Also I'm happy we were able to make some of the Grafana monitoring public: https://puffer.stanford.edu/monitoring
In Stanford Researchers Launch Free TV Service to Improve Live Streaming Using AI
daniel_rh·Jun 20, 2018
To compress files for a system like Dropbox we would recommend a) check if the file can compress with https://github.com/dropbox/lepton . Lepton has some new flags that can help it compress a wider range of files, so it's not just limited to pure JPEG files any longer. b) then compress it with zlib -6 to get an idea of how compressible the data is. c) if the data compresses by at least a percent with zlib, it's likely to do significantly better with more advanced compression like DivANS. About 1/3 of files in Dropbox fall into that >1% category but aren't compatible with Lepton. For those compressible files, DivANS gets 12.08% savings over zlib with the settings we chose in the blog post. Brotli, in contrast, gets 9.64% savings over zlib on that same data.
In Show HN: DivANS – Rust simd compression algorithm demo in WASM in the browser
niftich·Dec 21, 2016
Dropbox's Lepton [1][2], an additional lossless compression layer that operates on top of JPEG, would make for a smoother transition. If a browser natively supported Lepton, you could serve the compressed version over the wire, and still get the bit-exact original .jpg out at the end, if the user wanted to save the file. Of course, browser support doesn't exist yet. But browser implementors, consider the gains. This isn't promoting an incompatible format, it's getting bandwidth savings while being fully backwards compatible. [1] https://blogs.dropbox.com/tech/2016/07/lepton-image-compress... [2] https://github.com/dropbox/lepton
In A Very WebP New Year from Cloudflare
ptspts·Jul 15, 2016
Portability notes for the Lepton implementation (https://github.com/dropbox/lepton): * Implemented in C++ (-std=c++0x and -std=c++11 work, -std=c++98 doesn't work). * Needs a recent g++ to compile (g++-4.8 works, g++-4.4 doesn't work). * Runs on Linux and Windows. * Runs on i386 (-m32) and amd64 (-m64) architectures. Doesn't work on other architectures, because it uses SSE4.1 instructions. * Can be compiled without autotools (http://ptspts.blogspot.ch/2016/07/how-to-compile-lepton-jpeg...).
In Lepton image compression: saving 22% losslessly from images at 15MB/s
nachtigall·Jul 15, 2016
I would be interested why C++ was chosen for https://github.com/dropbox/lepton instead of Rust? Given the recent usage of Rust for the implementation of Brotli compression (https://blogs.dropbox.com/tech/2016/06/lossless-compression-...) and that it's used for data storage (http://www.wired.com/2016/03/epic-story-dropboxs-exodus-amaz...) this somewhat surprises me. The reasons given for Rust as stated in https://blogs.dropbox.com/tech/2016/06/lossless-compression-... would seem valid here too: > For Dropbox, any decompressor must exhibit three properties: > > 1. it must be safe and secure, even against bytes crafted by modified or hostile clients, > 2. it must be deterministic—the same bytes must result in the same output, > 3. it must be fast.
In Lepton image compression: saving 22% losslessly from images at 15MB/s

Showing the 15 most recent of 20 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.