645 PRO: RAW Redux

We’re doing some really innovative things with our new iPhone camera app, 645 PRO. One of these is to save an image that is appreciably less processed than any other to yet be captured by iPhone. We spent a lot of time (and discussed with quite a few people) before deciding what to call this. We decided the term “RAW image data” was the best option.

Well, we were wrong.

The term RAW means a lot of different things to a lot of different people and we thought our modified use of it was just fine (helped along by the fact that quite a few people agreed with us). But the gap between what we’re delivering and something that can rightly be called “RAW image data” is, as some have pointed out, actually too big. From now on we’re going to refer to the files we produced as “developed RAW”—dRAW—TIFF files.

The tell-tale on the app’s LCD screen, instead of reading +RAW will read +TIFF, and we’re updating all our marketing materials and the User Manual to reflect the change.

So. Why not just call them plain TIFF files? After all, that’s what they are, aren’t they?

There are two reasons. The first is the narrowly technical one that the TIFF specification allows for all sorts of image data to be wrapped up in a TIFF, and we want to say what sort of data is wrapped up in ours. The second is platform-specific, and is to do with one of the substantial differentiating factors between 645 PRO and most (if not all) other iPhone camera apps.

What follows may be boring if you’re the sort of person that gets bored by technical minutiae, but it’s important if you’re the kind of person that likes such things!

Let’s start by looking at what happens inside a typical higher-end camera such as a DSLR when you take a picture. (the first two graphics have been adapted from ones in an excellent article by Bob Atkins at Photo.net).

 

The yellow section is the gathering and organising of the RAW image data, which brings together the truly “raw” image data from the sensor  with the settings on the camera at the time (such as white balance, sharpness, saturation and many other elements). If the photographer has chosen to save a Camera RAW file, these two elements can then be saved as such, typically in a file format that is proprietary to the camera manufacturer, for later “development”. If the photographer has chosen to save a JPEG as well as (or instead of) the RAW file, a development phase takes place in-camera. The image data goes through a process called Beyer interpolation* and the settings are applied. You now have what I call a “developed RAW”—dRAW—image in the camera’s memory. The final stage is to apply JPEG compression—to varying degrees depending on the camera in question and the quality setting that has been chosen—and then save the file in the JPEG format.

If a Camera RAW file has been saved, this can then be transferred to the computer and opened up in an software able to read the specific Camera RAW format and, again developed. Bayer interpolation is applied and then the settings can be applied. Crucially these can be adjusted before being applied, allowing for all sorts of interesting corrections. Got the white balance a little wrong on the day? Not a problem, when you develop the Camera RAW file, that can be fixed. Once the development has been completed, the resulting image can then be saved as a JPEG (generally after going through a process of JPEG compression, as in the camera) or, more typically, another format, generally a TIFF.

TIFFs are used because, mostly, they are either uncompressed or compressed with the “non-lossy” LZW approach which is a clever way of making the files smaller without altering any of the image data. JPEG compression, on the other hand, is “lossy”, which means that some of the image data is modified in order to make the file size smaller; the greater the degree of compression, the greater the degree of modification (and, the more times a JPEG is opened, edited and re-compressed, the more this becomes visible). For the majority of leisure photographers, the quality loss from the amount of compression added in-camera (especially at “high quality”) is an irrelevance, but if you’re after maximum image fidelity, any lossy compression is a Bad Thing, and compound lossy compression (where images are compressed and then re-compressed in a lossy manner) is even worse.

In the world of iPhone apps, things tend to be slightly different. And the difference is significant if you care deeply about image fidelity. With the default Camera.app supplied by Apple (and also apps that use the version of it available to developers, which can generally be identified by the fact that their camera module looks just like the default Camera.app and that no image-modification takes place), it’s very like a simplified version of the DSLR, the only difference being that there’s no RAW option:

Where things change is with the more interesting apps that actually do something with the image. With most (if not all) of them, this is what happens:

So there are two stages of JPEG compression caused by the app developers starting with image data that has already been compressed by Apple as part of its default “development process”. For the majority of leisure photographers, again, this is not that important—even two stages of compression don’t change an image that much. But, again, for those seeking maximum image fidelity it’s an issue. Were such apps to save a TIFF file in addition to the JPEG (as 645 PRO does), its contents would have still have been through one stage of JPEG compression (and that’s also true of apps that provide a “save Original” JPEG option). Like this:

But 645 PRO takes a different approach. It gets its image data at an earlier phase of Apple’s “development process”, before any JPEG compression has been applied. This means its final JPEG files have only been compressed once (and, if you select the MAX-quality JPEG option, minimally, with no visible artefacts), and also that we can save a second copy of the image data, before any processing has been applied, as a TIFF. We’re calling this a “developed RAW”—dRAW—TIFF because it contains the image data in a state equivalent to that of a “developed” Camera RAW file and because, this being so unusual in the context of iPhone, that it hasn’t been through any JPEG compression (no one would assume that it had in the context of a DSLR; everyone who knew anything about iPhone camera application development would assume that it had in the context of iPhone) . So this is 645 PRO’s approach:

