Does Aphera support my camera?

Our recently published Camera Support page lists 541 camera models, each of which was verified by us. Because “we support your camera” is a promise, and we wanted it to be one that we can keep.

Read on for a look at what goes into building that list: not just once, but for every update we make.

Our camera list

There are dozens of digital camera manufacturers, selling 100s of camera models. Each of them uses a different format for their RAW capture (.ARW, .NEF, .CR3, .DNG, .IIQ, and more), varying everything from how the pixels are stored to how we’re supposed to crop the data before giving it to the user.

We wanted our list to be something you could trust, and something that represents both what the app actually does, and what we claim it does. To do this, we first had to really nail down what “supported” means.

For every one of the 541 names on our list, we can tell you: which version of LibRAW read it, which sample files we’ve opened from it, the name its owner would recognize, and which color matrices are available. Where a person overrode an automated rule, the reasoning why.

That is an unusual thing to be able to say about a support page. Most are a list of names and nothing else: no library version, no date, no indication of what was tested or when.

Organizing the raw data

Almost every RAW application, ours included, uses the open source LibRAW. It does the hard job of decoding every camera maker’s unique data formats, and we’re very grateful for that work. LibRAW itself maintains details of which formats it supports, but it doesn’t give the kinds of guarantees or clarity that we wanted to give to users of Aphera.

To be clear: LibRAW does an enormous amount of testing and validation on their tool, but they have a different goal. Given a file to read, the software does its best to figure it out. If it doesn’t work, that’s because it wasn’t supported. Instead, we wanted to say up front: these are the files we support.

Internally, LibRAW maintains two lists. The first is cameralist.cpp: the names of camera models whose files LibRAW knows how to decode. The second is colordata.cpp: the sensors LibRAW has color information for. They are maintained independently, by different work, and they often disagree.

A camera in the camera list but not color data will open. The pixels will be correct but the colors will be wrong (like, very wrong: think green skin). A camera in color data but not camera list is a sensor whose colors we know how to interpret, but in a file format we cannot read.

Given this, the rule is:

A camera is supported if it appears in both LibRAW’s camera list and color data.

It sounds simple, but each list uses different names to identify a camera. So we manually mapped each one to a common name: what does LibRAW itself call the camera when reading a file?

Reading real files

A name in a list is a claim about a camera, but we wanted proof that it would work when a real file was opened.

To do that, we use a corpus of real RAW files. Most come from raw.pixls.us, a community archive that exists so that software can be tested against real cameras. Another gem of the open source community to which we are grateful. The rest we collected ourselves. Combined that’s 2,191 sample files, across 37 formats.

For each file, we simply hand it to LibRAW and ask which camera made this? The answer comes from LibRAW’s own internal process of identifying a file for purposes of decoding and rendering. That means it’s the same thing that will happen in-app when we ask LibRAW to decode your imported RAW files. Once we have this name, we can link the file to everything else we know about a camera.

That link is what lets our tools answer questions such as: which files in our corpus are from cameras that LibRAW can’t name? Which cameras claim support in both lists but disagree with themselves about color? And importantly: which cameras do we claim support for via the lists, but have never actually opened a file from?

Today, we have 38 cameras in that last category: ones we don’t physically have a file to verify against. Almost all of them are medium format — Hasselblad and Phase One digital backs, several long discontinued, and none of them equipment you can easily borrow. The rest are bodies so new that nobody has posted a file yet.

Those 38 are supported on the strength of LibRAW’s two lists agreeing, without a file of our own to confirm it. That’s a weaker claim than we make for the rest of the list, but we know exactly which 38 they are, and can fill them in as we get our hands on files.

Human powered

The rule and the corpus get us a long way. What’s left is a list of judgment calls. In the current set we recorded 431 manual approvals, and 983 manual rejections. Every one has a written comment so we know why each camera is supported or not.

Phase One IQ3 100MP Trichr — “I want to support it, we need files, and we need a matrix for it as well”

Sigma fp — “its a dng, we could support if we had a file” (the fp L, a different body, is on the list) Kodak DCS Pro 14N — “very old camera”

