Why embed color profiles?

[IdamIndia]

I understand color profiles as translators of the image data for the device to show as it shoudl appear (to me, the human eye)

Why not apply this translation as a conversion (profile tells how the color values shoudl appear, right?) and done with it. Then the monitor should use it's profile to show the file correctly.

The whole idea of "working space" or choosing/applying a profile to an image seems only to apply this translation (the profile).

Why ask? Or why even have an image + profile, when one can simply do image x profile = a single profiled origianl image? In RAW conversion is this not what we are doing? And if so, why have the profile name attached to the file, when it is already converted?

Or did I got it all wrong? When I think I get it, soon I start to see - may be I am not getting it

[TheDigitalDog]

The profiles are the key's to showng you the colors 'correctly' but the display is a very device dependant color space! Working space are not (they are Quasi-Device Independent). Since Photoshop 5, the display color space is divorced from the editing of the images which are in this Quasi-Device Independent RGB working space. None of the idiosyncrasies of the display color space is therefor applied to the data we edit our images in.

In raw processing, there is first an assumed color space of the captured data which is essentially Grayscale data. Pretty much only the camera manufacturers have a really good idea of the native color space (based on the sensor, the color's used on the filters etc). Once a converter makes such an assumption, there is usually an internal raw processing color space such as linear ProPhoto primaries in Adobe raw conveters after which one can ask for any output color space the converter supports (four in ACR, any number of RGB color spaces in Lightroom). Again, the numbers have a numeric value and an associated color space that along with the display profile produce a 'correct' preview.

The display has it's own unique color space and hence ICC profile to define it, the data in an RGB working space have a different and independent color space with again, an ICC profile to define that data. That's one reason why the display color space is divorced from the editng space. One can have a vastily larger and differently shaped color space that defines the data from the color space of the display (why clip the editing color space to something even close to Adobe RGB (1998) let alone sRGB)?

[IdamIndia]

At the very start, when image is taken and a profile (capturing device dependent) is applied or assumed. The profile is attached or embedded. My question is just for this very step, not when the display profile is used to interpret for display characteristics/profile. Why is the original file not a "converted" file?

I am yet to grasp the point of working space vs display space. It makes sense, but I don't completely get it - is the display profile not related to working space? Working space is after all about the actual value of the pixels in file, while display is how it is rendered. While working, editing, I am actually seeing the display to make the edits.

The clipping point you make at the end gives some clue, I understand it as clipping that I can't really see in the image (as full black or full white) in lightroom or pshop, but when I enable show-clipping I notice it. So that clipping shown is based on the working space data not the display. The display may be showing even larger area in all black or all white. I mention this to confirm if I understand the concepts correctly.

If the original is converted, as per my original query, I can imagine the need for the key for display and print and therefore the need for a profile. The moment the display or print conditions change, those output profiles need to change. But why not rely on the original image as is (convert based on it capture device profile - since that is not going to change)?

[TheDigitalDog]

IdamIndia wrote:

At the very start, when image is taken and a profile (capturing device dependent) is applied or assumed. The profile is attached or embedded. My question is jsut for this very step, not when the display profile is used to interpret for display characteristics/profile.

Because that data isn't anything like nor should be described by a display profile. Unless the data IS from an actual display. The data is what it is, a set of numbers that need a scale (which is what the profile does for THAT data). The display is what it is and needs a profile to define that device. One profile by itself is like one hand clapping. You can define that device's numbers with one profile but you can't display it. You need another profile for that.

If you speak German and I don't, we can't communicate. If you speak German and I speak English, we still have an issue. If you speak German, I speak English and your friend speaks both, we have a translator and can converse. The original data is German. The Display is English. The profiles and as importantly, the profile connection space (your friend) allows your color space and my color space to produce an understood conversation.

[Guest]

Very well put, Andrew.  One way to understand this entire profile or no profile is just imagining what would happen without them.  Somewhat a crap shoot.  The thing about your monitor's profile is it is OS based information which is used to "display" color somewhat accurately.  It ends there.  Original image profile has to be disciplined.  Without some control, your image file is subject to color casts, gamut clipping, and densities outside reality.  If the capture is not controlled, you easily get images that are either under gamut or outside of gamut suitable for whatever your image's use is.  Andrew's communication situation is perfect in trying to understand the entire color management process.

[IdamIndia]

Let me change the title of the discussion:

Why embed profiles, when there exists LAB (near real world values), why not just use LAB?

and devices use profiles to convert LAB values in the file to their device capability. File remains pure LAB always. But we use RGB or CMYK as a given way to work.

[TheDigitalDog]

IdamIndia wrote:

Let me change the title of the discussion:

Why embed profiles, when there exists LAB (near real world values), why not just use LAB?

and devices use profiles to convert LAB values in the file to their device capability. File remains pure LAB always. But we use RGB or CMYK as a given way to work.

Lab isn't a native color space. No capture or output devices produce Lab. So at some point, we've got RGB data (from scanners and cameras). You want Lab, you still need a defined color space for RGB just to get to Lab. Might as well stay in RGB as there are numerous issues with Lab although the fact it's self defining (until you ask about white point) is nice.

[IdamIndia]

As this topic (color management) makes me to research and learn continuously, I am curious to understand more about your comment on LAB: "...numerous issues with Lab although the fact it's self defining (until you ask about white point)" What about the white point in LAB? I don't know if that should be another discussion.

In the meantime I got my answers, and a book called "Color Confidence" seems to clarify it well. In fact it has a reddish text box just for the precise question "Why not Lab?" ("why embed profile" is implied in the context). What pinned it well was the statement "Of course, provided a profile is embedded in an image file, the RGB and CMYK values are, in a way, stored as LAB..."

The text can be found in Google books preview: http://books.google.co.in/books?id=XprFp9u4lcAC&q=why+not+lab

what appeals to me now, is this:

• The intention is to give real world colors and consistently accross devices (with different color spaces)
• To achieve it, it is done through profiles
• Original digital image (RGB or CMYK) are easier to edit as RGB or CMYK (user friendly to move those sliders of R G and B) than LAB sliders (are there sliders in LAB? I have not explored)
• Though one could have untagged files, adding a profile tries to dictate some consistency to them for further use/editing. If that was not fixed for the digital image, it will be free for each app to use any color profile and make colors look different each time. I am not even talking of display and print profile here, assume they were all set.

My botheration has only been the first step of digital image. Not display and print profiles, that is, why is the original digital not converted to LAB? Now it becomes clear.

[TheDigitalDog]

IdamIndia wrote:

My botheration has only been the first step of digital image. Not display and print profiles, that is, why is the original digital not converted to LAB? Now it becomes clear.

Again, you can't convert to Lab until you have a profile that defines RGB or CMYK.

Lab is a huge color space, encoding requires high bit data.

Keep in mind that CIELab was just an attempt to create a perceptually uniform color space where equal steps correlated to equal color closeness based on the perception of a viewer. The CIE didn't claim it was prefect (cause its not). Most color scientists will point out that Lab exaggerates the distance in yellows and consequently underestimate the distances in blues. Lab assumes that hue and chroma can be treated separately. There's an issue where hue lines bend with increase in saturation perceived by viewers as an increase in both saturation and a change in hue when that's really not supposed to be happening. Further, according to Karl Lang, there is a bug in the definition of the Lab color space. If you are dealing with a very saturated blue that's outside the gamut of say a printer, when one uses a perceptual rendering intent, the CMM preserves the hue angle and reduces the saturation in an attempt to make a less saturated blue within this gamut. The result is mathematically the same hue as the original, but the results end up appearing purple to the viewer. This is unfortunately accentuated with blues, causing a shift towards magenta. Keep in mind that the Lab color model was invented way back in 1976, long before anyone had thoughts about digital color management.

[IdamIndia]

Thanks Andrew Rodney, your detailed answer helps me to conclude as such, for my use:

- Original data is sacred (original captured image)

- Profile is necessary due to device character and editing issues (what I see I will not get!)

- There is NO absolute color space definition (not even LAB though I started with that assumption)

- Color profile working space and policies must be set in Color settings

- Avoid converting to a profile (unless creating a copy) | "Intent" further complicates it

- Always embed a profile - the essential of color mangement workflow

It is the first and third that mainly solve the whole discussion for me.

[info645]

Thanks for the info. This is exactly what I was looking for.
Thanks,
Jonathan Anderson
Cristia Medical Supply, Inc.

[IdamIndia]

This is what I like about the forum. Valuable Knowledge stays there for reference. And this post in particular has given more to me when I returned to read the detailed answers again. That time I was so concerned only about embedded profiles, but as I learned more I had to return to see those other (additional) things that were said here. Thanks to Andrew Rodney for sharing things so well.