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

[digitaldog]

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

[Doug Gray]

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.

[digitaldog]

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?

[Doug Gray]

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.

[JRSmit]

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’.

[rasworth]

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

[JRSmit]

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.

[Doug Gray]

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.

[nirpat89]

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.

[digitaldog]

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.

[digitaldog]

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.

[Doug Gray]

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"

[digitaldog]

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.

[Ethan Hansen]

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.

[digitaldog]

• 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.

[Doug Gray]

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.

[Doug Gray]

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

[simon.garrett@iee.org]

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.

[JRSmit]

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.

[belnea]

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 ?