Technical Perspectives on Digital Photography

Several months ago, I was in the process of adding better color management for an open source rendering and simulation package. One of the things that many schools don't teach in their rendering courses is proper color management (along with proper gamma correction). Most people when writing their first ray tracer (in school or elsewhere) usually represent their colors as RGB without giving too much thought to which specific RGB color space (or even if the color space they are using is linear or non-linear). Generally, you want to do your intermediate rendering color computations in a wide gamut linear color space (I suppose you could do it in a different colorspace such as CIE XYZ or CIE LAB, but I wouldn't recommend doing things like BRDF calculations in such color spaces (however if you are doing spectral integration, you want to integrate to CIE XYZ, then convert to your internal RGB color space)) in high precision (preferably floating point for higher dynamic range). Naturally these things are a tradeoff against space and speed. Personally I'd rather be correct and accurate rather than fast, but YMMV.

So upon deciding that I should change the internal rendering color space to ProPhoto RGB I set off to find out as much as I could about ProPhoto RGB. After several online searches I came up with a few descriptions of the color space such as the one by Michael Reichmann, the one on Nature Photographers online magazine and its Wikipedia entry. Sadly, after hours of searching I couldn't find any technical details on the color space such as its white point, chromaticities or its nonlinear transfer function. I did manage to discover that it was first introduced and proposed by Eastman Kodak, and so went off and did another round of searches with 'ProPhoto RGB' and 'Kodak'. Again, not much luck. I finally gave up and asked a colleague what gives. It turns out ProPhoto RGB is the same as ROMM RGB. ROMM RGB was developed by Eastman Kodak, however I believe the name ProPhotoRGB is used because of the friendliness of the name (I guess ROMM RGB just doesn't have the same "pro" ring to it).

Now searching for ROMM RGB, led to easy and quick success. I was able to easily find the original white paper along with the specifications I needed.

Also, if you open up Photoshop you will notice that you can assign and convert to both 'ProPhoto RGB' and 'ROMM-RGB'. Though they are named differently, they are in essence the same.

Posted by Aravind Krishnaswamy at 10:12 AM | Permalink | Comments (1) | TrackBacks (0)

One of the things shadow/highlight adjustments are useful for is to correct for underexposure in a part of a picture. However this feature seems to get overused (and hence abused) a lot; which results in (what I consider) to be nasty halo artefacts.

Here is an exampe for the kind of picture you may want to jazz up using shadow/highlight:

Now if you run shadow/highlight on this image and realizing you want your sky to be a little darker, get a little too liberal with the highlight processing, you end up with something like this:

The halo-ing at the horizon to me tooks displeasing. However these kinds of images seem to pop up everywhere; especially with people playing around with HDR. Now I wouldn't presume to dictate what is and isn't art, hence I will concede that this type of shadow/highlight 'abuse' could be used to render an image with specific artistic intent.

If you did want to brighten up the shadow region in this image, by being a bit more judicious in the application of highlight processing, we can avoid some of the halo-ing artefact:

Incidentally, the correct answer in such a situation would be to take series of exposures and merge to HDR. Once you have an HDR image, you'll want to convert back to LDR using the appropriate exposure and gamma values that gets you the desired detail in both shadow and highlight regions. However be wary as some HDR->LDR tonemapping algorithms can introduce similar artefacting.

Posted by Aravind Krishnaswamy at 03:24 PM | Permalink | Comments (3)