The reason this can be done with JPEGs is the compression hasn't been updated. There are folks that have used h264 for compressing images and webp uses vp8 compression, both with much better results than JPEG.

Lepton is cool because it helps make existing technology a whole lot better, but what we actually need is a better image format.

You wouldn't see the same leap for videos because people have been working hard to make those great for a while while JPEG has been left to rot.

All that is true, but it misses out a key point: Lepton is risk-free.

I could re-encode all of my JPEG photos with a better codec, but the problem is that then they have gone through a lossy compression scheme twice: once with JPEG, and once with the new codec. This could ruin the image quality on some photos, giving them nasty artefacts.

The newer codecs might even be hindered further by the fact that they are being asked to compress an image that's been JPEG'd. I don't think any of the codecs you mentioned are tuned to work their best with image data that already has been butchered by JPEG. They expect to be given the 'pure' original image. This may well cause the codec to perform worse than expected.

Using Lepton gives none of these risks, since jpeg<->lepton is lossless. I could throw away all the JPEGs afterwards, safe in the knowledge that if I want to go back, I can.

Also, it's not really true that JPEG has been left to rot. There are lots of programs available that greatly improve upon the basic JPEG compression, while still outputting a JPEG file that any compliant decoder can read. And there's an even simpler way to shrink your photo file sizes - just drop the JPEG quality level slightly. Most cameras and programs default to a very high quality value. Dropping the default by even a tiny amount can produce remarkably smaller files, and you'll probably never notice the miniscule image quality loss.

I suspect that JPEG is so popular because it is 'good enough'. Most people and programs don't care so much about squeezing out smaller files, so they'll keep using JPEG regardless.

Yes, it should all just switch to FLIF

http://flif.info/

> 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

> outperforms PNG, lossless WebP, lossless BPG, lossless JPEG2000, and lossless JPEG XR

PNG was not designed to be used for photograph-like images. The rest of those were not designed to be lossless formats, the lossless version is just a tacked-on afterthought.

Very unsurprising to find a codec that can beat those.

In my own tests, I found FLIF generally beats PNG (PNG Crush/Optipng both in brute-force mode) for comics (greyscale, majority white) as well, but by a less significant margin.

It's also worth noting that there aren't many other lossless formats, so it's still a valid comparison. I'm sure neither TIFF nor RAW outperform FLIF either.

That's not a valid comparison for TIFF. TIFF is a container which supports multiple compression algorithms. You could plug FLIF in as a compression algorithm and use it directly.

Alright, well against current commonly supported TIFF compression algorithms such as LZW, Packbits, and ZIP.

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)

What are the processing implications?

The lack of processing comparisons raises that question pretty loudly, and it's definitely important in a mobile world. There's more to performance than size

Actually, high quality JPEGs are just as good as BPG, VP8, etc:

https://people.xiph.org/~jm/daala/revisiting/subset1_psnrhvs...

so when you use a better encoder like mozjpeg, JPEG is actually competitive with the newest formats, given enough quality

it gets slightly grainier results with blocking artifacts, but BPG and WebM look like they had a painting algorithm blur out all of the details

Indeed. In one project where I converted jpegs to webp I saw around 70% savings at similar quality. This was on Android where it's fully supported. On the web pretty much only Chrome supports it, I'm not sure why Firefox, IE and Safari are hesitant.

This [1] is from 2013, so I don't know how it holds up, but I found it in the criticism section of the Wikipedia article for webp [2].

edit: This [3] is a follow-up from 2014 to the article/study from 2014.

TL;DR: "We consider this study to be inconclusive when it comes to the question of whether WebP and/or JPEG XR outperform JPEG by any significant margin. We are not rejecting the possibility of including support for any format in this study on the basis of the study’s results. We will continue to evaluate the formats by other means and will take any feedback we receive from these results into account."

[1]https://blog.mozilla.org/research/2013/10/17/studying-lossy-...

[2]https://en.wikipedia.org/wiki/WebP#Criticism

[3]https://blog.mozilla.org/research/2014/07/15/mozilla-advance...

I've heard that Safari (10) on upcoming iOS 10 supports webp. Don't know about Safari 10 on macOS Sierra.

Where did you read that? Since Apple has yet to commit on H.265, ( Due to Insane patent Licensing payment ), I am hoping they jump onboard with Open Media Alliance.

I'd love to have something like this for archiving DVD ISOs though, where the VOBs are compressed with old-school MPEG.

It wouldn't get much smaller. The reason DVDs are such a high bitrate compared to Handbrake rips isn't that MPEG2 is inefficient, it's because there's a keyframe twice a second. Most movie rips have a keyframe every 10 seconds.

It's mostly to let you fast forward, but there is a technical issue there. MPEG2 decoders aren't all mathematically identical, so what happens is the picture tends to drift away from the real thing after a while, and there's hacks like frequent keyframes and flipping the smallest DCT coefficient to get around it…

I've always wondered if it would be possible to losslessly convert the MPEG2 DCT coefficients, motion vectors etc to the equivalent subset of h.264 and then take advantage of the better prediction and entropy encoding of the later standard.

Maybe you could even go further and actively remove keyframes (in a fully reversible way, just keep a record of where they were)

I'm not sure how much you would save, and for losslessly archiving DVDs you might be better off creating a special format like Lepton for mpeg2

The first part of your question was posed on Doom9 in 2009. It's the opinion of Dark Shikari, longtime lead x264 developer, that it would be possible [1].

