Aperture 2 working color space

I've been studying raw converters, color spaces, and the proper selection of working spaces recently. I've gathered three dominant opinions on working color space: (1) choose a really big one and always work in 16 bit, (2) choose one that is large enough for your output device and no larger, and (3) choose one optimized for the colors contained in your image. These three approaches trade off color safety for quantization losses. There are people who do none of the above, but they are optimizing for things other than image quality.

The problem with (2) is that it assumes you will always know what your output device is. Advocates of this approach seem very connected to the printing side of photography. There apparently have little appreciation for "the future".

The problem with approach (3) is that it doesn't lend itself to an automated workflow. It requires careful choices for each and every image. If you want an example of how far this can be taken, go look here. I have to admire anyone who takes this approach, but it does seem to me to be more worthwhile when all you have is 8 bit.

That leaves (1). Advocates of this approach typically say choose ProPhoto and be done with it. Others advocate better large spaces like DCam 4 or BetaRGB but the idea is the same. Make sure your gamut is large enough to fit and then use enough bits to ensure your data is preserved.

Both Lightroom and Aperture are implemented with the large space mentality. Both packages hide the internal working space from the user, but in the case of Lightroom it is well known. Lightroom uses a variant of ProPhoto for its internal processing. Computations are gamma 1.0 and displayed values are gamma adjusted and shown as percentages. Apple is more secretive about theirs, though. All they say is that they use a large internal working space and you are supposed to trust them.

I imported a variety of tagged and untagged images to Aperture to verify that color space conversions were being performed properly, then I used tagged ColorChecker reference files to verify that Apple uses its own internal working space for all images (not just raw ones). I also verified that Aperture's RGB data provided in the loupe is independent of proofing setting. It is, so I set out to determine what the working space is based on the ColorChecker numbers Apple provides through the loupe.

I recorded the RGB values for each of the 24 patches according to the Aperture loupe, created a synthetic, unmanaged ColorChecker chart using those values in Photoshop, then profiled the result. The profile I produced was remarkably similar to AdobeRGB.

Going online, I came across this thread: http://lists.apple.com/archives/Colorsync-...l/msg00520.html

Andrew Rodney says or at least said at the time, that he believed Aperture uses some form of AdobeRGB for its internal working space. That appears to me to be true.

Of course, these are only displayed loupe numbers that Aperture provides and they could convert those to AdobeRGB if they wanted to. Why would they?

The point of all this is that AdobeRGB isn't a particularly large color space and I have underwater images that won't fit in it.

How many of you that understand and believe in the virtues of ProPhoto are using Aperture? Have any of you looked to see if you ever got a color out of Aperture that was outside the AdobeRGB gamut?

Before I go looking at this in detail. I would like to understand something. What is the broadest color gamut that our cameras are capable of, and if this is camera specific, is there are reference somewhere for what the specific camera gamut is?

I assume that you are speaking of the output gamut of Lightroom and Aperture, or are the RAW images sitting in Aperture somehow limited as well?

As an aside, the photo I posted of the manta and sunball, was originally imported into Aperture.

Our cameras are capable of a very large gamut. Some people claim BetaRGB is large enough to contain all cameras, others say it is even bigger. You can view camera profiles in the various viewers and that gives you some idea.

Luminous Landscape offered this article on the subject. Ordinarily I hate referring to LL but it is one of only a few online pages that discusses the matter at all. Iliah Borg suggests the article is in error and device profiles are smaller (but not much). As you can see, though, it is clear that AdobeRGB is way too small to contain the capabilities of our cameras yet that appears to be what Aperture uses.

What I'm speaking of is the working space that the software uses internally. Some packages, like Photoshop, let you specify that while others do not. Aperture keeps that information a secret.

A raw converter really only does two tasks, it performs the demosaicing operation to produce a full color image and it encodes device-specific data into some standardized color space. All our software packages do FAR more than that, but the raw conversion itself boils down to just that. That very first color space is important because if it is too limiting then you are losing color information right up front. Some programmers argue that if that color space is too broad then conversion quality suffers. What I find fascinating is that all this hinges on the fact that these spaces are integer encoded and only (typically) use 8 or 16 bits. Apparently it doesn't occur to these programmers to use fixed point or floating point arithmetic instead. I say that because RPP does use floating point and the authors (Iliah Borg is one) insist that integer truncation is one of the biggest contributors to image quality problems among their competitors. As a programmer myself, I find this a bit hard to believe but the incompetence of programmers doesn't really surprise me anymore.

OK; this is weekend work. Cant' get too distracted on a weekday.

OK; this is weekend work. Cant' get too distracted on a weekday.

Who you kidding, of course you can. Please let us know what you find

