Future-proof >8-bit lossy high quality compression format for archival purposes

The video scene has been shaken up by h.265 which introduced amazing compression levels over its h.264 predecessor, but what about us static image monkeys?

I’m looking for a high quality lossy compression format I could store my photos in for archival purposes. I want to use Adobe RGB or even ProPhoto RGB so I would like this format to support 10-bit precision or so. Is there anything like that showing signs of not dying out anytime soon?

PGF from 2000 supports 8 or 16-bit, nothing in-between AFAIK, and it’s 16 years old and still generally unsupported.

JPEG 2000 from 2000 is equally old and just not exciting by today’s standards. I couldn’t find any definitive information on supported bit depths, but its likely it supports 10-bit files (in addition to the obvious 8- and 16-bit modes), so at least there’s that.

JPEG XR seems good, if you can swallow who developed it. It supports a selection of bit depths including 10-bit. It’s not as old, coming from 2009, so one would assume it uses newer technology. It’s released under a BSD licence. But I don’t have any Linux program which would support it.

WebP from 2000 is a derivative of the shitty VP8. It is also released under the BSD licence. It only supports 8-bit YUV 4:2:0. Not for us.

BPG from 2014 supports “8 to 14” bits per sample, so probably 10-bit too, and it supports chroma subsampling off/4:2:2/4:2:0. It boasts much better compression than JPEG, metadata and lossless compression. It is based on h.265/HEVC, yay! But nothing supports it yet, boo (but web browsers can support it via 76kB of javascript, nice). It seems like a good choice. Maybe we should push for support of BPG in our software?

Comparison:
http://xooyoozoo.github.io/yolo-octo-bugfixes/#swallowtail&jpg=s&bpg=s
Specifically try “Mascot”, “Swallowtail” and “Zoo bird head”.

Get BPG:
http://bellard.org/bpg/

It seems that the technology BPG uses has licencing issues which may/does exclude it from free use.

Daala is a competing technology work-in-progress from xiph.org, intended to be a free format.

tiff/png and then xz/bz2 compress?

I like the idea of BPG in general, but I don’t normally associate the terms lossy with archival. Is there a particular reason to go with a lossy solution vs. (I’m assuming) the raw files?

I feel that the prices of storage drop so nicely that it would take a really large image collection to start worrying too much about it (that’s just me). I only recently switched out my primary NAS drive due to drive failure (I was miles away from filling up the 4TB).

Still, BPG does look neat (especially with animations - something neat for cinemagraphs and comparison images vs. animated gifs).

1 Like

A post was split to a new topic: Creating Cinemagraphs

3 posts were merged into an existing topic: Creating Cinemagraphs

Maybe you want HEIF or lepton on top of your jpegs.

I can’t believe FLIF - (Free Lossless Image Format) is not mentioned here. Not my favorite acronym though.

that’s the one I was thinking of but couldn’t remember…

Any format that has licencing encumbrances will never be fully supported, so is a bad choice for archives, IMHO.

Any lossy format is also a bad choice for archives.

Technically, I like the successors to JPEG, but they lack support.

I think you should choose a lossless format that is currently widely supported. So that would be TIFF or, arguably, PNG. Sure, the compression for photos isn’t great. If you don’t need metadata, PNM is a good choice: dead simple, so a program to read PNM can be written in a couple of minutes.

You (or someone) will also be considering the physical media, and will probably conclude that they need refreshing every few years. When that is done, consideration should be made about also changing the file format.

Just a comment about BPG - this is better portable graphics, IMHO not really suitable for archiving. This is 0.9.6 AFAIK not much different from 0.9.7 Using Kubuntu 16.04

Image Encoder version 0.9.6
usage: bpgenc [options] infile.[jpg|png]

-b bit_depth set the bit depth (8 to 12, default = 8)
-lossless enable lossless mode
-e encoder select the HEVC encoder (x265 jctvc, default = x265)
-m level select the compression level (1=fast, 9=slow, default = 8)

First thing to note is the limitation on import formats jpg/png, so bit depth at the moment is not too relevant. Then, do you need to worry about the license unless maybe in the USA?

the optional JCTVC HEVC reference encoder is released under the BSD license.
Some of the HEVC algorithms may be protected by patents in some countries

Plenty tests around, but here are mine.
lossless, is a dead loss. Taking a typical jpeg from a digital camera 7.5 MB, lossless = 15 MB

Different matter with default (x265) compression, file size 1.16 MB and with jctv, file size 0.9 MB
What is the trade off, (depends on computer but as a comparison) Encoding speed: x265 took 30 seconds, jctv 2 minutes.

Is it practical. There is a Gimp plugin to load a .bpg file https://i.imgur.com/T12mk0e.jpg but not export one.