Applying ICC profile at different stages, does it matter?

[TarekAH]

sorry for my late reply, but work sometime is time consuming

Welcome back, Tarek.

As I understand it, an ICC profile does not have a specific color gamut as such. By which I mean that it can not be said to be PhotoPro, for example. I don't think you are, but are you referring to the Profile Connection Space?



The statement is too sweeping and is a bit vague.

The ICC profile converts the image color data firstly to XYZ or L*a*b* - usually by a 3x3 matrix.

well...you said it "The ICC profile converts the image color data firstly to XYZ or L*a*b*", so from where and to where?

so basically to my understanding and according to the resources (that I am trying to collect for now), when creating an ICC profile you are encoding your photo's colors in one of your chosen color spaces that is preferably must be wide enough (e.g. ProPhoto). Then there is a transformation happening when you want to print/display your photo and this transformation is carried out in one of the PCS (Profile Connection Space) e.g. CIELAB, CIEXYZ. hence the shrinkage or some loss/inaccuracies during this process of remapping colors (the inaccuracies severity depend of course on how your workflow handle that, clearest example here is moving from display RGB to printer CMYK).

Remember that raw data has no gamut and some values can be well outside of the CIE xyY triangle.

well quite much, I mean there is no possibility of displaying raw data/numbers after all - it will be just a mess of gray intensities- hence you need to define them inside some boundaries where Red, Green and Blue have pre-defined values --> again that is why you process/any raw engine or studio studio processes your raw data usually in a wide gamut color space (e.g. ProPhoto) which has ,as you mentioned, some (quite much) values outside the defined xyY triangle and even outside the boundaries of the defined visible colors!!

Of course the mapping is from the ICC PCS (say XYZ) to the monitor's color space (say sRGB) but that itself does not cause "too much cut-off's and missing information". Therefore your statement 3 is incorrect.

sorry but I am not quite sure based on what you are claiming that converting from ICC profile's color space through XYZ to your monitor sRGB causes not much of clippings?

I beg to differ, clearest example I can provide is:
imagine if you have your ICC profile encoded in Adobe RGB color space and you assign it to a photo, then the photo needs to be displayed on a standard monitor with sRGB color gamut (smaller gamut than Adobe)...then necessarily a transformation and remapping for the colors will happen from Adobe RGB --> sRGB and clearly sRGB gamut is limited compared to Adobe RGB hence the loss in information or inaccuracies.

Please try to avoid bringing "gamut" into the discussion

I don't think a discussion about color space and color accuracy can avoid the use of the word "gamut" it is the building block of what we are talking about, right?

--------------------------------------------------------------------------------------------------
please feel free to correct any misunderstanding from my side

best,
Tarek

[xpatUSA]

well...you said it "The ICC profile converts the image color data firstly to XYZ or L*a*b*", so from where and to where?

With all due respect, you should already know that by now.

so basically to my understanding and according to the resources (that I am trying to collect for now), when creating an ICC profile you are encoding your photo's colors in one of your chosen color spaces that is preferably must be wide enough (e.g. ProPhoto). Then there is a transformation happening when you want to print/display your photo and this transformation is carried out in one of the PCS (Profile Connection Space) e.g. CIELAB, CIEXYZ. hence the shrinkage or some loss/inaccuracies during this process of remapping colors (the inaccuracies severity depend of course on how your workflow handle that, clearest example here is moving from display RGB to printer CMYK).

You are implying that inaccuracies are inevitable. I say that that depends on the source image's data where inaccuracies will only occur if the source data (not color space) has a wider gamut than the destination color space.

well quite much, I mean there is no possibility of displaying raw data/numbers after all - it will be just a mess of gray intensities- hence you need to define them inside some boundaries where Red, Green and Blue have pre-defined values --> again that is why you process/any raw engine or studio studio processes your raw data usually in a wide gamut color space (e.g. ProPhoto) which has ,as you mentioned, some (quite much) values outside the defined xyY triangle and even outside the boundaries of the defined visible colors!!

Agreed but nothing new there for those who know how raw is converted to RGB.

sorry but I am not quite sure based on what you are claiming that converting from ICC profile's color space through XYZ to your monitor sRGB causes not much of clippings?

Clippings are not inevitable, if you think about it.

I beg to differ, clearest example I can provide is:
imagine if you have your ICC profile encoded in Adobe RGB color space and you assign it to a photo, then the photo needs to be displayed on a standard monitor with sRGB color gamut (smaller gamut than Adobe)...then necessarily a transformation and remapping for the colors will happen from Adobe RGB --> sRGB and clearly sRGB gamut is limited compared to Adobe RGB hence the loss in information or inaccuracies.

