I can't promise this will work, but if in Photoshop you do a convert-to-profile from Adobe RGB to the lab's ICC printing profile using perceptual rendering intent, and then convert back to Adobe RGB, that may squeeze the colors like you want in the first operation while keeping them all within the printable gamut in the second.
May not do what you expect. Look for the white paper: "Perceptual Rendering Intent Use Case Issues" on the color.org ICC website.
The latest V2 ICC profiles are subset compliant with V4. V4 compliant profiles require that a Perceptual transform from PCS to device that is then transformed from device back to PCS should reconstruct the original. From my testing this is valid for V2 profiles created by i1profiler but the accuracy deteriorates the more the original colors exceed the printer's gamut.
This is an interesting point you raised, and I'm really bumping up against the limits of my understanding, so I'm sorry is what follows is clueless. But:
If you have an image in Adobe RGB with some colors outside the gamut of the desired ICC printing profile, and in Photoshop you perform a 'convert to profile' from Adobe RGB to the printing profile using perceptual rendering intent, presumably if you then do another convert-to-profile back to Adobe RGB, the only way that any software or profile could know to do a 'reverse transform' would be that Photoshop itself stores a list of what it's done. I wouldn't think that the image data itself would contain a flag indicating 'I was converted from Adobe RGB to this printing profile' much less data on how much 'perceptual squeeze' was performed to fill all the source gamut into the target gamut. If
I'm correct on these suppositions, then presumably at worst you convert from Adobe RGB to the printing profile using perceptual, export that as a 16-bit TIFF (now encoded in the printing profile), exit Photoshop, re-launch Photoshop, open the TIFF you just exported, and do a convert-to-profile to Adobe RGB (with the rendering intent for this second conversion probably irrelevant). At that point your image should be encoded in the standard Adobe RGB,
but all of its colors should be within the printable gamut as defined by the ICC printing profile. If this is not correct, I fail to see why (which doesn't mean I'm right).
I found Photoshop's conversion dialogs clear when converting from a standard colorspace to the printer's RGB device space but confusing when converting from the printer's RGB device space to a standard colorspace. Intuitively, selecting conversion Intent would apply to the target, not the source. But that isn't actually the case when the source is a printer device space. The conversion intent selections actually only apply to the source or printer's device color space.
This can be more intuitive if the image starts off in Lab. Converting to printer space uses the Intent settings to apply the proper profile tables to the Lab values producing printer RGB values. When converting back to Lab, the source printer profile is selected and the target is set to Lab. The Intent settings in the dialog are actually applied to the printer profile going in reverse to convert to Lab even though the dialog implies the Intent settings apply to the target. But when the source is a printer profile, they don't. It can be quite confusing/strange but that's the way Photoshop works.
So Photoshop doesn't need to know what the image was previously in or what conversion intent was applied.
When you convert with Photoshop using Perceptual you first go from the image colorspace to the ICC PCS which is sometimes called icclab. It's the same as CIELAB except that the a* and b* are limited to +- 128 so anything larger is clipped at that point. A great part of ProPhoto RGB gets clipped and even pure green in Adobe gets clipped as a* goes just beyond -128.
Once in PCSLAB, say from Adobe RGB, the ICC table BtoA0 gets used to convert to device RGB. That's whats get saved. When you convert back to Adobe RGB and also select Perceptual, the inversion table, AtoB0, gets used. The '0' in both indicates it's the Perceptual table. This turns device RGB into PCSLAB and from there it's transformed to Adobe RGB. The process of going to/from PCSLAB and Adobe RGB doesn't use Intent and is accurate except for the a*,b* clipping of course.
However, the AtoB0/BtoA0 tables really only compress/decompress a relatively short distance beyond the printer's gamut in spite of the ICC's desire. So if the original image has colors well outside the printer's gamut they will not be accurately recovered. I did some testing of this years ago and found things deteriorate quickly once the colors were around 10 dE beyond the printer's gamut. At 20 it was hopeless. So the ICC's aspirational goal of complete Perceptual invertability fails badly with synthetic images in ProPhoto RGB like Bill's Balls.
I ran a quick test, and it indicates that, even with v. 4 ICC profiles, my original suggestion to the OP (at
https://www.dpreview.com/forums/post/66214493) should work. I performed the test in Affinity Photo 1.10.5, and the results are presented in ProPhoto RGB and an ICC printing profile, so this will probably not look right if the viewer's browser is not color managed. First I selected what I believed to be a version 4 ICC profile--Canson Platine in the Canon Pro-100 (cifa_pixmapro100_platine310.icc)--and used
ICC View to confirm that it is indeed a v. 4 profile (if you try to upload it, it says failed because v. 4 profiles are unsupported). I took Andrew "Digital Dog" Rodney's gamut test file, which he makes available (at
http://www.digitaldog.net/tips-and-tricks.html) for downloading as a 16-bit TIFF in ProPhoto RGB, and exported it as a maximum-quality JPEG, still in ProPhoto RGB:
Then I performed a Document -> Convert Format / ICC Profile... and converted the gamut test from ProPhoto RGB to the Canson printing profile using perceptual rendering intent and black point compensation. I exported that as a maximum-quality JPEG encoded in the Canson printing profile:
Then I performed a second convert to profile, converting the image back from the Canson printing profile to ProPhoto RGB, and exported that as a maximum-quality JPEG in ProPhoto RGB
As you can see, it did
not restore the saturation.
I'm not saying there are
no differences between the second and third JPEGs; there appear to be relatively subtle differences. As previously discussed, the conversion process induces some errors, usually modest. Maybe other factors are having an effect.
But if you have to submit a file for printing in a color working space like sRGB, Adobe RGB, or ProPhoto RGB, and you want to control the rendering intent used for the conversion of your image to the printing profile, I
still think that you can do a convert-to-profile to the printing profile--using the rendering intent of your choice and black point compensation or not, again your choice--and a second convert-to-profile back to the color working space, that
should prevent further compression or clipping in the printing service's process of printing.
