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

[Doug Gray]

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.

[JRSmit]

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?

[JRSmit]

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.

[rasworth]

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

[Doug Gray]

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.

[Lessbones]

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)

[JRSmit]

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.

[digitaldog]

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?

[digitaldog]

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

[unesco]

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

[nirpat89]

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?

[digitaldog]

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.

[nirpat89]

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. 

[JRSmit]

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.

[JRSmit]

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.

[rasworth]

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

[Doug Gray]

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

[digitaldog]

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?

[Doug Gray]

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.

[digitaldog]

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?