509 cameras were rejected with some version of “old camera, ok if not supported.” 150+ phones were excluded from the list because they use DNG, Adobe’s standard for RAW files. DNG being a standard means that it doesn’t matter which camera created it, we can accept all such files universally.

By writing each decision down, a year from now when somebody asks why their Kodak is missing, we can provide an answer.

Decisions that expire

There’s one problem with recording decisions like this: they rot over time.

Every one of those 1,414 decisions was made against a specific build of LibRAW. “This camera is fine even though color data doesn’t list it” may have been true of LibRAW 0.22. But LibRAW is actively developed. Cameras get added. Sensor data gets corrected. The reasoning behind a decision can quietly stop applying while the decision itself still looks authoritative.

So we attach each decision to the LibRAW version it was made against, and the moment we import a newer LibRAW, every one of them goes stale and drops out of the published list. All 1,414. A dependency upgrade invalidates every human opinion in the system, deliberately, and then we go and re-confirm them.

It is a genuinely annoying design and we would not change it. The alternative is a support page that drifts: true once, then carried forward forever because nobody remembered to check.

What is your camera called?

Everything above produces a correct list for use by the app. But it’s not enough for our support page, because the names in it are not real camera names. In extreme cases, the names have very little to do with the models you can buy. Take Hasselblad for example. Here’s how LibRAW names them in color data:

Those names describe sensors — a resolution, coating, revision — and say nothing whatsoever about the camera anybody can buy. They are good keys for matching one dataset against another. But they’re not something we can list on our support page.

In another case, Canon sells a body in Japan as the Kiss X9. The same body is the Rebel SL2 in the United States and the EOS 200D in Europe. One camera, sensor, file type, but three names. It’s completely reasonable that the camera’s owner only knows one of these names.

If we list only one of the three names then two-thirds of the people who own that camera won’t find it on the list: it will appear as if Aphera doesn’t support it.

There are plenty more cases to deal with, for example: a Leica D-LUX7 is a rebadged Panasonic DC-LX100M2. A Leica owner is not going to think to look under Panasonic, and should not have to.

Names come from products, not sensors

Fortunately, LibRAW’s camera list is written to describe the cameras that people buy, whereas color data is written to describe sensors. So we do a reverse mapping back into the camera list to find all of the names it can go by.

The camera list is generous: it lists regional names, market designations and rebadges, because it was written by people who knew perfectly well that a camera has more than one name.

When we find missing names, we add them by hand. Fortunately, unlike support decisions, they do not expire when LibRAW is upgraded: the name doesn’t change when the library does.

In all, the result is 433 distinct cameras that go by 541 names. Every name a camera is sold under gets its own line, so a Kiss X9 owner and an SL2 owner each find their camera without having to know it is also an EOS 200D.

Aphera Calibrated, or Standard

Our Camera Support page has two columns: the Camera, and the Color Matrix.

A color matrix is a 3×3 set of numbers that maps what the sensor recorded onto colors that mean something. If it’s the wrong numbers, your photo’s colors look off or just plain wrong. It’s one of the most important things to get right so that each camera’s images look good, edit well, and match closely with other cameras.

There are six places to find a matrix, and we collect all of them for every camera: LibRAW’s built-in color data; what LibRAW derives from a sample file; Adobe’s, by running a sample file through the DNG Converter and reading the matrix that comes out; the manufacturer’s own, when a camera writes it directly; values contributed from published references; and ours, measured. 11,622 matrices in total, from which each camera gets the best available, by priority:

1. Aphera — measured by us
2. Manual — contributed or from published references
3. Adobe’s DNG Conversion
4. The manufacturer’s original DNG
5. LibRAW’s built-in – also sourced from Adobe’s data

For simplicy of the Color Matrix column, we list option (1) as “Aphera Calibrated” and everything else as “Standard”.

You’d think camera makers would publish these values, but alas. In Aphera, every supported camera gets the best matrix available. Over 70% of them have our own tuned values.

You’re supported

Every camera on Aphera’s Camera Support page is something we can vouch for. As we make changes to our own software and bring in new versions of LibRAW to support newly released cameras and formats, we wanted to be confident that every camera keeps working, and keeps rendering the same as it did. Where it changes for good reason, we’ll communicate that.