On Sep 3, 2004, at 2:02 AM, Rob Studdert wrote:
Using the PS CS import utility the option exist to select one of four CS profiles in my system. The available profiles are Adobe RGB (1998), ColorMatch RGB, ProPhoto RGB and sRGB IEC61966-1, in this line up I assume ProPhoto has the widest Gamut.
I haven't looked at ColorMatch RGB but ProPhoto RGB is by far the largest colour space I've ever seen. Adobe 1998 is a little bigger than sRGB, mainly in the green channel (which includes cyan). Adobe's is optimised for the publishing industry, and sRGB was created to represent the phosphors of most computer monitors (I won't go into the reasons why).
Now for a little side-tracking (I'll return to your comments later).
Basically you can define a device-independent colour space to be as big as you want but the bigger the working space is, the larger the colour difference between two adjacent values will be (eg 127 to 128). This is because the volume enclosed by the smaller working space is now represented by a smaller bit depth, within the larger working space. I hope this makes sense - I'll try a simplified visual approach as I find it easier to understand this way:
Draw a 10cm line and mark the halfway point. The length of the line represents the gamut of our hypothetical colour space, and the point represents a colour within that space which is 50% of the maximum saturation that our colour space is capable of representing. Let's say that we can measure position in 10 increments (1 per centimetre). This represents our bit depth, and as such the amount of increments is fixed regardless of the length of the line. (Those in the US can use inches instead of centimetres if they prefer.)
Now extend the line in one direction until it's twice as long (20cm). This is equivalent to converting our image to a colour space that is twice as large. Our original halfway point is now at the 1/4 mark. Note that it hasn't actually moved. Visually our colour is unchanged, but our new colour space can represent colours that are twice as saturated as our previous colour space could represent.
However, our "bit depth" is fixed to 10 increments regardless of how long the line is. Our increments have changed from 1cm to 2cm in size! So how do we represent the position of our point which is 5cm from "zero"? We have two options: either introduce a quantisation error by rounding it to either the 4cm or 6cm points, or increase our bit depth to improve accuracy. Colour management is all about preserving colour so from that perspective it is best to use a very large bit depth.
Increasing bit depth requires more memory and disk space to store, and more CPU to process. This all costs money so we don't want to do this unless it's really necessary, so for best results it's important to choose a working space that is big enough but not too big :)
Note that most colour information in a photograph will easily fit inside sRGB (particularly skin tones), so chopping down the amount of bits that represent this data, by representing this data in a bigger colour space, can have serious implications if you're using 8 bits per channel. And it's a lossy process. Once the RGB numbers have been re-quantised to smaller numbers within a larger colour space, they can't be recovered. I have exaggerated my example above but really an 8 bit file is pushing our luck for tonality.
The result of the quantisation error is an effect known as posterisation, where gentle tones can be rendered as distinct bands of colour. You can simulate this by opening a 24-bit-per-pixel file and switching your display settings to 16 bits per pixel (65k colours) or lower. It's most obvious with gentle tones, such as a landscape with lots of sky or a softly-lit portrait. It can also result in a "splotchy" or "grainy" appearance.
So to preserve tonality for the less saturated colours in a large working space, you need to increase bit depth. For that reason you should only use large working spaces if your source data (or destination, after processing) actually contains colours that can't be represented by the smaller spaces. You can buy peace-of-mind by always working in 16 bits per channel, if your PC has enough memory.
In reality, there is little difference between sRGB and Adobe RGB. IMO 8 bits per channel is fine in either of these spaces. Anything bigger than Adobe RGB (eg EktaSpace or Pro Photo RGB) I would strongly recommend storing at 16 bits per channel.
It gets a lot more complicated when you consider that a colour space is really three-dimensional, and that not all combinations of R/G/B numbers are guaranteed to fit within the gamut (you may have noticed Photoshop's gamut warning icon appear in the colour picker).
Looking at the histogram in the PS CS import utility there is information lost
when switching between Adobe RGB and ProPhoto RGB profiles.
Hopefully what I wrote above will help explain this. I don't think the histogram is an accurate tool for showing what's really going on, but it does show you that there are differences in the R/G/B values due to the conversion. A histogram of saturation values would be useful, rather than luminance values. I'm wishing for a plot that shows where the image colours lie within the gamut of the colour space - you can buy software that does this but it would be nice to have it built into Photoshop or ColorSync Utility (anyone from Adobe or Apple reading this?).
Assuming files are to be archived in a 16bit per colour format I assume that losses when
converting to lower gamut profiles would not be so destructive?
That would be correct for 16 bits per _channel_ (not per colour:). For the sake of doubling the filesize there are multitudes of advantages in doing pretty much all image adjustments in 16-bit mode, even if the original and/or final file is 8-bit. If you can afford the storage space, definitely archive in 16-bit.
Of course, converting to a smaller working space is risky as it's difficult for the system to know how to handle colours that are present in your file that are outside the gamut of the destination working space. The chosen rendering intent makes a difference here. It also makes a difference going the other way but this is more subtle (it has more to do with the quantisation errors). For photos it is best to use either Perceptual or Relative Colorimetric.
When printing it gets really messy as printer gamuts can be all over the place. Inkjets are really CMYK devices so their gamuts don't match up with RGB colour spaces. Soft proofing is very good but it does rely on having a well calibrated a profiled monitor, and accurate printer profile for your ink and paper combination.
I would expect this to be a better archive solution than Adobe RGB?
If your source file really does contain colours outside of Adobe RGB, then the answer is yes. Part of the point of archiving this way is that if printing or display technology suddenly leaps into a whole new level of capability, you can take advantage of that improvement with your existing media. It's not so bad with film as slides & negs can be re-scanned into a new colour space, but with digital capture it's a different story.
So your choice of working space is largely determined by your input device, together with any subsequent processing you might perform prior to storage.
For archival purposes I was using EktaSpace for a while - this space was designed to represent the colours that Ektachrome slide film is capable of holding. However I think that my scanner is the limiting factor in that workflow, and I may do some more experimentation when I upgrade my scanner (I'd be re-scanning my slides anyway).
For the record I am currently using Adobe RGB.
Thanks for the great info. Have you still got that page up which contains the
test images rendered in various colour spaces?
http://www.digistar.com/~dmann/temp/profile_test/
That page only exists to test whether your web browser is colour managed. I need to update the yes/no list as I've had some more feedback (no more "yes" entries, unfortunately). It seems that only Mac browsers support it as they tie into ColorSync at the system level.
Something that may be more useful is this comparative plot of sRGB vs Adobe RGB 1998. The colours shown are only a guide and do not represent real colour values - they just show you which direction is blue, which is green, etc. I've also done plots of bigger spaces but I think this is the only one I uploaded. The greyed out one is Adobe RGB and the coloured one is sRGB.
http://www.digistar.com/~dmann/temp/srgb_adobe1998.jpg
Please note that it is a 2D projection of a 3D plot. That shot is looking almost vertically down toward the top (white point), so the entire bottom half (dark colours, heading toward the black point) is not visible. This was using ColorSync Utility which comes as part of Mac OS X.
A while ago I made a whole heap of plots comparing Adobe RGB against Epson 2100 profiles, but I haven't put them online. A friend's daughter is (or was, at the time) a fine art student and she had taken some digital photos of an artwork she'd done. Unfortunately they contained some extremely saturated reds that his printer just couldn't cope with, so I did the plots to help him explain to her why the printer couldn't reproduce what she saw on the screen.
Cheers,
- Dave (one of these days I want to write a web-based guide that's both informative and understandable).
http://www.digistar.com/~dmann/