Not sure what you mean by the keyframe removal, though. Such an act would be lossy, significantly impair any P-frames or B-frames (unless you majorly modify them), and, it frankly doesn't sound very reversible. Mind elaborating?

[1] http://forum.doom9.org/showthread.php?t=149895

What I mean is transforming I-frames into equivalent P-frames (or even B-frames) that decode to the exact same pixels. The transformation might result in something that is bigger than a directly encoded P-frame (which can tolerate some small errors) but I suspect the new P-frame will be smaller than the original I-frame.

There is no restriction that P/B-frames only reference I-frames, so you don't even need to touch those frames.

For conversion back to MPEG2 it would be ideal to detect or mark the original I-Frames, so you can convert them back (a simpler transformation). But you could also pick any random P/B-frame and convert it to an I-frame with little issue.

Why bother trying to losslessly compress your DVDs when they're already a low quality, compressed MPEG2 source? The small amount of content that isn't available in higher quality won't take up that much space left as is.

This is why I come to HN. To find out what's in my video archive and how easy it is to replace.

In the case you're being facetious, maybe you could clarify how big is your video archive exactly and what sort of compression you're trying to achieve on it?

Shouldn't you just use Handbrake and H.264/AAC? (Assuming your computer is fast/new enough to play it back.)

The article (and the person you're replying to) is referring to lossless compression. Converting to H264 and AAC may maintain a high quality at a lower bitrate but they're definitely not lossless.

I assume he'd want it to be lossless, as is the case with Lepton.

How does h.264/5 not fit the bill?

I don't think h.264/5 is bit-for-bit retrievable is it? Neuronexmachina might be wanting to be able to get back the 1:1 version maybe?

Can you run those losslessly?

While there's a lossless H.264, it doesn't fit the implied use-case proposed in the thread. Using lossless H.264 to recompress lossy MPEG-2 would be akin to using PNG to recompress a JPEG -- silly and wasteful.

Sure, it's an inexact analogy because PNG is not a block-based DCT coder, but all lossless H.264 does is set the quantizer as absurdly high as it needs to go to losslessly encode a particular frame. Staring from a compressed source, this is not a good recipe for achieving a space-saving result.

Is JPEG, PNG, etc a container format that could use arbitrary compression, like MKV? Or do we need a brand new format.

The JPEG file format is pretty detailed, there are lots of places in the file where you could indicate that the image has been compressed with a different algorithm. But it wouldn't really help, because older decompressors will still not be able to interpret the new codec. They would be able to parse the file and read the metadata in it - like image width and height, timestamps, camera details, and so on, but there's no way it can decompress the data.

PNG is a very nice, extensible container format. In principle you can use it to store arbitrary image data, and still make use of all established metadata fields.

In practice you probably shouldn't do that without changing the file extension and the magic bytes to avoid confusion among users and poorly written software.

While PNG (and libpng) are reasonable for their intended purpose as a GIF replacement for simple RGB and greyscale graphics, it doesn't compare when it comes to the power and flexibility of TIFF, from sample format and depth, to sample count, image orientation, tiling and many additional features.

TIFF is showing its age at this point, with a some high-end scientific applications switching to HDF5. But PNG simply isn't featureful enough for this type of data.

If I remember correctly PNG can use different compression algorithms per scanline, although I doubt it's ever used as such.

perhaps BPG is better? By the great Fabrice Bellard

http://bellard.org/bpg/

BPG is based on h265

Thanks for testing this! For archival purposes, be sure to check the exit code of the lepton binary after compressing each JPEG: the default parameters only support a subset of JPEGs (you need to pass -allowprogressive and -memory=2048M -threadmemory=256M to support a wider variety of large or progressive JPEG files). Lepton will not write images that it is unable to compress using the settings provided. In those cases be sure to keep the original JPEG.

Hi Daniel, very cool project! I am interested in hearing your thoughts on alternative image formats / compression methods.

WebP is very promising (also based on VP8) for lossless and lossy compression. Have you considered using it to compress PNGs in the same way Lepton is compressing JPGs? Odds are it wouldn't be bit-perfect though (despite being pixel-perfect).

Also interested in hearing about the tradeoffs between server-side decoding and client-side. Not to keep focusing on it, but WebP has native support in Chrome and javascript decoders for everything else.

I think it is a very exciting time for image formats with several promising new ones on the way (WebP, FLIF, maybe BPG but possible legal issues).

How much better do you think it could get with JPEGs encoded with Lepton in mind?

The best I've seen is a new compressor at http://encode.ru/threads/2459-EMMA-Context-Mixing-Compressor

Can also recompress GIF and some RAW formats, but is much, much slower

I'm running over several terabytes and on the 5k images I've done so far (3.6GB), the compression has been 0.78x, which is damn good for lossless compression!

EDIT: 17GB now (my server is kinda slow) and it's still holding at 0.78x.

It's not really "lossless" if it only works with a lossy format though, right?

Yes and no. It's not a lossless way to encode an image, but the Lepton step itself doesn't add any loss that wasn't already present in the JPEG to begin with, and it generates a smaller file overall.

Over 3D video files...

It seems like the real bottleneck here is binary... why can we not start supporting base 10 yet? Or even base 64? a-Z+0-9?

Someone just had to mention that _stupid_ show. Seriously. By empowering that show, you're just making fun of yourself and all the other programmers on here.