What RGB colorspace is used when printing a non colormanaged profiling chart?

[JRSmit]

I tried to find out how, but could not get clear answer.
What RGB colorspace is used when printing a non colormanaged profiling chart?
In my rusty knowledge it requires a RGB colorspace to convert RGB to L*a*b*.
I assume i am wrong but can can someone shed some light ?

[rasworth]

The profiling chart, a set of rgb triplets, provides a stimulus to the printer creating a non-color managed map of the printer's response.  This map is then measured with a spectrophotometer, which creates 36 or so spectral percentage reflectivity numbers for each patch.  These data sets are vector multiplied with the human color matching functions to create a L*a*b* triplet for each patch.  The complete set of L*a*b* values is utilized to create the profile, mapping rgb stimulus values into real colors, unique for each printer/paper/configuration.

However, this mapping has to be inverted to be useful in a color managed workflow, i.e. real colors in an image as defined by a standard editing color space (sRGB, etc.) are translated to the rgb printer stimulus values to achieve the correct color.

Richard Southworth

[simon.garrett@iee.org]

I assume that a profiling chart has an implied colour space?

[Doug Gray]

I assume that a profiling chart has an implied colour space?

No, it does not. It is printed to the native RGB response of the printer/paper combination. The "colorspace" is determined by the printer and paper which is why making a profile is required. The profile contains the colorspace info which can then be used to print Lab values to whatever RGB values are needed for printing that Lab color. That varies with each printer/paper.

[digitaldog]

The short answer is, it doesn't matter.
The slightly longer answer is, whatever RGB color space you assign the numbers to.
So what's happening is this; the software generating the targets was told it needed RGB values to send to the printer because you're profiling an RGB print path. It could be asked for CMYK.
All the package cares about is Lab values (or a similar device independent color space) to produce reference values. Your Spectrophotometer will produce Lab values. Reference and measured data is used to profile the printer. The question could be, what RGB color space was used to convert the Lab reference to RGB to generate the patches. And the profile making company might be able to tell you. But the shortest answer is the best; it doesn't matter and you have no control over it, it 'is what it is'.

[digitaldog]

No, it does not.

Well how did the original reference Lab values become RGB to make the target?
I suggest, there has to be some implied color space but it's not known to us and it doesn't matter to use.

[Doug Gray]

Well how did the original reference Lab values become RGB to make the target?
I suggest, there has to be some implied color space but it's not known to us and it doesn't matter to use.

How? Because there are no "original reference Lab values" from which the RGB patches for profiling a printer are made. I'm shocked you would think that. Typically, RGB patch values are evenly, or as evenly as possible if rounded, spaced often with additional patches near the neutral axis where color perception is more sensitive.

[digitaldog]

How? Because there are no "original reference Lab values" from which the RGB patches for profiling a printer are made.

They are all made from a reference of Lab values; how else would the Spectrophotometer measurement data compare to the reference which is indeed Lab.

Typically, RGB patch values are evenly, or as evenly as possible if rounded, spaced often with additional patches near the neutral axis where color perception is more sensitive.

That's moot; the RGB patch values come from somewhere in; Lab reference values. Just examine dataset for patches in say PatchTool below. RGB values yes, FROM Lab (based on what one selects for a profile or is assumed from the product):

[Doug Gray]

They are all made from a reference of Lab values

Nonsense.

how else would the Spectrophotometer measurement data compare to the reference which is indeed Lab.

Circular reasoning. The spectro data, which is converted to Lab, is not compared to a "reference Lab" but to the output of the profile's AtoB tables. The CMM looks up Lab values from RGB values AFTER the profile is generated from measuring Lab values printed from the RGB values. But the profile first has to be created from the printed RGB patches which do not derive from Lab.

That's moot; the RGB patch values come from somewhere in; Lab reference values. Just examine dataset for patches in say PatchTool below. RGB values yes, FROM Lab (based on what one selects for a profile or is assumed from the product):

Seems pretty obvious that the Patchtool is doing a lookup of Lab values from RGB values using a monitor profile. No idea how that relates to your belief that RGB profile patches for printer profiles are somehow derived from a Lab colorspace.

[digitaldog]

Nonsense.

OK, then tell us the source RGB color space iP1 used to make my TC918 target. And don't forget what I said earlier and why it's not important:
All the package cares about is Lab values (or a similar device independent color space) to produce reference values. Your Spectrophotometer will produce Lab values. Reference and measured data is used to profile the printer. The question could be, what RGB color space was used to convert the Lab reference to RGB to generate the patches. And the profile making company might be able to tell you.
Did X-rite tell you?
All that matters is the Lab values.
If I ask i1P for G255, R0, G0; you think that's from a known lab value OR it's in say ProPhoto RGB which isn't a color in the first place?