It’s completely new (as far as we know) and, for some iPhone photographers it’s really important. And we wanted a punchy way to describe it to make that clear. We found something that seemed appropriate. And we were wrong. We listened to the feedback, we discussed the matter in depth with a number of leading industry figures and we came to the conclusion that referring instead to a ”developed RAW”—dRAW—TIFF made sense in this very specific context.

[edit: this was written in April 2012; it is important to note that, several months later, many more apps are now grabbing their data before the initial JPEG compression—which is great for photographers—although, still, very few offer to option to save unmodified TIFFs.]

All the 645 PRO marketing materials are being updated with the updated terminology. 645 PRO is currently in the App Store approvals process, and we don’t want to interfere with that, but we will rush-release Release 1.1 with the modified LCD tell-tale and an updated User Manual as soon as we are able.

Mike Hardaker
Founder, Jag.gr

* Not all digital cameras have Beyer sensors; this is describing typical rather than universal Camera RAW scenarios.

Comments

  1. This is a welcome change, in fact RAW to me (and to many others) is a name for a file that has been captured before the bayer interpolation.
    I’m looking forward for your app in the store and thank you for this useful post.

  2. Brandon Lee says:

    Congratulations on finding a nice way to explain and manage this issue (even more clearly than before — the fact that even your filtered JPEGs can be totally lossless was buried before) before the launch.

  3. Keith says:

    Awesome explanation, thanks for taking the time!! The graphics were a great addition to the explanation. I can not wait for the app!

  4. Roger Hein says:

    Nicely explained. Hopefully, in use, saving files in both formats won’t be a strain on the iPhones resources with a long lag between shots.

    • Mike says:

      The total save time is longer (predictably), but you do get control of the camera back in the same time as with JPEG-only saving. The practical difference is simply that the save buffer takes longer to clear, so you can’t take as many shots in a short period of time if it gets to the stage of being filled up. The time differences are more dramatic—again, predictably—on iPhone 4 than iPhone 4S.

  5. Think you made the right decision. Also think your app sounds pretty great. I’ll be an early adopter!

  6. Happy says:

    What kind of app workflow compresses two times? Apps that do realtime filter?

    • Mike says:

      Pretty much any app that makes any modification to the image of whatever nature (and quite a few that don’t, I suspect, simply because programmers often follow the “standard” way of doing things without thinking about the ramifications). The orthodox way of using the Apple still camera APIs means the developer starts off with a compressed JPEG; doing it differently, while possible, is remarkably non-obvious. And if you start with a compressed JPEG, alter it, and then save it as a compressed JPEG it will be re-compressed. To repeat, however: most people won’t notice (or care), but for those who do…

      In passing, it’s worth remembering that passing such a JPEG through multiple iPhone editing apps will only compound this as each app saves the file as a compressed JPEG. Again, for most people it’s not a big deal, but we’re able to offer an option for those who do see it as such.

      • Happy says:

        Thanks for the reply! Really appreciate it :-) So–correct me if I’m wrong–basically:
        1. All editing apps recompress JPEG after saving.
        2. 645 aims to give the least compressed possible photos to begin editing with.
        3. If users edit, say, the dRAW photo multiple times, theoretically the quality is higher–regardless whether it’s clear to the naked eye–than if a user edit a standard JPEG compressed photo the same number of multiple times.

        By the way, by using Apple still camera APIs, does that mean using the same UI and not having separate focus and exposure and other stuffs the Camera app doesn’t have? Does the same thing eg interpolation, compression etc. apply to video camera too?

        • Mike says:

          1. If a JPEG is modified and then saved then it will be recompressed. So all editing apps that take a JPEG and modify it before saving it (or a copy) as JPEG perform that decompression. I can’t say that it’s true of all editing apps because I haven’t tried them all.
          2. Yes.
          3. If users edit the dRAW TIFF and then modify/save it repeatedly in a non-lossy format (such as back on to itself, as an LZW-compressed TIFF) then the image data isn’t changed in the saving process. So the *fidelity* is higher. The *quality* really depends on the modifications that are made…

          No, the UI is very different, and includes (lockable) independent focus and exposure points. See http://jag.gr/645/ for a summary. The way we save files (and the terminology we use) is just one factor that makes 645 PRO different—and one that, for many people, will actually be the least important!

          And yes, video gets compressed too (and it does on pretty much anything shy of “stupidly expensive”). It’s different, but conceptually similar.

          • Happy says:

            Thanks again! I won’t say I completely understand all these but asking wasn’t harmful, right? ;-) Can’t wait to see what you’ll do to video recording if you ever decide to.

            I actually prefer using slider to zoom than pinch but it seems that would clutter 645′s UI. Are there developers who use Lanczos?

            Oh, I think you forgot to change the one small +RAW pic to +TIFF.

  7. Dennis Bond says:

    I agree that you have made the right decision. I enjoy using 6X6 and 6X7 and look forward to the new app!

  8. Adam Fields says:

    This is a massive improvement over the previous choice of terminology. I’m glad you fixed it.

  9. manu says:

    Hello, that sounds interesting. Is the draw/tiff file in 16 or 8 bit ?

  10. manu says:

    Thanks for your quick answer. 8bit means there’s not much room for improving dynamic range, I guess…