I'm playing with image-optimized diffs for storing edits to artwork. Version control seems to treat images as binary blobs, which means changes to common compressed formats like PNG/JPEG rewrite ≈90% of the file, so updates eat roughly the same space as storing separate files anyway.
Instead of writing some bit-twiddling code myself, I had an idea. We already have highly optimized algorithms for storing differences between images: video codecs.
What video codecs out there allow for lossless reconstruction through their interpolation (“b”) frames? The most common ones all understandably err on the lossy side.
For example, HEVC lossless mode – the encoder will find optimal inter or intra predictions and then losslessly code the residual.
(Moved from a comment.)
Related
I have this image (photo taken by me on SGS 9 plus): Uncompressed JPG image. Its size is 4032 x 3024 and its weight is around 3MB. I compressed it with TinyJPG Compressor and its weight was 1.3MB. For PNG images I used Online-Convert and I saw webp images much more smaller even than compressed with TinyPNG. I expected something similar, especially that I read an article JPG to WebP – Comparing Compression Sizes where WEBP is much smaller that compressed JPG.
But when I convert my JPG to WEBP format in various online image convertion tools, I see 1.5-2MB size, so file is bigger than my compressed JPG. Am I missing something? WEBP should not be much smaller than compressed JPG? Thank you in advance for every answer.
These are lossy codecs, so their file size mostly depends on quality setting used. Comparing just file sizes from various tools doesn't say anything without ensuring images have the same quality (otherwise they're incomparable).
There are a couple of possibilities:
JPEG may compress better than WebP. WebP has problems with blurring out of the details, low-resolution color, and using less than full 8 bits of the color space. In the higher end of quality range, a well-optimized JPEG can be similar or better than WebP.
However, most of file size differences in modern lossy codecs are due to difference in quality. The typical difference between JPEG and WebP at the same quality is 15%-25%, but file sizes produced by each codec can easily differ by 10× between low-quality and high-quality image. So most of the time when you see a huge difference in file sizes, it's probably because different tools have chosen different quality settings (and/or recompression has lost fine details in the image, which also greatly affects file sizes). Even visual difference too small for human eye to notice can cause noticeable difference in file size.
My experience is that lossy WebP is superior below quality 70 (in libjpeg terms) and JPEG is often better than WebP at quality 90 and above. In between these qualities it doesn't seem to matter much.
I believe WebP qualities are inflated about 7 points, i.e., to match JPEG quality 85 one needs to use WebP quality 92 (when using the cwebp tool). I didn't measure this well, this is based on rather ad hoc experiments and some butteraugli runs.
Lossy WebP has difficulties compressing complex textures such as leafs of trees densely, whereas JPEGs difficulties are with thin lines against flat borders, like a telephone line hanging against the sky or computer graphics.
I have some files encoded using the H.264 codec.
There is a loss of quality when I convert them from H.264 to H.265.
I imagine I should convert them back to raw/original file format, then encode them into H.265.
Is it possible to decompress/decode H.264 into the original format (perhaps using FFMpeg)?
Is it the best way to convert from H.264 to H.265 without quality loss?
Thank you again for your help,
H.264 is lossy; the quality is lost at encoding time. There is no way to reconstruct the original from encoded form. In contrast, decoding is lossless - it produces exactly all of the information present in H.264 file, no more, no less. If your video editing software is not horrible, your H.264->H.265 conversion is the highest quality you can theoretically achieve given the compression settings you provide (without finding your original uncompressed file); there is no benefit in a separate decoding step, as that is what your software needs to do anyway.
Imagine a bad photocopy: there is no unphotocopier that can give you the original. That's what is happening with lossy compression.
What are the state-of-art algorithms when it comes to compressing digital images (say for instance color photos, maybe 800x480 pixels)?
Some of the formats that are frequently discussed as possible JPEG successors are:
JPEG XR (aka HD Photo, Windows Media Photo). According to a study the Graphics and Media Lab at Moscow State University (MSU) image quality is comparable to JPEG2000 and significantly better than JPEG, compression efficiency is comparable to JPEG-2000
WebP is already tested in the wild on Google properties mainly, where the format is served to Chrome users exclusively (if you connect with a different browser, you get png or jpg images instead). It's very web-oriented
HEVC-MSP. In a study of Mozilla Corporation (oct 2013) HEVC-MSP performed best in most tests, and in the tests that it was not best, it came in second to the original JPEG format (but the study only looked at the image compression efficiency and not at other metrics and data that matters: feature sets, performance during run-rime, licensing...)
Jpeg 2000. The most computational intensive to encode/decode. Compared with the regular JPEG format, it offers advantages such as support for higher bit depths, more advanced compression and a lossless compression option. It is the standard comparison term for the others but it is a bit "slow in acceptance".
Anyway JPEG encoders haven't really reached their full compression potential after 20+ years. Even within the constraints of strong compatibility requirements, there are projects (e.g. Mozilla mozjpeg Project or Google Guetzli) that can produce smaller JPG files without sacrificing quality.
It would depend on what you need to do with the encoded images of course. For webpages and small sizes, lossy compression systems may be suitable, but for satellite images, medical images etc. lossless compression may be required.
None of the formats mentioned above satisfy both situations. Not all of the above formats support every pixel format either, so they cannot be compared like for like.
I've been doing my own research into lossless compression for high bit depth images, and what I've found so far is that a Huffman coder with suitable reversible pre-compression filtering beats jpeg2000 and-jpeg xr in terms of file size by 56% on average (i.e., makes files less than half the size) on cinematic real world footage and faster. I can also beats FFV1 in the limited tests I've conducted, producing files under half the size even after FFV1 has truncated the source image pixel depths from 16 bits to 10 bits. Really most surprising.
For lossless compression ratios FLIF is ranked number one for me, but encoding times are astronomical. I've never made a file smaller than a FLIF file when compared. So good things come to those who wait. FLIF uses machine learning to achieve its compression ratios. Applying a lossy pre-compression filter to images before FLIF compression (something the encoder enables), creates visually lossless images that competes with the best lossy encoders, but with the advantage that re-encoding the output files repeatedly won't further reduce quality (as the encoder is lossless).
One thing that is obvious to me - nothing is really state of the art currently. Most formats are using old technology, designed in a time when memory and processing power was a premium. As far as lossless compression goes, FLIF is a big jump forward, but its an area of research that is wide open. Most research seems to be into lossy compression systems.
I'd like to batch convert my entire photo library from NEF/RAW format to a more suitable format for storage. By that I mean I would like to keep the higher bitrate data, potentially for future 'developing', but I want a smaller file footprint. I realize I could just zip them into an archive but I would prefer they were still in a browsable format.
I'm currently considering going with JPEG XR (i.e. HD Photo) since it supports HDR bitrates (giving me some good room to change exposures in the future) and decent enough lossy and lossless compression (though I'm not sure HDR will work with lossy). I'm also aware of the WebP format but while it's compression and quality are phenomenal it will not work for storing my HDR data intact. I realize the demosaicing data is gone if I don't use NEF/RAW but it's a compromise I'm willing to make as long as I can keep that higher bitrate data. I've considered TIFF as well but ruled it out due to it only supporting lossless compression.
Can anyone recommend an alternative to these formats or perhaps comment on their own experience with the JXR format, specifically using the MS JXRlib?
For raster images there is:
JPG is for natural scenes
PNG or GIF for geometric scenes that are characterized by smooth colors, straight lines and gradients.
For vector animation there is SVG
And for raster video there are various MPEG codecs which do a good job for natural scenes.
So my question is, what should I use for a video which is exclusively rasterized smooth colors, lines and gradients?
You can use animated PNGs.
http://people.mozilla.com/~dolske/apng/demo.html
Try Huffyuv. It is a lossless codec that might work well with the kind of video you are talking about. Since it is lossless, file sizes may be a lot larger, but it is worth a try. What you are describing (fewer colors and detail than a natural scene) might compress acceptably.
The problem with geometrics and cartoons is that Mpeg 1/2/4, VP3, Theora, MJPEG, and the like use chroma subsampling and block based motion compensation with 8x8 DCT blocks, same as JPEGs. This works okay for lots of colors and motion; our brains fill in the difference until the cable box freezes and we see the blocks. It does not work well with things with a lot of lines and fewer colors.
MNG, but it looks like it's not very well supported.
If Windows formats are an option, use the screen codec:
http://www.microsoft.com/windows/windowsmedia/forpros/codecs/video.aspx#WindowsMediaVideo9Screen
There is a video codec that encodes each from as a PNG image (like MJPEG encodes each frame as a JPEG) called CorePNG
Actually, GIF is terrible for images with gradients. JPEGs are good for anything with lots of details, gradients, etc. GIFs and PNGs are good for, basically, anything with flat colors (like cartoons and such).
More info from sitepoint.com
Lagarith is another good lossless video codec, like Huffyuv
i'm a big fan of x264, which is a free (as in freedom) h.264 encoder. recently, support for at least one colorspace with proportionally more chroma samples was added, meaning it can achieve extraordinary, near-lossless compression on raster graphics. be sure to use a high (low number) quality setting. i prefer 0 - you may be surprised how small the output file is, given your input.