Seems pretty obvious that the Patchtool is doing a lookup of Lab values from RGB values using a monitor profile.

Nope, it's Generic RGB according to their manual. RGB values HAVE to be from some color space as you know; actual or assumed. Unlike Lab which is key here.

[Ethan Hansen]

There appears to be some confusion about how the profiling process works. A profiling target, be it BGB, CMYK, or multicolor is just a bag of numbers. These numbers are thrown at the printer (or monitor, TV, etc.) and a spectrophotometer measures what color (spectral ideally, converted to LAB or XYZ if you must) these numbers produced. A profile is at its essence a translation tool. You image contains a particular color; what numbers does the printer/monitor/etc. need to be given to match the source as accurately as possible (colorimetric intent) or aesthetically (perceptual and saturation intents)? The CMM then converts the image pixels to the appropriate device values and sends them along.

The initial RGB target values have no color space attached. That is why it is so important pr print targets or show them on a display with no intervening color management. A 918 patch target RGB for i1Profiler contains an equally spaced 9x9x9 step cube of RGB values (729 base grid patches), a smattering of semi-neutral colors, additional colors in highlights and shadows, etc. I do not know what color space, if any, i1Profiler (or ColorPort, MeasureTool, PatchTool... etc.) use to show reference values. My suspicion is that they simply throw the RGB values at the screen and let them display as they may. For CMYK, the values undergo some default transformation to RGB. Color accuracy is not essential here - it's just a visual representation to indicate whether the chart was measures semi-successfully.

It is only if you generate a profile target from an a priori assumption of device behavior that the reference data set becomes anything other than a mathematical abstraction. For example, in two stage printer profiling, you'll print a smaller generic target to get a sense of how the particular device behaves; e.g. where color output varies smoothly and predictably, where the kinks are, and areas where colors bunch together. From this small chart, you create a larger data set with closely spaced patches in problem areas and larger spacing in well behaved sections. This allows reasonable measurement and computation time while still providing accurate coverage. The actual target values, however, remain a bag of numbers.

[digitaldog]

There appears to be some confusion about how the profiling process works. A profiling target, be it BGB, CMYK, or multicolor is just a bag of numbers.

Indeed so one can assign/assume any scale (color space) and come up with any answer one desires.

The initial RGB target values have no color space attached.

Indeed, nor is one needed. Just as, without color management, RGB values can be sent directly to a display for a preview.

That is why it is so important pr print targets or show them on a display with no intervening color management. A 918 patch target RGB for i1Profiler contains an equally spaced 9x9x9 step cube of RGB values (729 base grid patches), a smattering of semi-neutral colors, additional colors in highlights and shadows, etc. I do not know what color space, if any, i1Profiler (or ColorPort, MeasureTool, PatchTool... etc.) use to show reference values. My suspicion is that they simply throw the RGB values at the screen and let them display as they may. For CMYK, the values undergo some default transformation to RGB. Color accuracy is not essential here - it's just a visual representation to indicate whether the chart was measures semi-successfully.

So i1P can optionally import images for target creation. The tagged image data would/could be used for part of said target. Now what happens when I import the image in sRGB using G255/B0/R0 versus importing the same triplet in ProPhoto RGB? Does i1P examine that tag, or is it 'just an RGB number', or i1P assumes some internal scale for RGB?
Does it matter?
Some RGB values are produced, either initially or upon import. And yes, I agree, they are just numbers. To have a meaning above and beyond just being pure numbers, they need a color space, a scale for said numbers. Or if they are interpreted into Lab.
This is a bit like the old question: does raw have a color space? Yes, but that color space may not be known, or it might not be a colorimetric color space (again, G255 in ProPhoto RGB).
If we want to give a set of RGB numbers an actual meaning, we need a scale. If we want to reinterpret it into Lab, we need a scale.  One question was: I assume that a profiling chart has an implied colour space? And it most certainly can, but what is it?
What would be interesting would be to see if and when i1P imports an image in two vastly different color spaces, does it do so identically? I've never looked but it would be an interesting exercise.

[Doug Gray]

OK, then tell us the source RGB color space iP1 used to make my TC918 target.

i1P doesn't use a "source RGB colorspace" to generate printer targets. No idea why you continue to think it does.