I just did a bit of poking around through my "Aperture Library.aplibrary" folder and found that all the thumbnails and previews are tagged as Adobe RGB. This includes all my scanned slides, which have custom scanner profiles embedded in them. It seems to confirm that Aperture is using Adobe RGB internally.

As I understand it, when you export the file you can specify any color space that you desire and Aperture will go back to the raw file and re-perform the conversion, so colors should not be clipped. However, it seems to me that performing all my editing in a smaller color space and then exporting into a larger color space could give unexpected results.

For now, I don't see this as being a problem for me as my monitor isn't capable of displaying the full Adobe RGB spectrum (nor does my printer), but it does raise questions to the "future proofness" of Aperture. I guess it wouldn't be hard for apple to change aperture to use a larger color space internally, but it does raise questions about there logic.

Cheers,

Mike

Yes, I've heard one person say the same. It would be easy to check but I haven't tried.

The common criticism of large spaces is you're editing "blind". The claim is that your monitor can't show it so you can't judge it. I have a big problem with that argument because it makes those that offer it hypocrites. They advocate smaller spaces yet still larger than what they can see on their monitors.

The one defense is that you can edit "by numbers" in large spaces and some actually claim to do that. Trouble is, even if Aperture works right with large spaces, it's "numbers" implementation prevents editing by the numbers except in the AdobeRGB-like space they use internally. There's also a question of what happens on TIFF imports and on images that have used plugins. Those images can't go back to raw. It makes no sense to me to use a small working space, then export to a large one by attempting to undo the potential clipping by re-referencing the source.

I don't know about Aperture but the camera profiles given by Capture One have working spaces bigger than Adobe 1998.

It's easy to check in ColorSync Utility in Mac OS X.

Anyone notice Eric's latest sunball post? Aperture didn't look too good in that conversion. Cyans around the sunball were seriously posterized. I'd like to know if it's related to working space.

Anyone notice Eric's latest sunball post? Aperture didn't look too good in that conversion. Cyans around the sunball were seriously posterized. I'd like to know if it's related to working space.

It could also be related to an out of gamut issue and the working space.

I just did a little test. I took a random RAW image off a card and created 3 different versions. A TIFF exported from Aperture using Aperture as the initial RAW convertor, , a TIFF imported into Aperture after using NX2 as the RAW convertor and then reexported as a TIFF, and TIFF directly out of Capture NX2 using NX2 as the RAW convertor.

Plotted in Color Think, they are all different. The Aperture RAW gamut appears more compressed than the NX2 RAW gamut, and what is more disturbing is that the TIFF imported to Aperture then reexported appears to be more compressed than the other two. This would seem to indicate that an image stored as a TIFF in Aperture is modified from import to reexport. Not sure I understand what's happening exactly, but it bothers me nevertheless that this process is not benign. I would be interested to see if Lightroom does a similar thing.

If you provide me the raw file and the NX2 generated TIFF (plus the output color space) I can return the Lightroom result images to you.

What's the best way to send you a 15MB file?

do you have a photo site? ftp site? you can try email but that may be too big. It may take a bit for me to arrange a ftp location.

I tried a similar experiment. I'm not an NX2 user but have an eval copy installed. I found a way to do a color space assignment or conversion, but I couldn't figure out how to tell NX2 to export using the space of my choosing. I chose to accept the default which was Nikon AdobeRGB. My source image is a ColorChecker chart that's uncropped. No colors should be out of range.

I set my white points, contrast flat, and then my grayscale range and exported in Lightroom and NX2. Here are the graphs:

Lightroom 2, ACR 4.4 profile, not calibrated!!!

NX2

NX2 imported to Lightroom, then exported

Lightroom and NX2 create different default conversions as expected. Lightroom does not appreciably alter the NX2 image through import/export.

LR and NX2 conversions overlaid

NX2 conversion with the import/export version overlaid

Basically, all this works as expected.

I'll get Craig my RAW file so he can augment the test on his side.

All conversions were done straight, with no attempt to "reign in" the sunball. That is a different exercise.

Also, I often use http://yousendit.com to send files. Piece of cake. If you are paranoid, you can pay for secure delivery, or you can encrypt the file before you send it.

Eric,

I suspect what is going on in Aperture with the sunballs and maybe to a lesser degree in Lightroom is gamut compression compared to Nikon / Canon convertors. I have had problems with out of gamut cyan areas of sunballs, and I suspect these cyans are 'close to the edge' of the gamut, resulting in early compression with any type of gamut restriction and hence posterization. I have to run some more tests with Aperture. Maybe presets have to be turned off or something when importing / storing TIFFS in Aperture.

To paraphrase Col. Hannibal ' I hate it when a plan falls apart'