In the {Canon} EOS {350D} manual there is a comment next to the colour space menu option description that states:
“This setting is not recommended if you do not know about image processing, Adobe RGB, and Design rule for Camera File System 2.0 (Exif 2.21)”
To which I had always replied (mentally) “Of course I do”. Ahem. I need to modify that statement to read “Of course I do, under {OS X}” as it turns out I hadn’t quite done all the config I thought I had.
I shoot 99.7% of my images in {RAW} and {Adobe RGB} colour space as I hate to think that I might miss something at the time that could be corrected losslessly later, which means that I have zero settings for colour, sharpening and saturation too (Parameter set 2). The first step in Canon’s {DPP} is then to dial the saturation one stop back up to the mid point (from -1 to 0) and give it some mild sharpening (from 0 to 4) before moving on to cropping. After that, I export as either a TIFF or JPEG and use Photoshop Elements 3 and its “Save for Web” feature to get smaller images for use on-line and via email because it does a great job of keeping me informed about the final file size, as well as letting me preview how many artefacts I’m introducing.
Because I have {DPP} set to use {Adobe RGB} internally and PSE3 has had the “Full Colour Management” option set, I had assumed that the JPEG’s I was producing for the web were in {sRGB} space, as that’s what’s expected, and looking at the output from PSE3 against the original always appeared to confirm that everything was as it should be. Except it wasn’t, as I discovered after I uploaded an image or 7 to print via PhotoBox and looked at the preview: the image was flat, skin tones muted and a little greenish, and red bokeh was lacking in any sort of lustre. Digging a little deeper it appears that PSE3 never converts colour spaces (it can be bullied via cut-n-paste as long as the source and destination files already have the desired space set) although {PSE4} is supposed to – I can’t verify that as there is no {OS X} trial version on {Adobe}’s site at present. Canon’s {DPP} will embed the ICC profile within the image on demand, but again, does not translate after the initial opening of the image.
All of my test previews and prints at home were done via {OS X}, and there the image appeared to be correct: this was due to the fact that although the JPEG files were marked as {Adobe RGB} (uncommon though that might be) the image previews and prints all read the profile correctly, and translated everything for me. PhotoBox, however, takes the perfectly reasonable view that most JPEG’s are {sRGB} and rather than try to read custom profiles that might not be embedded correctly they ignore that data and render them directly as {sRGB} all the time, hence the subtle colour shifts.
The answer was relatively simple: there is an {Automator} action within {OS X} that will convert colour spaces for you, and it works 100% as advertised, as does the convert to JPEG action. The hard part was making the file extension change from whatever the source was to .jpg which I have done with an action from Complete Digital Photography, although some {AppleScript} in the workflow would work just as well. Note that this action will consume the files it is given, so export copies of the images you wish to convert, select those copies, and then right click to run the “Convert to sRGB” action. The file can be in any source type that the system understands, as well as any colour space that it knows how to render correctly – it’s all taken care of for you !