The loss in information or inaccuracies is/are not inevitable if the source data is inside the gamut of the target color space.

I don't think a discussion about color space and color accuracy can avoid the use of the word "gamut" it is the building block of what we are talking about, right?

Agreed only if we are not talking about raw data, i.e. our discussion remains within the CIE 1931 XYZ triangle.

If I recall correctly, your goal is to reproduce scene colors perfectly on a output device? That goal is impossible if the scene colors are themselves outside the gamut of the output device.

Case in point - the 18th patch (cyan) on the 24-patch Macbeth card is out-of-gamut in sRGB. So, with a perfect ICC profile, my perfect sRGB monitor will NEVER show it correctly!!



Good luck with your quest ...

[TarekAH]

thanks Ted, it seems we are on the same page on most concepts. Even though one small thing I am not quite sure about...

You are implying that inaccuracies are inevitable. I say that that depends on the source image's data where inaccuracies will only occur if the source data (not color space) has a wider gamut than the destination color space.

what do you mean exactly when you say "source data has wider gamut than...".
to my understanding these data don't have yet a "gamut" to start with...they are just arbitrary numbers.
Where do these data lies/reside? and don't they need to be defined first in -at least- an arbitrary color space in order to be transformed into a destination color space properly?

I know that technically first they are just arbitrary numbers transduced in the sensor expressed as "intensities" but still meaningless unless they are being defined in a color space - which is usually called CAMERA COLOR SPACE- right?

While reading on how programs such as Lightroom or its alternatives work, it's said that when they open a raw image the data (the colors) are being mapped temporarily in the RAM into the selected working color space of the software (e.g. for Lightroom it is ProPhoto) in order to visualize it. Hence, the "source data" lies in a well-defined color space already (which depends on the used converter engine, but mostly it is either ProPhoto or some other wide gamut if there is any), right?

[xpatUSA]

thanks Ted, it seems we are on the same page on most concepts. Even though one small thing I am not quite sure about...

what do you mean exactly when you say "source data has wider gamut than...".
to my understanding these data don't have yet a "gamut" to start with...they are just arbitrary numbers.
Where do these data lies/reside?

Are you familiar with Bruce Lindbloom's CIE color calculator?

http://www.brucelindbloom.com/index....alculator.html

If so, that will be the best way to explain. In the Calculator, one can enter a color (chromaticity) as CIE xyY and, for any selected color space, see if that color is in-gamut or not. The calculator does not bound numbers to 0 or 255, so it is easy to spot out-of-gamut values.

Let's say we edit an image, raw, TIFF, JPEG, it doesn't matter which, in ProPhoto working color space. After editing, say that a particular pixel has R,G,B values of 96, 102, 39. Those are the source data values that I am talking about. Now we save the image with those data values but with an ICC profile suitable for viewing on an sRGB computer monitor (the destination color space). For that pixel, the ICC profile will cause transformation** of those numbers to R,G,B values of 123, 123, 23 to be sent to the monitor. The transformed numbers are not out of gamut meaning that, although the data saved was for ProPhoto, the data was not outside of the sRGB gamut boundary and the pixel will be shown on the monitor screen at it's correct color in terms of xyY a la CIE. If instead the source RGB numbers were within the ProPhoto gamut but outside of sRGB, then the output numbers would be incorrect.

** I believe that viewing software does the transformation in accord with the ICC matrices (or LUT's for printers).

[xpatUSA]

Let's say we edit an image, raw, TIFF, JPEG, it doesn't matter which, in ProPhoto working color space. After editing, say that a particular pixel has R,G,B values of 96, 102, 39. Those are the source data values that I am talking about. Now we save the image with those data values but with an ICC profile suitable for viewing on an sRGB computer monitor (the destination color space). For that pixel, the ICC profile will cause transformation** of those numbers to R,G,B values of 123, 123, 23 to be sent to the monitor. The transformed numbers are not out of gamut meaning that, although the data saved was for ProPhoto, the data was not outside of the sRGB gamut boundary and the pixel will be shown on the monitor screen at it's correct color in terms of xyY a la CIE.

Found this today which confirms the above statement:

"... When converting to a matrix RGB profile such as sRGB, it's the color gamut of the image itself (and not the color gamut of the source profile) that determines what colors will be clipped upon converting to a smaller color space ..."