Luminous Landscape Forum
Raw & Post Processing, Printing => Colour Management => Topic started by: JRSmit on September 27, 2020, 06:43:10 am
-
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 ?
-
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
-
I assume that a profiling chart has an implied colour space?
-
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.
-
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'.
-
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.
-
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.
-
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):
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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?
-
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.
-
That's not so.
that's exactly so because your 3 color gurus can't give any formal definition of it
-
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/
-
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.
-
Well, this is certainly interesting and strange as hell.
Experiment.
1. Created a ProPhoto RGB tif file with a color gradient going from Lab 50,-50,0 to 50,-40,0 which is a moderately saturated darkish green. Saved as an RGB tif file and tagged with ProPhoto RGB. Contains no colors outside of that gradient.
2. Selecting optimize profile and using a profile with the standard 957 patch set for a 9500II I then added another 957 "Smart patches. The result was a new set of 957 patches with about 1/3 of them near neutrals.
3. I selected extract patches from an image then dragged and dropped the green gradient image into it. I1Profiler added the default 20 patches.
4. I then saved the chart image tif files, the pfx RGB patch file, and the I1Profiler CGATS patch file. Here's what the CGATs file had. Note the crazy "RGB" values in the last 20 locations.
CGATS.17
ORIGINATOR "i1Profiler - X-Rite, Inc."
INSTRUMENTATION "i1iSis XL ; Serial number 0"
DESCRIPTOR "9500 Baryta 957 D50 M2 ppRGB"
FILTER ""
KEYWORD "DEVCALSTD"
DEVCALSTD "XRGA"
CREATED "2020-09-27T18:40:11"
NUMBER_OF_FIELDS 5
BEGIN_DATA_FORMAT
SAMPLE_ID SAMPLE_NAME RGB_R RGB_G RGB_B
END_DATA_FORMAT
NUMBER_OF_SETS 977
BEGIN_DATA
1 - 18.69 255.00 255.00
2 - 0.00 221.91 249.46
3 - 19.33 181.39 255.00
4 - 5.33 112.18 247.76
......
973 - 46.83 -16.26 0.91
974 - 46.83 -16.26 0.91
975 - 46.83 -16.26 0.91
976 - 46.83 -16.26 0.91
977 - 46.83 -16.26 0.91
END_DATA
Yep, Those sure aren't RGB values. Looks like Lab values that their software created and added to a RGB CGATs file. Software bug.
So then I looked at the RGB values in the pxf file. Basically all entries at the end like this:
<cc:CreationDate>2020-09-28T02:39:46Z</cc:CreationDate>
<cc:DeviceColorValues>
<cc:ColorRGB ColorSpecification="Unknown">
<cc:R>81</cc:R>
<cc:G>125</cc:G>
<cc:B>91</cc:B>
</cc:ColorRGB>
</cc:DeviceColorValues>
</cc:Object>
<cc:Object ObjectType="Target" Name="Target968"
OK, that actually make sense. Sort of. At least they aren't Lab values with negative entries.
Next step, look at the green gradient tif file that was tagged ProPhoto RGB. The patches were RGB=(81,125,92). OK, the B value was 92 but we've already established that when I1Profiler saves pfx patches files it truncates fractional values while it rounds them when making a tif chart. Cool.
So now lets see what the tif file added patches are when the tif file is assigned the printer's profile. Ah, now that the patches are being interpreted in the printer's device colorspace guess what the Lab values as read out in Photoshop (Abs Col)?
Yep, Lab=47,-16,1
Gee, identical (after rounding) to Lab values erroneously added at the end the CGATs file.
All of which is FUBAR since adding a bunch of extra patches from an image which are printed at Lab 47,-16,1 don't do a darned thing to improve the printer's profile accuracy at Lab=50,-40,0 to 50,-50,0 which were supposedly the colors needing improvement.
-
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
So in the first part of your statement, the simplest case, a rgb triplet (1 patch) is put into the print pipeline and results in a print of that patch.
That rgb triplet, where in the Lab color space is it?
When specified, it’s color as observed varies with the rgb color space assigned to it. And per rgb space a different place in Lab space.
If I take the same rgb triplet and print it twice, each with a different rgb profile assigned, i get two different looking patches.
So it looks to me that the print pipeline, in a not color managed situation, still has to put this rgb triplet somewhere in the , let us call it the color universe. In my thinking thus some defined rgb color space.
Secondly the application used to create the rgb triplet, a profiling application, also has to have its notion of where in the color universe it’s triplet is, otherwise it can not have a reference value.
Or am I looking in the wrong direction?
-
Seems my question has triggered some reactions, which I did not notice when responding to Richard’s post. Still digesting all the responses ,but it is still not clear to me.
-
Yes, you caused the color experts' juices to flow.
I think the way to think about it is from a printer manufacturer's viewpoint. The ink mixing algorithms are set to give something reasonable for unmodified RGB inputs. By reasonable I mean RGB=200,50,50 should result in a fairly saturated shade of red. And the manufacturer is going to keep the channels monotonic, i.e. as R increases the shade of red brightens. Also for R=G=B triplets we expect to see something close to gray. There are certainly many more constraints, but the end result is something that with no color management, just feed the image RGB triplets directly into the printer, will result in something visually ok.
But I believe the manufacturer can only get so close, given that many types of paper will receive the same ink recipe. The printer target, which is the result of unmodified RGB triplets fed in to create the patches, belongs to some broadly defined color space "built in" to the printer. It's up to the profile created from that target to narrow it down to a specific paper, using a specific dot density, and designed to be viewed under a specific illuminant, to allow printing an image that is close if not identical to what we viewed on the monitor. An image pixel in the sRGB space with RGB = 200,50,50 may be converted by the profile to 205, 46, 58 at the printer inputs to achieve that goal. In this sense a closely defined color space doesn't exist for the freshly printed target, we require the spectro measurements and profile software to achieve such.
As a side note, today's printers are much more "linear" than the ones 15-20 years ago, when I first began printer profiling. The neutral curves, a plot of the RGB values necessary to print gray step charts, were significantly off of the R=G=B axis. Today's printers are easier to "tame", the profiles don't have to push the RGB values as far to achieve correct colors. This has resulted in needing fewer patches to create good quality profiles.
Hope this helps,
Richard Southworth
-
If I take the same rgb triplet and print it twice, each with a different rgb profile assigned, i get two different looking patches.Or am I looking in the wrong direction?
If you are getting two different looking colors printing the same triplet then you are not printing without color management. That's the problem. How the image is tagged, being it sRGB, ProPhoto RGB, or untagged should make absolutely no difference in the color of the printed patches when printed without color management.
That is the whole reason for using ACPU, or the utility from DryCreek, or using null transform trick in Photoshop using Windows or printing directly from I1Profiler. It's essential to print with color management disabled or you will not be able to create good profiles.
-
unless you have done a conversion by mistake unless an assignment, in which case the numerical values would indeed change (and the source profile would be assumed as whatever you have set as default in PS or whatever program)
-
If you are getting two different looking colors printing the same triplet then you are not printing without color management. That's the problem. How the image is tagged, being it sRGB, ProPhoto RGB, or untagged should make absolutely no difference in the color of the printed patches when printed without color management.
That is the whole reason for using ACPU, or the utility from DryCreek, or using null transform trick in Photoshop using Windows or printing directly from I1Profiler. It's essential to print with color management disabled or you will not be able to create good profiles.
What I meant was color-managed printing as I tried to say with having the same triplet printed once with profiel a and once with profiel b assigned. In other words the color space used makes a difference.
I use the Drycreek utility as it does not scale like acpu , i use windows 10.
Whether I print from i1 Profiler or via i1 profiler save the chart as tif, then print with Drycreek utility does not give a difference.
-
Yep, Those sure aren't RGB values. Looks like Lab values that their software created and added to a RGB CGATs file. Software bug.
Bug? Perhaps. Point is, you feed the software RGB, it produced Lab and to do so, it had to assume some RGB color space no?
I'd have (and may do) a simpler experiment:
1. Make three documents, say 100x100 pixels using RGB triplets R0/G255/B0 in sRGB, ProPhoto RGB and untagged.
2. Import as a target (optimization or otherwise).
3. Create a TIFF as if I were printing it.
4. Examine the values (RGB/Lab) resulting from that export.
But your test, more though seems to show Lab values being produced and the question then becomes, from what of the RGB you feed the product?
-
So in the first part of your statement, the simplest case, a rgb triplet (1 patch) is put into the print pipeline and results in a print of that patch.
That rgb triplet, where in the Lab color space is it?
Whatever you assign; the new scale of the RGB numbers and hence Lab values from it.
I can say my new puppy weights 12. You can assign pounds, ounces, kilo's to that number. The number now has a scale and a meaning.
When specified, it’s color as observed varies with the rgb color space assigned to it. And per rgb space a different place in Lab space.
Yes, hence my last question to Doug about the Lab values he found from feeding one product RGB numbers.
If I take the same rgb triplet and print it twice, each with a different rgb profile assigned, i get two different looking patches.
So it looks to me that the print pipeline, in a not color managed situation, still has to put this rgb triplet somewhere in the , let us call it the color universe. In my thinking thus some defined rgb color space.
IF assigned or converted yes, different results. Just as using Kilo's vs. pounds produces a different weight of the puppy.
Secondly the application used to create the rgb triplet, a profiling application, also has to have its notion of where in the color universe it’s triplet is, otherwise it can not have a reference value.
Which was my original point before we got into raw having a color space (it does, and of course one alias poster had to misread this and knock some color experts who specifically indicated raw does have a color space even if it's undefined).
Does the target of RGB data have a color space? Yes; whatever you use to define it's scale and it can be undefined (but a color space it has). Now how were the values produced? I suspect differing software products may use differing approaches, certainly it seems from Doug's experiment, i1P is doing something and applying Lab values. How and why? But again, when the rubber hits the road, it probably doesn't matter unless (big unless), the RGB generation is such it could either potentially create triplets that are (gamut) clipped compared to the device or, outside the spectrum locus. I'd hope neither is the case. In terms of what's happening under the hood with at least one software product, there is one person here who is qualified to tell us: GWGill
-
Seems my question has triggered some reactions, which I did not notice when responding to Richard’s post. Still digesting all the responses ,but it is still not clear to me.
I will ask simple but maybe strange question: why do you need to know it? :-)
-
I think I asked a similar question long time ago in a kind of round about way - if the same file is assigned 3 difference colorspaces, i.e. sRGB, AdobeRGB and ProPhotoRGB and sent to print with the same conditions and same printer/paper profile, would the prints look same or different. If different, then shouldn't the printer/profile have a specific input colorspace that it should be good for. In other words why isn't there different profile for different input colorspace?
-
I think I asked a similar question long time ago in a kind of round about way - if the same file is assigned 3 difference colorspaces, i.e. sRGB, AdobeRGB and ProPhotoRGB and sent to print with the same conditions and same printer/paper profile, would the prints look same or different.
If indeed you assign three different profiles to the same numbers, the numbers have three different definitions; they are not the same color. If you then convert them with the same output profile, you again have three different colors.
Again, an analogy. If I tell you we are a distance of 1000 apart, then I supply miles, feet, meters to that one number, indeed there are three differing descriptions of distance we are apart.
-
If indeed you assign three different profiles to the same numbers, the numbers have three different definitions; they are not the same color. If you then convert them with the same output profile, you again have three different colors.
Again, an analogy. If I tell you we are a distance of 1000 apart, then I supply miles, feet, meters to that one number, indeed there are three differing descriptions of distance we are apart.
Right. I understood that part. But then why don't we have different paper profiles for different colorspaces. Would it not be more accurate if the target is printed with the colorspace in question to create an unique paper profile that is best for documents that have that particular colorspace.
-
I will ask simple but maybe strange question: why do you need to know it? :-)
A good question.
For me : To understand the total chain of color management in printing, or perhaps better worded : color control. And this is basically the start of the chain, yet this point is not clear.
After this point the chain is basically all profile managed, basically open, and quite documented. (Not necessarily easy ;-))
All this obviously for me as print studio to continuously improve the print quality.
-
Right. I understood that part. But then why don't we have different paper profiles for different colorspaces. Would it not be more accurate if the target is printed with the colorspace in question to create an unique paper profile that is best for documents that have that particular colorspace.
This is why an icc print profile has ‘in the middle’ a profile connection space.
-
There's nothing in the middle of an icc print profile. It relates real colors, i.e. L*a*b* values, to the corresponding rgb triplet required to duplicate that color on the printer. The image has an embedded profile that relates its rgb pixels to L*a*b* (going thru XYZ first) values. The CMS engine used by the application connects the image with the display and the printer.
There is one profile each for the image, display and printer, and none have to worry about the other. This is why talking about printing targets for multiple color spaces makes no sense, all we need to do is characterize the printer/paper combination by itself. One of the major benefits of icc profiles is their independence from each other, once we have characterized the image and each device the CMS takes care of the rest.
Richard Southworth
-
Bug? Perhaps. Point is, you feed the software RGB, it produced Lab and to do so, it had to assume some RGB color space no?
I'd have (and may do) a simpler experiment:
1. Make three documents, say 100x100 pixels using RGB triplets R0/G255/B0 in sRGB, ProPhoto RGB and untagged.
2. Import as a target (optimization or otherwise).
3. Create a TIFF as if I were printing it.
4. Examine the values (RGB/Lab) resulting from that export.
But your test, more though seems to show Lab values being produced and the question then becomes, from what of the RGB you feed the product?
Ok, here's what what I did using your 3 R0/G255/R0 documents untagged, and tagged with sRGB and ProPhoto RGB.
1. Select optimize profile (adding colors from an image is not available in profiling menu.)
2. Select a printer profile previously made for the Canon 9500II and generate 100 smart patches.
3 Add 20 colors from the green images using "Extract patches from an image"
We now have a total of 120 colors in the patch set. The first hundred appear to be optimized to improve the 9500 II profile using the saved spectral data in the profile. The last 100 appear as green.
Now for the fun. Double click on any of the first 100 patches to read the generated RGB patch values. Now double click on one of the green ones at the bottom. The RGB value from the earlier click is unchanged. Click on a red patch then back to a green patch and the green patch reads the same RGB values as the red patch.
BUG.
Save both the pxf and CGATs patch files after adding each of the 3 tagged/untagged green images. The added green patches from the untagged, and tagged green images all produce exactly the same RGB values.
After saving the pxf and CGATs patch file the CGATs file has the same RGB values in the first 100 triplets as the pxf file. Except that the pxf file has truncated (not rounded) values while the CGATs files has fractional "RGB" values.
The last 20 are Lab, not RGB which is a bug since the CGATs file has no Lab fields, only RGB fields.
If the pxf file is now reloaded, and then saved as a CGATs file the last 20 patches are magically transformed to be the same as in the pxf.
Here's the buggy CGATS file in full. NOTE that RGB files are between 0.00 and 255.00.
CGATS.17
ORIGINATOR "i1Profiler - X-Rite, Inc."
INSTRUMENTATION "i1iSis XL ; Serial number 0"
DESCRIPTOR "greenpp_9500 Baryta 957 D50 M2"
FILTER ""
KEYWORD "DEVCALSTD"
DEVCALSTD "XRGA"
CREATED "2020-09-28T14:06:53"
NUMBER_OF_FIELDS 5
BEGIN_DATA_FORMAT
SAMPLE_ID SAMPLE_NAME RGB_R RGB_G RGB_B
END_DATA_FORMAT
NUMBER_OF_SETS 120
BEGIN_DATA
1 - 0.00 255.00 249.00
2 - 43.00 158.00 255.00
3 - 2.00 38.00 255.00
4 - 60.00 255.00 204.00
5 - 33.00 158.00 179.00
6 - 89.00 214.00 230.00
7 - 9.00 55.00 153.00
8 - 62.00 89.00 187.00
9 - 119.00 155.00 246.00
10 - 44.00 13.00 167.00
11 - 95.00 58.00 206.00
12 - 160.00 107.00 255.00
13 - 83.00 0.00 214.00
14 - 150.00 39.00 246.00
15 - 9.00 187.00 85.00
16 - 67.00 233.00 135.00
17 - 0.00 98.00 46.00
18 - 47.00 139.00 104.00
19 - 94.00 193.00 149.00
20 - 145.00 251.00 199.00
21 - 0.00 18.00 41.00
22 - 34.00 49.00 75.00
23 - 82.00 96.00 118.00
24 - 128.00 149.00 164.00
25 - 186.00 214.00 216.00
26 - 237.00 255.00 255.00
27 - 75.00 20.00 93.00
28 - 126.00 62.00 132.00
29 - 188.00 103.00 176.00
30 - 243.00 174.00 233.00
31 - 112.00 0.00 136.00
32 - 176.00 30.00 152.00
33 - 237.00 78.00 192.00
34 - 244.00 0.00 240.00
35 - 74.00 224.00 13.00
36 - 107.00 180.00 26.00
37 - 161.00 243.00 56.00
38 - 99.00 112.00 0.00
39 - 146.00 142.00 30.00
40 - 209.00 201.00 74.00
41 - 255.00 255.00 124.00
42 - 144.00 63.00 0.00
43 - 192.00 105.00 38.00
44 - 255.00 164.00 80.00
45 - 176.00 25.00 13.00
46 - 242.00 70.00 40.00
47 - 159.00 255.00 9.00
48 - 209.00 209.00 15.00
49 - 255.00 162.00 20.00
50 - 251.00 77.00 0.00
51 - 19.00 0.00 2.00
52 - 23.00 0.00 0.00
53 - 25.00 14.00 0.00
54 - 42.00 6.00 0.00
55 - 30.00 9.00 0.00
56 - 39.00 17.00 2.00
57 - 53.00 6.00 0.00
58 - 70.00 30.00 17.00
59 - 86.00 24.00 18.00
60 - 104.00 29.00 18.00
61 - 122.00 40.00 32.00
62 - 117.00 60.00 63.00
63 - 129.00 80.00 77.00
64 - 151.00 68.00 53.00
65 - 169.00 99.00 74.00
66 - 190.00 88.00 68.00
67 - 184.00 116.00 110.00
68 - 195.00 118.00 82.00
69 - 192.00 138.00 109.00
70 - 221.00 123.00 94.00
71 - 229.00 152.00 103.00
72 - 247.00 160.00 122.00
73 - 254.00 189.00 140.00
74 - 247.00 212.00 192.00
75 - 251.00 231.00 187.00
76 - 0.00 3.00 0.00
77 - 4.00 8.00 6.00
78 - 25.00 28.00 27.00
79 - 48.00 51.00 50.00
80 - 67.00 69.00 66.00
81 - 87.00 88.00 82.00
82 - 107.00 106.00 98.00
83 - 130.00 128.00 117.00
84 - 152.00 149.00 136.00
85 - 172.00 171.00 156.00
86 - 191.00 192.00 178.00
87 - 215.00 215.00 201.00
88 - 233.00 234.00 224.00
89 - 0.00 4.00 46.00
90 - 4.00 11.00 49.00
91 - 33.00 36.00 73.00
92 - 61.00 61.00 95.00
93 - 82.00 80.00 112.00
94 - 101.00 101.00 129.00
95 - 123.00 123.00 152.00
96 - 148.00 149.00 175.00
97 - 174.00 178.00 199.00
98 - 201.00 207.00 226.00
99 - 225.00 229.00 253.00
100 - 244.00 251.00 255.00
101 - 86.03 -91.77 82.59
102 - 86.03 -91.77 82.59
103 - 86.03 -91.77 82.59
104 - 86.03 -91.77 82.59
105 - 86.03 -91.77 82.59
106 - 86.03 -91.77 82.59
107 - 86.03 -91.77 82.59
108 - 86.03 -91.77 82.59
109 - 86.03 -91.77 82.59
110 - 86.03 -91.77 82.59
111 - 86.03 -91.77 82.59
112 - 86.03 -91.77 82.59
113 - 86.03 -91.77 82.59
114 - 86.03 -91.77 82.59
115 - 86.03 -91.77 82.59
116 - 86.03 -91.77 82.59
117 - 86.03 -91.77 82.59
118 - 86.03 -91.77 82.59
119 - 86.03 -91.77 82.59
120 - 86.03 -91.77 82.59
END_DATA
-
BUG.
Save both the pxf and CGATs patch files after adding each of the 3 tagged/untagged green images. The added green patches from the untagged, and tagged green images all produce exactly the same RGB values.
120 - 86.03 -91.77 82.59
[/b]END_DATA
[/i]
Hold on there... Let's look at what this shows:
1. You imported RGB triplets and got Lab values. So the idea that no implied RGB color space in this (other?) profilers isn't used isn't so or you wouldn't get Lab values in the first place, right?
2. If you examine those lab values, you'll see that's darn close to R0/G255/B0 in sRGB! Just load those Lab values in Photoshop's foreground color picker, toggle your RGB Working Space from ProPhoto RGB (nope), to Adobe RGB (1998) (no again) to sRGB: Bingo!
(see below)
3. The product clearly doesn't care about the tag you applied; it treated all three, assumed all three were sRGB. At least to produce all those Lab values.
Let's move to the part that started all this:
Q: I assume that a profiling chart has an implied colour space?
A: No, it does not.
Well it appears from this one test, at least in this one example, indeed there is an implied color space; sRGB. How else would you explain those Lab values generated?
-
Hold on there... Let's look at what this shows:
1. You imported RGB triplets and got Lab values. So the idea that no implied RGB color space in this (other?) profilers isn't used isn't so or you wouldn't get Lab values in the first place, right?
First, please note that the patches actually added do not have those Lab values, in sRGB, ProPhoto RGB or any other colorspace I've found. The patches added are not R0/G255/R0 but R100/G254/R19.
When adding image patches that the profile is supposed to optimize the profile around it has a few choices. It can ignore the actual colorspace of the imported images and just assign it sRGB. Works great if the images you print are in sRGB. Just offhand I would expect that most people that are so color critical as to make optimized profiles are not working from sRGB. But maybe that's just me.
If you examine those lab values, you'll see that's darn close to R0/G255/B0 in sRGB!
And is just what happens when the coders decided to ignore the colorspace of images that contain colors one is trying to improve and just said, what the hell, let's just use sRGB. That's what everyone uses, right?
The correct thing to do is use the tagged colorspace to convert sample image colors to Lab probably using Rel. Col. Then convert those to the device RGB colorspace. That would most likely produce the closest sets of patch colors that could be added to improve the profile in that region.
Well it appears from this one test, at least in this one example, indeed there is an implied color space; sRGB. How else would you explain those Lab values generated?
It's a bug. How do you explain what is clearly Lab converted from sRGB(0,255,0) that is showing up at the end of a set of otherwise reasonable RGB values. It didn't even catch the fact the values had large negative numbers. This is simply bad programming and thus likely meaningless.
But lets look at what actually gets stored in the XRite format pxf patch files. It ain't the bogus Lab values. Its this:
RGB (100,254,19) and that's also what gets saved in the tif charts. What does that get printed as? On my 9500 it comes out Lab (70,-59,58) and that obviously is nothing anywhere close to what gets printed with a RGB(0,255,0) patch in sRGB using color management or not.
Fortunately, this bug is unlikely to show up as making the profile worse. It doesn't hurt anything. Just doesn't help.
-
First, please note that the patches actually added do not have those Lab values, in sRGB, ProPhoto RGB or any other colorspace I've found. The patches added are not R0/G255/R0 but R100/G254/R19.
OK, you said: Ok, here's what what I did using your 3 R0/G255/R0 documents untagged, and tagged with sRGB and ProPhoto RGB.
And: The last 100 appear as green.
Did you mean the last group from 100 on? So what are 101-120?
When adding image patches that the profile is supposed to optimize the profile around it has a few choices. It can ignore the actual colorspace of the imported images and just assign it sRGB. Works great if the images you print are in sRGB. Just offhand I would expect that most people that are so color critical as to make optimized profiles are not working from sRGB. But maybe that's just me.
All I'm concerned with at this point is the RGB R0/G255/B0 you added and what (if any?) Lab values you got. Why do the last group (101-120) in bold, show Lab values?
What triplets did you add that presumably produced 101-120? Or did you not do this? If you did do so, there are lab values from RGB triplets. Again, how did those Lab values get generated?
-
And is just what happens when the coders decided to ignore the colorspace of images that contain colors one is trying to improve and just said, what the hell, let's just use sRGB. That's what everyone uses, right?
At this point, that doesn't matter whatsoever. We don't know the idea behind the product and it's moot. Call it a bug but the point is, the RGB triplets WERE assigned an RGB color space: sRGB.
The correct thing to do is use the tagged colorspace to convert sample image colors to Lab probably using Rel. Col. Then convert those to the device RGB colorspace. That would most likely produce the closest sets of patch colors that could be added to improve the profile in that region.
It's what you believe is the right thing and I'm not going to disagree or agree. It doesn't matter at this point, it's going OT from the original question asked and the answer provided. Again:
Q: I assume that a profiling chart has an implied colour space?
A: No, it does not.
Seems it absolutely does assume an implied color space: sRGB. We can agree that's a 'bug' and the tagged color space should be used. That's an additional discussion. But clearly, the product did use an implied color space as again, if it didn't, how on earth did those Lab values get produced? Those Lab values ARE 0/255/0 in sRGB as I showed in my screen capture (well within one value).
It's a bug. How do you explain what is clearly Lab converted from sRGB(0,255,0) that is showing up at the end of a set of otherwise reasonable RGB values.
No, how do you explain "no, it does not" assume an implied color space after stating clearing there was a Lab conversion from sRGB?
RGB (100,254,19) and that's also what gets saved in the tif charts. What does that get printed as? On my 9500 it comes out Lab (70,-59,58) and that obviously is nothing anywhere close to what gets printed with a RGB(0,255,0) patch in sRGB using color management or not.
What gets printed isn't what the target is, what color space is assumed; the crux of the experiment. To answer the OP's question above (and below).
-
All I'm concerned with at this point is the RGB R0/G255/B0 you added and what (if any?) Lab values you got. Why do the last group (101-120) in bold, show Lab values?
What triplets did you add that presumably produced 101-120? Or did you not do this? If you did do so, there are lab values from RGB triplets. Again, how did those Lab values get generated?
I added triplets RGB(0,255,0).
Have no idea. They do correspond to sRGB though. But what gets added to the pxf patch set isn't that or even anything close. It was RGB(100,254,19). Go figure.
As I said. It's a bug for I1Profiler to append Lab values to an RGB CGATs file but at least it didn't append them to the pxf file. And if you save the pxf file then reload it then save again as a CGATs file the last 20 patches are all (100,254,19) which gets put in the tif chart if you save the chart.
Where that number comes from? Who knows. It doesn't correspond to anything close to the original (0,255,0) in any colorspace. But given that I1Profiler created a buggy CGATs RGB file, I don't trust anything it's doing here.
This was on Windows 10 x64, If you (or anyone else) are interested in seeing if the same problem is on Macs, I can package up a set you (or anyone with I1Profiler) can use to duplicate these, um, peculiarities and post them in a zip file.
-
I added triplets RGB(0,255,0).
Ok, and you show Lab values from that in the last group from 100 on: 101-120?
Those Lab values define RGB(0,255,0) in sRGB. So let's make this simple: did i1P report that Lab value from the triplets you provided to it?
It doesn't correspond to anything close to the original (0,255,0) in any colorspace.
101-120 do, I'm still confused on what you did, what you reported. Again, where did 101-120 Lab values, that you bolded come from if not from the triplets RGB(0,255,0) you added?
-
Ok, and you show Lab values from that in the last group from 100 on: 101-120?
Those Lab values define RGB(0,255,0) in sRGB. So let's make this simple: did i1P report that Lab value from the triplets you provided to it?
No. As I said, the triplets' Lab values shown incorrectly in the CGATs file are not what was actually saved in the pxf file which is the default file format for saving RGB patches. What actually got saved was RGB(100,254,19). Strange eh?
101-120 do, I'm still confused on what you did, what you reported. Again, where did 101-120 Lab values, that you bolded come from if not from the triplets RGB(0,255,0) you added?
I just created a tif 8 bit image in sRGB, ProPhoto RGB and untagged. Then I used the extract patches from image option in I1Profiler to add them to the existing set of 100 "smart patches" which created them from the 9500II profile.
Then I saved the RGB patches in I1Profiler CGATs format. That's it.
-
There's nothing in the middle of an icc print profile. It relates real colors, i.e. L*a*b* values, to the corresponding rgb triplet required to duplicate that color on the printer. The image has an embedded profile that relates its rgb pixels to L*a*b* (going thru XYZ first) values. The CMS engine used by the application connects the image with the display and the printer.
There is one profile each for the image, display and printer, and none have to worry about the other. This is why talking about printing targets for multiple color spaces makes no sense, all we need to do is characterize the printer/paper combination by itself. One of the major benefits of icc profiles is their independence from each other, once we have characterized the image and each device the CMS takes care of the rest.
Richard Southworth
Without disrespect to the very complex math and the processing required (The math is not my forté) , what I understand of the basic concept is that the device specific colors are converted to xyz and/or Lab at runtime using tables in the icc profile , thus allowing to unambiguously connect a color in one device to a color in another device with the same visual appearance provided it is within the gamut of the receiving device.
So in a very short explanation : the xyz and/or Lab is the color space ‘in the middle’.
-
You have it correctly stated, I was quibbling with your statement that the connection space was in the middle of the profile. The rgb values of the image are translated via its embedded profile (or implied/default profile) to XYZ real colors. These are fed to the application's CMS (Color Management System) outside of the profile, which performs the conversion to L*a*b* values, a one to one relationship. The L*a*b* values are in turn fed to the printer/paper profile and are translated to the appropriate rgb values to drive the printer.
There is some other magic going on in the "middle", including a white point shift - to me the math of this process is fascinating, if you want to dig in go to BruceLindbloom.com for the relevant formulas.
Ok, enough preaching,
Richard Southworth
-
Hi Richard, yes what is really going on is way more complex than my very simplified statement, luckily some guys are very good in making these complexities work for us.
-
Without disrespect to the very complex math and the processing required (The math is not my forté) , what I understand of the basic concept is that the device specific colors are converted to xyz and/or Lab at runtime using tables in the icc profile , thus allowing to unambiguously connect a color in one device to a color in another device with the same visual appearance provided it is within the gamut of the receiving device.
So in a very short explanation : the xyz and/or Lab is the color space ‘in the middle’.
Right. This is what happens. There are two intermediate colorspaces in ICC profiles PCSLAB and XYZ. Conversion to/from these intermediate spaces are done by the color management engine (CME). There are some limits to PCSLAB. Specifically, Adobe RGB green (0,255,0) produces a Lab value that is outside of PCSLAB as it results in an a* of -129 and gets clipped to -128 which is the PCSLAB limit.
When an image to be printed is in an RGB colorspace like ProPhoto RGB the values are first converted to XYZ by the CME by the ProPhoto RGB profile. What happens next depends on the whether the printer profile uses PCSLAB or XYZ as the intermediate colorspace. A few use XYZ but most use PCSLAB. I1Profiler only produces PCSLAB profiles so lets look at what happens with the printer PCSLAB profile for an RGB printer. First the 3 LAB channels may go through a reshaping stage which are 1D LUTs then they go through 3DLUTs the output of which may also go through 1D LUTs and the result is the RGB that will be sent to the printer driver.
Image files that are in Lab colorspace skip the first step since they are already in Lab.
There are multiple tables used by the CME for each of the colorspace conversions, Relative, Perceptual, Saturation and Absolute. Only Relative and Absolute are well defined by the ICC specification though in early days there was ambiguity around some areas, especially how black point was handled. The ICC tightened up the specs almost 20 years ago but OEM printer profiles still vary in how well they are followed. There are also issues with CMEs. Specifically Microsoft's which uses the CIE definition for Absolute Colorimetric while the ICC deviates from the CIE and requires adaptation to D50 of colorspaces like sRGB and Adobe RGB which assume a D65 whitepoint.
-
So what is the bottom line on OP's original question - couldn't quite follow what was going on with Doug's testing - way beyond my capacity.
-
So what is the bottom line on OP's original question - couldn't quite follow what was going on with Doug's testing - way beyond my capacity.
The bottom line is, if you have RGB data, it's in an RGB color space; whatever you assign to that color space. RGB isn't device independent.
-
No. As I said, the triplets' Lab values shown incorrectly in the CGATs file are not what was actually saved in the pxf file which is the default file format for saving RGB patches. What actually got saved was RGB(100,254,19). Strange eh?
I just created a tif 8 bit image in sRGB, ProPhoto RGB and untagged. Then I used the extract patches from image option in I1Profiler to add them to the existing set of 100 "smart patches" which created them from the 9500II profile.
Then I saved the RGB patches in I1Profiler CGATs format. That's it.
This is really simple.
Here's what I did first by creating three TIFFs in Photoshop (3x3 pixels):
1. sRGB with triplets 0/255/0
2. ProPhoto RGB with triplets 0/255/0
3. ProPhoto RGB with the same triplets but saved untagged.
Go into Optimization, load each one (one at a time) as seen below in screen capture.
Click Save button, save as CGATs txt file.
ALL THREE text files show Lab values. All three have identical Lab values.
The product of course examines the RGB triplets and assumes sRGB. Same Lab values, all convert back to sRGB with the triplets of 0/255/0 (in PS, 88/-79/81).
Conclusion: The product absolutely examines RGB values to convert to Lab. In doing so, it assumes an sRGB color space for any import to BUILD A TARGET. That could be considered a bug but the facts are, RGB is examined, a color space is assumed and used to produce Lab values in CGATs file. And target.
Back to the question and what I believe is the incorrect answer:
Q: I assume that a profiling chart has an implied colour space?
A: No, it does not.
IT does assume an implied color space of sRGB right? My tests indicates to me it does. RGB in, Lab out.
-
This is really simple.
Here's what I did first by creating three TIFFs in Photoshop (3x3 pixels):
1. sRGB with triplets 0/255/0
2. ProPhoto RGB with triplets 0/255/0
3. ProPhoto RGB with the same triplets but saved untagged.
Go into Optimization, load each one (one at a time) as seen below in screen capture.
Click Save button, save as CGATs txt file.
ALL THREE text files show Lab values. All three have identical Lab values.
The product of course examines the RGB triplets and assumes sRGB. Same Lab values, all convert back to sRGB with the triplets of 0/255/0 (in PS, 88/-79/81).
Conclusion: The product absolutely examines RGB values to convert to Lab. In doing so, it assumes an sRGB color space for any import to BUILD A TARGET. That could be considered a bug but the facts are, RGB is examined, a color space is assumed and used to produce Lab values in CGATs file. And target.
Partially correct. The image that colors are extracted from to improve the printed color accuracy is clearly assumed, by I1Profiler, to be in sRGB. Since the majority of prints are, in fact, from sRGB picture images this makes some sense. After all, what is desired is to create patches, when printed, that are nearer the colors in the image. A better approach would have converted colors from whatever colorspace the image was actually in and not just assume sRGB. It's not ideal but it isn't bad.
Those colors in Lab that correspond to sRGB (0,255,0) are intermediate values in the processing of the added image colors. They are simply the Lab equivalent of sRGB(0,255,0). They were added to the end of the CGATs file by error before processing was finished and are not what is actually used to make the profile. What is added to the patch set that I1Profiler uses (it isn't the CGATs file) differs a lot which can be seen by saving the patch set in default format (pfx) and looking at it with a text editor or examining the printable target tif image pixel values.
If you examine the last entries in the pfx file, or added green patches in the target tif file, you will find that it consists of patches which have RGB values that, when printed without color management, correspond with what gets printed when the sRGB(0,255,0) is printed using color management. The actual patch values in the pxf and tif target image, will vary with printers.
On to bigger questions. How well does adding colors taken from a picture image really work?
Next, I took a look at how well the addition of 20 patches of colors I wish to optimize from an image worked. Also decided to see how badly the same colors extracted from a ProPhoto tagged image were since they were interpreted as sRGB.
So I made 4 profiles based on the Pro1000. First was a standard profile with minimal chart size of 518 (8x8x8 grid) with 6 solid colors appended. This was made with the patch generator. Next I made an optimized profile with 100 additional patches generated from the "smart patch generator" on the optimize profile option. This made a total set of 618 patches. Then finally I made to profiles, each with added skin colors. These were made stepping Lab with L* from 65 to 75, a* from 15 to 25, and b* from 15 to 25 which is a distribution of Caucasian skin colors. This produced 1331 pixels converted to sRGB and ProPhoto RGB and saved as tif files. Each of these were added to create profiles optimized for these skin colors.
To avoid I1Profiler's weird fractional problem all patch sets were saved as pxf patch files then immediately loaded back.
To measure how well these 4 profiles worked I ran all 1331 lab values of the skin tones through each of the 4 profiles and quantified how far off the Lab values were from the original
printer_518_patches: Mean:0.382, 1% worst:0.78 max:0.85
printer_618_patches: Mean:0.296, 1% worst:0.77 max:0.84
printer_638_sRGB: Mean:0.188, 1% worst:0.50 max:0.57
printer_638_ProPhoto:Mean:0.278, 1% worst:0.75 max:0.82
Results: The addition of 100 "optimized" patches improved the mean dE error from .382 to .296 but reduced the max error and worst 1% by only .01 in the skin tones.
The patch set that incorporated an additional 20 colors extracted from the sRGB skin tone tiff significantly improved the dE errors, reducing the average error to .188 and the worst 1% and max errors to .50 and .57 respectively. That's impressive for only adding 20 more patches.
However, the ProPhoto tagged tif file with the same Lab values, reduced the average skin tone error by less than .02 and the worst cases were only .02 better than the 618 patch set. This is consistent with my expectations that the patches selected from the ProPhoto skin image were so far off when the ProPhoto tag was ignored that it provided little improvement.
Takeaway. If you want to optimize I1Profiler from images that you intend to print but aren't in sRGB, convert a copy to sRGB before adding it to the optimize profile using "Extract patches from image"
-
Partially correct.
This is the correct part I'm concerned with since you started all this stuff about:"no, it does not" and outlined below: YES it does.
Numbers assumed to be in sRGB were entered to make a target. The product provided a conversion to Lab using that sRGB assumption. So 'No, it does not" has been disproven:
Q: I assume that a profiling chart has an implied colour space?
A: No, it does not.
Correct answer: Yes, this one product does.
If you want to go further down a different path about the product fine.
On to bigger questions. How well does adding colors taken from a picture image really work?
Bigger, perhaps. Different indeed. But perhaps you want to start a new thread about this new topic.
The topic here, the title is clear: What RGB colorspace is used when printing a non colormanaged profiling chart?
I will only answer based upon i1Profiler: sRGB. You can accept the testing or not, but I don't see how the answer based upon the RGB triplets imported, and the Lab values extracted from the target can provide another answer, it certainly isn't "no, it doesn't" (assume) some RGB color space.
Takeaway. If you want to optimize I1Profiler from images that you intend to print but aren't in sRGB, convert a copy to sRGB before adding it to the optimize profile using "Extract patches from image"
My take away, the OP's I'd hope would be this: i1P assumes sRGB for RGB triplets.
-
I read through the full thread in an attempt to summarize the diverging conversations. Here's my take:
- Do RGB values in a standardprofile target chart have an implied color space? No. Chart RGB values are sent to the printer (or other output device), results measured, and a profile created from them. To avoid confusion, this only refers to an original test chart, not one made in the optimization workflow. As a test: create a minimal test chart (manually, not from within i1Profiler) containing 512 RGB patches in an 8x8x8 cube. Print, measure, create profile using i1P, Argyll, etc. Compare the colorimetric tables. Not identical, but close. There is no implied color space at this stage. We can go through the math if you wish, but a profiling application that assumes a reference RGB (or CMYK for that matter) colorspace for the reference data will necessarily be less accurate and unable to profile higher output gamut devices.
- What about i1Profiler optimization based on loading colors from an image? TL;DR: This feature is broken and almost guaranteed to screw up your profile.
Doug and Andrew showed that, at best, i1Profiler ignores the image colorspace and assumes the RGB pixels are sRGB. A huge problem is that the results vary based on what path you follow. "Optimized" colors (scare quotes because they are anything but) do not necessarily choose colors present in the image. I made a 17 step neutral gradient (points spaced every 16 RGB steps apart) from black to white. None of the 17 colors i1Profiler picked were neutral and the last 9 colors were identical. Echoing the findings above, the generated test charts were identical no matter what colorspace the image had. Now things got weird. If I simply proceeded through the i1Profiler workflow - not saving targets or reference files - the profile reference data were all as Doug details when saving as CGATS: Colors were converted to LAB, but interpreted as RGB; i.e. the L value was used as a Red reference, a as Green, and b as Blue. The reference color i1Profiler displayed on screen, however, is an sRGB interpretation of the LAB color. That made for one messed up profile. Saving the reference patches in pxf format, loading this back into i1Profiler, and the measuring gave correct(ish) RGB reference values. Given that the patches were not chosen well and colors repeated, the effect on the profile was minimal at best.
- Can the image optimization be coaxed to work? TL;DR Not without effort, and even so, it does not make much difference.
I then emulated Doug's latest experiment by adding skin tone patches to a test chart. We have a set of 100 spectral measurements of actual people. Aside: You can only imagine the looks one gets approaching people in a packed international bar asking if you can measure the color of their skin. Led to interesting conversations over the course of a couple evenings. I added the maximum 30 patches to an existing profile using an i1Profiler extract of an sRGB image, saving into pxf format first to avoid the LAB/RGB errors above.
Mathematical accuracy of the profiles on the skin tones alone was unchanged. Mean dE00 0.176 without optimization, 0.0172 with. Worst 10% degraded from 0.810 to 0.821. Prints made on the actual printer in question showed no visual differences.
Next, I manually added the sRGB values of all 100 patches to the profile target and reference file. There were definite changes, but not in a good way. Mean dE00 of the skin tones dropped from 0.176 to 0.091. Pretty good, except the worst 10% skyrocketed by 4x to 3.219. Visual comparison of the prints showed banding and color reversal artifacts with the profile. I do not know whether the tricks we used 15+ years ago with ProfileMaker to cope with added patches works with i1Profiler. That's not a task I want to revisit.
-
- Can the image optimization be coaxed to work? TL;DR Not without effort, and even so, it does not make much difference.
I then emulated Doug's latest experiment by adding skin tone patches to a test chart. We have a set of 100 spectral measurements of actual people. Aside: You can only imagine the looks one gets approaching people in a packed international bar asking if you can measure the color of their skin. Led to interesting conversations over the course of a couple evenings. I added the maximum 30 patches to an existing profile using an i1Profiler extract of an sRGB image, saving into pxf format first to avoid the LAB/RGB errors above.
My experience building hundreds of profiles, with i1P optimization, with my custom optimization target: The optimization either does nothing (visible) or can produce very slight improvements. I never know when or why so I just always offer this as an option to my customers if they are OK printing and sending me three more 8x11 pages (my custom optimization target has 2368 patches, it's not much work to measure with an iSis XL). 8 times out of ten, and I always compare soft proofs alone, there is no visual difference between the original and optimized profile. I make this clear to customers and it is totally up to them if they wish to follow this secondary path.
-
I made a 17 step neutral gradient (points spaced every 16 RGB steps apart) from black to white. None of the 17 colors i1Profiler picked were neutral and the last 9 colors were identical.
I see a similar small number of patches chosen that Ethan observed. My tif image had 1331 pixels with lab values centered on Lab(70,20,20) with +/- 5 in unit steps around it. 8 of the 20 differ with the last 12 being a repeat of the last for the sRGB tif file. They were generally in or near the set. The ProPhoto tif file extracted a different set as expected since it ignores the tif file colorspace tag. They were more desaturated and much further from the Lab set and were only 6 before they started repeating.
Here's samples, RGB then Lab, from the end of the first 100 "smart" patches to where the additional 20 image colors started repeating. The ProPhoto RGB skin tone patches are simply placed in the wrong spots to optimize those colors.
From sRGB skin tone image extract
98 173.00 186.00 210.00 75.91 1.00 -10.17
99 214.00 225.00 245.00 88.01 1.19 -10.94
100 240.00 251.00 255.00 97.51 -1.10 -4.49
101 199.00 156.00 149.00 72.77 10.86 18.23
102 204.00 147.00 156.00 72.33 16.46 15.31
103 213.00 154.00 152.00 74.78 15.75 20.24
104 195.00 147.00 134.00 70.18 12.30 22.29
105 195.00 136.00 138.00 68.19 17.36 19.13
106 202.00 157.00 160.00 73.76 12.28 14.27
107 185.00 144.00 134.00 67.89 10.65 18.90
108 187.00 138.00 146.00 67.43 14.91 13.59
109 187.00 138.00 146.00 67.43 14.91 13.59
110 187.00 138.00 146.00 67.43 14.91 13.59
From ProPhoto RGB skin tone image extract
98 173.00 186.00 210.00 75.91 1.00 -10.17
99 214.00 225.00 245.00 88.01 1.19 -10.94
100 240.00 251.00 255.00 97.51 -1.10 -4.49
101 163.00 146.00 127.00 64.34 3.37 16.23
102 180.00 159.00 146.00 69.60 4.19 14.30
103 151.00 132.00 122.00 59.65 5.64 12.48
104 145.00 138.00 106.00 59.99 0.34 19.21
105 180.00 168.00 135.00 70.55 -0.11 20.72
106 154.00 131.00 126.00 60.14 7.23 11.27
107 154.00 131.00 126.00 60.14 7.23 11.27
108 154.00 131.00 126.00 60.14 7.23 11.27
I like the idea of taking a look at the near neutrals. The Pro1000 has a strong hue shift in the first 25% of the device neutral axis and the 8x8x8 base grid doesn't track it very well.
BTW, my dEs stats are measured against a reference Argyll profile made from about 8000 patches. It gives pretty repeatable results against the I1Profiler since it had different algorithms and 3DLUT spacing. I was mainly using this to discover the weird anomalies that I1Profiler creates sometimes when RGB values are varied by tiny amounts as discussed on another thread. Easy to adapt to test the optimizer. Hard to believe how messed up it is. But then even on regular charts I1PRofiler has had the problem of truncating RGB values stored in their profiles while rounding the ones used to create or print the tif targets. About half the RGB values in the tif images are higher by one than in the pxf file or internal storage when created by their patch generator. Just throws in another smallish error that no one ever notices.
-
Ethan,
I see significant improvements from adding the 20 neutral patches from "Extract patches from image" in I1Profiler's optimize workflow. Not sure why you don't see any improvement but the added device space patches seem strategically placed to provide the profiling engine the information where there is significant neutral deviation from the 618 (518+100) profile which has the added 100 "smart patches."
I created a 16x16 tif file with neutral RGB values from 0 to 255. Instead of the flesh tones used previously, this image was used to extract an additional 20 RGB values that are in printer RGB colorspace from the 256 actual sRGB neutrals. The Lab values in printer device space have a range of L*s but the patches are all quite near neutral with a*=b*=0. The RGB values differ from each other as much as 13. This is consistent with the Pro1000 printing glossy.
Here's the first set of 11 patches added. The first 10 neutral patches differ before repeating to fill up the 20.
621 116.00 124.00 123.00 53.27 0.12 0.21
622 172.00 176.00 180.00 72.66 0.41 0.83
623 75.00 88.00 76.00 36.55 -0.68 -0.07
624 47.00 61.00 48.00 23.11 -0.05 -0.25
625 218.00 222.00 221.00 87.55 0.11 0.13
626 143.00 149.00 153.00 62.92 0.24 -0.09
627 196.00 201.00 203.00 80.18 -0.38 -0.26
628 95.00 106.00 100.00 45.33 -0.09 -0.66
629 232.00 235.00 233.00 92.61 0.51 0.50
630 54.00 67.00 55.00 25.97 -0.42 -0.89
631 54.00 67.00 55.00 25.97 -0.42 -0.89
This seems quite reasonable as the printer's a* and b* variation in RGBs is larger to track the neutral axis. The added neutrals significantly improved neutral performance across L* with a*=b*=0.
Mean dE over neutral L* in steps of 1.
printer_518_patches: Mean:0.7907
printer_618_patches: Mean:0.6406
printer_638_sRGB: Mean:0.4787
-
I read through the full thread in an attempt to summarize the diverging conversations. Here's my take:
- Do RGB values in a standardprofile target chart have an implied color space? No. Chart RGB values are sent to the printer (or other output device), results measured, and a profile created from them. To avoid confusion, this only refers to an original test chart, not one made in the optimization workflow. As a test: create a minimal test chart (manually, not from within i1Profiler) containing 512 RGB patches in an 8x8x8 cube. Print, measure, create profile using i1P, Argyll, etc. Compare the colorimetric tables. Not identical, but close. There is no implied color space at this stage. We can go through the math if you wish, but a profiling application that assumes a reference RGB (or CMYK for that matter) colorspace for the reference data will necessarily be less accurate and unable to profile higher output gamut devices.
The chart RGB values are sent to the output device unaltered in order to measure and charactarise the device, so another way of viewing it is that they do have an implied colour space: the colour space of the output device! The purpose of the exercise is to measure that colour space. However, I do understand your point.
-
So in my limited view:
When an image is sent into the print pipeline (driver-printer) without color management ( use of acpu or Drycreek f.i.) the print pipeline will use its rgb colorspace to transform and print the result. Thus in fact the combi of print pipeline and given paper.
This rgb colorspace of the print pipeline is a given. However I have a sneaky suspicion it is prophotorgb like.
Anyhow it seems to work.
-
Takeaway. If you want to optimize I1Profiler from images that you intend to print but aren't in sRGB, convert a copy to sRGB before adding it to the optimize profile using "Extract patches from image"
[/b]
I noticed that when I ask the apple app (apercu) to convert a srvb image to adobe rvb, it removes the exif tag from the colorimetric space.
When I do the same manipulation with photoshop, he left it but empty and it says: not calibrated…
try to change the tag (exiftools) and indicate the correct profile used in the image to see.
you use colorport x-rite to, for spot colour ?
-
I noticed that when I ask the apple app (apercu) to convert a srvb image to adobe rvb, it removes the exif tag from the colorimetric space.
When I do the same manipulation with photoshop, he left it but empty and it says: not calibrated…
try to change the tag and indicate the correct profile used in the image to see
??? Cannot understand what you are trying to say. Please clarify.
-
When using photoshop even when not starting with a photo, he leaves the exif data tag blank what becomes: uncalibrated instead of deleting it.
example :
1 - picture converted by photoshop to adobe rvb
2 - picture converted by apercu to adobe rvb
3- original picture in Srvb
-
So in my limited view:
When an image is sent into the print pipeline (driver-printer) without color management ( use of acpu or Drycreek f.i.) the print pipeline will use its rgb colorspace to transform and print the result. Thus in fact the combi of print pipeline and given paper.
This rgb colorspace of the print pipeline is a given. However I have a sneaky suspicion it is prophotorgb like.
Anyhow it seems to work.
You are correct that underlying assumptions are made about interpreting RGB color values. Most printers use some combination of inks, CMYK or multicolor, to create the actual print. The printer driver creates a mix of output depending on the received color values and applicable media settings. Cruder printers paired with a capable RIP do allow a one-to-one matching of input color value (CMYK or multicolor again) with output. More modern printers, however, vary dot size, spacing, and density in a way that you cannot control directly.
Sending RGB input to a printer with different outputs obviously involves a conversion. Whether there is an actual inferred color space, I can't say. The only printer driver implementation we have insight to is covered under NDA. As an example, however, if you print the same RGB input values directly to a Canon or Epson inkjet, you will obtain varying results depending on the media setting used. Look at the print under a loupe and you will see that not only does total and per channel ink limiting change, but so does drop size - by a factor of 15 in the case of Epsons.
The key point is that the process is consistent - as long as you prevent unwanted color management from occurring.