Peter,
It does seem to make sense. You define a space with a narrower gamut than sRGB and then convert to the narrow profile from ProPhotoRGB, clipping out of gamut colors. Then back to ProPhotoRGB and use opacity to effectively interpolate with the original image before converting to sRGB.
Hi Bill,
Thanks a lot for your interest and for this concise summary! I’m sorry for my late response (was out of the town yesterday); however, let me take the opportunity to outline some considerations more detailed:
The procedure as described above aims for a core/shell-structure with a solid core of unaltered colors and a compression range (in-between the narrower gamut and sRGB) which is intended to provide a smoother transition to the remaining (clipped) colors on the surface of sRGB.
This, sooner or later raises the question if channel clipping due to RelCol is inevitably something bad. Above procedure in a modified, more extreme implementation can virtually squeeze a whole Granger Rainbow from ProPhoto RGB into sRGB, thus, avoiding channel clipping largely. But I could not find an example in practice where this makes a better image.
I think it’s a coin with two sides. Channel clipping of saturated colors due to gamut conversion indicates a loss of data-bits & information which can result in posterization and a missing fine structure. On the other side, in case that all out-of-sRGB pixels would be randomly distributed throughout the whole pRGB image (as opposed to clustered), channel clipping after conversion would just indicate a best possible use of the tiny gamut.
Further, given that two neighboring colors which both are clipped are not necessarily undistinguishable; real-world images probably more require an in-between approach (rather than an eliminate-clipping imperative).
Coming from ACR, it can make some sense to maintain ProPhoto RGB for final image editing (made my peace with it). A considerable part of my images contains more or less colors which are clearly located out-of-sRGB. Converting them to sRGB, plain RelCol seems to work fine in many cases. In essence, it’s an artistic decision to maintain a highest possible level of saturation at the cost of some channel clipping and even in case that some few details are ironed out at 400% magnification.
However, sometimes it gets too much; e.g. with very saturated flowers. That’s the intended field of application for above suggested procedure. But as we had a very long winter here in Europe (no flowers at all) it’s still more on a beta level. For example, it could make sense to add a hue-lock in order to avoid respective shifts resulting from CIE Lab as the profile connection space… Of course, I’d be glad if a dedicated cognoscenti would take up the subject.
Couldn't you also use soft proofing also with ProPhotoRGB? Set the device to simulate to sRGB in the custom setup, show out of gamut colors, and then reduce the saturation until in gamut, and then convert from ProPhotoRGB to sRGB. I have some red flowers in ProPhotoRGB that are much out of gamut in sRGB and used the above method and noted that the maximum in the red channel of the converted file was near 255. The converted file looked pretty dull on screen, however.
As far as I can tell, a global reduction of saturation bears three main risks. In 3D it can be understood as a squeezing of the whole de-facto gamut as occupied by the image colors. (1.) Possible in-sRGB colors are moved which could have been left where they are. (2.) pRGB colors which are just slightly out-of-sRGB are easily moved too far inside; there’s no threshold. (3.) Perceived lightness can be affected depending on the definition for saturation used.
Point number 1 can likely be solved e.g. by a selection of out-of-gamut colors via the Color Range tool. Maybe combined with a Hue/Sat.-layer in Saturation blend mode - this then also counteracts point number 3. Or, it could make sense first to convert to Lab mode (for a stopover) where the Saturation slider of the Hue/Sat.-tool works differently (L* is preserved in Normal blend mode; no Saturation blend mode required).
But I think that point no. 2 is a persistent one. It finally imposes the burden to balance ‘more details vs less saturation’ on a visual basis; because out-of-gamut-marks alone can be a bad advisor (see above discussion). The next problem is to handle this within a monitor’s limited gamut…
Finally I see a certain risk with this approach, to make things worse than better (‘file looked pretty dull’), but this shall not say that it couldn’t work well.
In summary, I tend to conclude that the whole issue of ‘ProPhoto RGB conversion to smaller matrix spaces’ is more pronounced in theory than in practice; depending on the photographic subject of course. So for such cases it would be quite nice to have a ready developed procedure and commonly agreed state of the art approach / Action which does the trick (unless I’m missing something which already exists).
Peter
--