a) It doesn't limit any gamuts because there is no gamut. All a profiling target is made up of are many RGB numbers being sent directly to the printer (e.g. 0,0,0 1,1,1 etc) or CMYK, etc.
b) There are no gamuts at all at this stage in the profile creation process. To have a gamut, there needs to be some sort of device-independant measurements and as explained in part a) there are only RGB commands being sent to the printer, no Lab or XYZ involved, therefore there are no gamuts involved either.
c) A null-transform, which is what is happening, means that in effect, nothing is happening at all as one profile essentially cancels out the other, so any profile could be used.
When you assign sRGB to an image in PS, it just changes the way it looks, it doesn't change the image RGB numbers - I understand that.
However, when you go to print the profiling target, and if you select sRGB as the print profile, PS is converting the image to sRGB on the fly as it is sent to the printer. This is exactly what happens when you send a normal print job to print, and select your paper profile - PS is converting the image to the profile RGB numbers as it is sent to the printer.
It doesn't matter since the sRGB (or any) profile was assigned at the beggining, the conversion part at the print stage completes the null-transform, hence no RGB values are actually changed.
I've never personally checked the actual numbers going in & out but I've never needed to as I've used this method many times & never had any strange or unusual outcomes. The null-transform is a well known method to overcome this problem in Ps CS5 & even X-Rite themselves have recommended this method for a number of years, since CS4, as you can see in this PDF:
(from Luminous Landscape)
For those of you wondering about the technical explanation of what is happening, here it is :
Advanced users who wish to build their own custom profiles (or have custom profiles made via a service) need to print untagged profile target images. Conceptually, the pixel values in these target images need to pass unmodified from the printing application (e.g., Photoshop) to the printer driver. There should not be any type of color transformation applied to the profile target image. So far, so good.
However, when printing from Photoshop CS4 in â€œNo Color Managementâ€ mode on Leopard (10.5) or Snow Leopard (10.6) to a recent Epson driver, the OS appears to be applying a color transformation (via ColorSync) to the profile target image data before handing it off to the printer driver. Specifically, the OS is converting the image pixel values from the Media Type-specific profile to sRGB. For example, if you are using an Epson Stylus Pro 3800 and have set the Media Type in the driver set to Premium Luster, then the default profile â€œPro38 PLPPâ€ will be shown in the â€œAdvanced Color Settingsâ€ of the driver. ColorSync then performs a conversion of the target image data from Pro38 PLPP.icc to sRGB, then hands the result off to the driver. The result is a bogus target print. Regrettably, it is not entirely clear at this time what is triggering the conversion.
In the meantime, the workaround described above allows profile targets to be printed, regardless of OS version or driver version.
Effectively, the workaround does this:
â€“ tag the (previously untagged) target image with a profile; doing so doesnâ€™t change the pixel values,
â€“ ask Photoshop during print to perform a conversion to the same profile (e.g., Adobe RGB to Adobe RGB), which effectively does nothing (i.e., null transform), since the source and destination profile are the same, and
â€“ tells the OS not to perform any additional conversion, since the application (Photoshop) already handled the color transform; the OS then hands off the Adobe RGB-tagged image as-is to the driver, with no modification
The end result is that the profile target image pixel values go straight through the system with no change, which is what weâ€™ve been trying to achieve all along. This is why it does not matter whether you choose Adobe RGB, ProPhoto RGB, etc. for this workaround. The central idea is to (1) cause Photoshop to avoid doing a color transform (implemented by making sure the source and destination profiles are the same), and (2) to convince the OS that the data being provided by the app has already been color transformed, and hence the OS wonâ€™t interfere.
Thanks aaron125 for you two citations above. It always helps to have those. So it would appear that Photoshop does no color space conversions if the file is already tagged as the same as the printing profile selected. Very clever.
It's not just a Photoshop thing, as the same process is used at the OS level with Mac ColorSync, so I'm not sure but I think it may be a process at the ICC-compliant colour management engine level - but that's just a guess, don't take my word for it.
Found this in my copy of Bruce Fraser's Real World Color Management (2nd Ed.), dating back to 2005. Looked up null transform in the index at the back of the book & it has the following in the glossary on p.547 as a definition for null transform:
quote RWCM p.547 null transform
When the source profile and destination profiles are the same, CMMs ensure no conversion occurs.
(Bold/italics from book, not my editing)
My copy of RWCM is 1st ed, and doesn't even have 547pp
I think I may have a PDF copy of the 2nd Ed. around here somewhere, I'll have a look for you. Sorry, got every other Real World, but not the one we're after.
that'd be great if you could post a link...
OK, got it for ya mate. I just checked & it seems to be the same as my printed version. Haven't checked by getting the book & comparing but scrolled through the PDF & it looks all the same. Enjoy!