Skip to main content
Known Participant
February 24, 2013
Question

Why embed color profiles?

  • February 24, 2013
  • 1 reply
  • 27179 views

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

This topic has been closed for replies.

1 reply

TheDigitalDog
Inspiring
February 24, 2013

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)?

Author “Color Management for Photographers" & "Photoshop CC Color Management/pluralsight"
IdamIndiaAuthor
Known Participant
February 24, 2013

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)?

IdamIndiaAuthor
Known Participant
February 26, 2013

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.


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.