All the package cares about is Lab values (or a similar device independent color space) to produce reference values. Your Spectrophotometer will produce Lab values. Reference and measured data is used to profile the printer.

Only the RGB patches' numerical values and measured spectral data converted to Lab, are used to profile a printer. The RGB values of the printed sheet can be said to be in the combined printer/paper's colorspace but that's about all that can said. That obviously varies quite a bit from printer/paper to other printer/papers.

Nope, it's Generic RGB according to their manual. RGB values HAVE to be from some color space as you know.

I know no such thing. RGB values are just RGB values. Sort of like RAW camera files. They don't have a color space until processed using knowledge of the CFAs or printed using CYMK in the case of RGB profile printer targets.

[digitaldog]

Sort of like RAW camera files. They don't have a color space until processed using knowledge of the CFAs or printed using CYMK in the case of RGB profile printer targets.

That's not so. As outlined many years ago when asked of multiple experts; need the copy and paste? They don't have a colorimetric color space, but a color space indeed if we listen to three color scientists when asked:

Does a raw file have a color space?>>

Fundamentally, absolutely YES, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these
primaries define the color space of the image.
Practically, it makes little difference unless you are interested in accurate scene-referred data. In the context you described, a simple transform is applied to convert from the camera primaries to a new set of primaries (eg CIE or working space) that have more desirable characteristics than the RAW primaries.
Mathematically, of course, you know the foregoing is true. Matrix algebra informs that if the final color image encoding is a "color space" then so must be all of its infinite number of linear transforms (lets ignore the 1 D non-linear transfer functions), including the original RAW encoding.
Eric Walowit
Tahoe

Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry.
The same thing could be said about film negative densities.
Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like with film scanning).
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation. In the standards committees we decided it is useful to be able to talk about non-colorimetric color spaces so we allow them and use “colorimetric color spaces” when appropriate.
Jack Holm


On Jan 18, 2008, at 9:36 AM, Thomas Knoll  wrote:
The fact that a mosaic array is “grayscale” is a red herring in this argument.  An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result.  For most cameras, if you just “assign” a working space RGB profile, you get a recognizable color image as a result, so it certainly seems like a color space.
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently.  Any translation from camera color space to CIE XYZ space is an approximation because of this.

Going full circle: does the profiling package have a implied color space? Practically, it makes little difference.

[Doug Gray]

That's not so. As outlined many years ago when asked of multiple experts; need the copy and paste? They don't have a colorimetric color space, but a color space indeed if we listen to three color scientists when asked:

Does a raw file have a color space?>>

Fundamentally, absolutely YES, but we may not know what that color space is. The image was recorded through a set of camera spectral sensitivities which defines the intrinsic colorimetric characteristics of the image. An simplistic way to think of this (while not purely accurate) is that the image was recorded through a set of "primaries" and these
primaries define the color space of the image.
Practically, it makes little difference unless you are interested in accurate scene-referred data. In the context you described, a simple transform is applied to convert from the camera primaries to a new set of primaries (eg CIE or working space) that have more desirable characteristics than the RAW primaries.
Mathematically, of course, you know the foregoing is true. Matrix algebra informs that if the final color image encoding is a "color space" then so must be all of its infinite number of linear transforms (lets ignore the 1 D non-linear transfer functions), including the original RAW encoding.
Eric Walowit
Tahoe

Raw image data is in some native camera color space, but it is not a colorimetric color space, and has no single “correct” relationship to colorimetry.
The same thing could be said about film negative densities.
Someone has to make a choice of how to convert values in non-colorimetric color spaces to colorimetric ones. There are better and worse choices, but no single correct conversion (unless the “scene” you are photographing has only three independent colorants, like with film scanning).
A purist might argue that a color space not based on colorimetry is not really a color space because it is not an assignment of numerical values to colors, defining colors as a human sensation. In the standards committees we decided it is useful to be able to talk about non-colorimetric color spaces so we allow them and use “colorimetric color spaces” when appropriate.
Jack Holm


On Jan 18, 2008, at 9:36 AM, Thomas Knoll  wrote:
The fact that a mosaic array is “grayscale” is a red herring in this argument.  An early processing step fills in the missing values, and you have a 3 or 4 channel image as a result.  For most cameras, if you just “assign” a working space RGB profile, you get a recognizable color image as a result, so it certainly seems like a color space.
The camera color space differences from a more common working color space in that it does not have a unique one-to-one transform to and from CIE XYZ space. This is because the camera has different color filters than the human eye, and thus sees colors differently.  Any translation from camera color space to CIE XYZ space is an approximation because of this.

I agree with these people. Perhaps I should have worded it like this:

Sort of like RAW camera files. They don't have a known color space until processed using knowledge of the CFAs or printed using CYMK in the case of RGB profile printer targets. After printing, measuring, and profiling,  the chart the device's RGB colorspace becomes known

Going full circle: does the profiling package have a implied color space? Practically, it makes little difference.

It makes no difference because it doesn't normally have an implied colorspace. There is an exception.

Your mention of importing colors such as, generated patches, spot colors or sampled from an image in an optimization phase uses a preselected profile to process those colors. It this case the color space is known (the pre-existing profile) and the patches can be placed based on that.

[digitaldog]

Your mention of importing colors such as, generated patches, spot colors or sampled from an image in an optimization phase uses a preselected profile to process those colors. It this case the color space is known (the pre-existing profile) and the patches can be placed based on that.

And if imported untagged which is possible? AFAIK, no warning dialog, then?

[Doug Gray]

And if imported untagged which is possible? AFAIK, no warning dialog, then?

Warning dialog? From XRite? lol.

I just added 20 patches from an image then saved the patch set as an RGB i1Profiler CGATs and pxf file. The RGB patch set is fractional, just like creating new patches from scratch. However, the RGB values for created smart patches clearly use the profile to optimize the set. However, they also create fractional values which are rounded when printed but not rounded when used, directly with measurements, to make a new profile.

A few other observations. The CGATs file has the same values as the patches in i1Profiler except for the additional patches from the image. Those, like the smart patches, are completely wrong and some values are even negative. Last I've heard RGB triplets are 0-255.

On closer look the 20 extra RGB values, unlike the additional smart patches, do not correspond to those in the target tif file but appear to actually be in Lab (hence the negative values). Seems there is a bug in I1Profiler. So beware saving optimized patch sets in CGATs format. pxf should be safe.

As for what it includes sampling colors from a tif image, I ran a test with one of the kids in the Kodak Disc saving it as both Adobe RGB and converted to ProPhoto RGB. Both tagged. The patches added were quite desaturated from the ProPhoto RGB import in comparison to the Adobe RGB import.

Looks like very little testing has been done by XRite in this area.

[DP]

That's not so.

that's exactly so because your 3 color gurus can't give any formal definition of it

[digitaldog]

that's exactly so because your 3 color gurus can't give any formal definition of it

More like you don't understand what they've clearly written even with the salient points bolded.
Oh, and they are not my color gurus; all three are (like myself) members of the ICC.
You have any idea for example, who Eric and Jack is, and what each has done in the field of color (unlike you sir, hiding behind an alias)?
https://www.linkedin.com/in/eric-walowit-7934a04/
https://www.linkedin.com/in/jack-holm-bb536b9/

[GWGill]

I tried to find out how, but could not get clear answer.
What RGB colorspace is used when printing a non colormanaged profiling chart?

If the chart is used as intended, then the RGB space is (by definition) the native space of the device you print it on. That's the very purpose of a profiling chart.

What can make this confusing this is that many of the systems that deal with images don't have a way of representing this. Some/many assume that any image must have a defined/known/default colorspace. So it may appear that a test chart image is in some particular colorspace, even though it isn't.
Technically there are standards for labelling an image as having a specific colorspace or not being tagged at all. The latter could/should mean that it is in the colorspace of the device it is used on, but this is ambiguous - it could just mean that the creator hasn't labelled it ("mystery meat"). What is missing from the standards is a way of specifically labelling the colorspace as being that of the destination device AKA the "I'm a test chart" tag. (This is something I've suggested a few times in ICC circles, but no-one has been motivated enough to go anywhere with it :-)

Due to the lack of an explicit "I'm a test chart tag" and the lack of clear workflows on many systems for printing test charts, sometimes some colorspace trickery has to be used to get a test chart printed correctly - i.e. setting the devices driver profile to something specific, and then labelling the test chart with the same profile, so that the driver sees the match, and does a "null" transform when printing.

Another point of confusion is that the RGB/device values may have been chosen on the basis of an assumed device colorspace.  This is just a mechanism for making the test chart as efficient as possible - the assumed colorspace just has to represent the general behaviour of a class of devices to be useful.
There is also the possibility of "bootstrapping" the test chart - using a previous profile for the device in question to (say) pick device test values that are close to being on the devices neutral axis, etc.