Advice on how to manage color spaces from raw to print

[Robert Ardill]

Hi,

I've been struggling for some time with the whole question of how best to prevent conversion problems (for example clipping of colours, shifting of hues) in the process of going from a raw image in Lightroom through Photoshop and to my printer.

So far I've tended to do the following:
- In Lightroom I turn on soft-proofing for my paper (usually Relative Colorimetric) with the gamut warning on to try to stay within the printer gamut
- In Photoshop I work in Adobe RGB mostly as it's not too far from my paper gamut (and also my monitor gamut)
- Again, I turn on the gamut warning in Photoshop
- I try to keep the colors within gamut as I make further edits to the image
- If I find that colors are out of gamut I use various techniques to select the out-of-gamut pixels and bring them back into gamut (but only if the soft-proofing shows any flatness or bad colors in these areas - if not I'll let the CMM do the correction).

All of which is fiddly and time-consuming, so that if I'm in a hurry I often take shortcuts and hope that the color management will do a reasonable job on its own (which I find is usually fine for images with low saturation but risky for ones that are quite saturated).

I've recently wondered why not do the following:
- In Lightroom turn on soft-proofing for my paper with the gamut warning on to try to stay within the paper gamut, as before
- In Photoshop: open the image in ProPhoto (to avoid any color space conversion from the Lightroom color space) and then immediately do a conversion to the printer profile (Relative or Perceptual as appropriate)
- Edit with the paper profile as the working space (that way I can't inadvertently stray outside the paper gamut)
- Save/Print (in other words embed the paper profile in the document, don't convert back to ProPhoto).

It's an awful lot easier and quicker and the editing is much more flexible because there is no need to worry about the paper gamut - the only downside that I can see is that the image is then only tuned for this particular printer/paper (which doesn't bother me too much as I mostly develop images for specific papers).

Am I missing something? Is there a fundamental reason why one should not use the printer profile as the working space?

Thanks!

Robert

[digitaldog]

The OOG overlay is buggy (no accurate) and not all that useful. Ignore it. Pick the rendering intent you prefer (soft proof), convert the data. Soft proofing will allow you to pick the most pleasing rendering intent and simulate (with paper and ink black) how the image will change on that media, you can edit a tad to get back to the original appearance. Usually a slight curve or two, a tad of saturation or vibrance and that's about as close as you'll get to the 'before' preview with soft proof off. That's about it.

Is there a fundamental reason why one should not use the printer profile as the working space?

Oh yes! It's only appropriate for that output. If you need to print to other devices, you're kind of screwed being in the wrong output color space. RGB working spaces are output agnostic. LR is the best place to do this work because:

It's soft proof surround is better.
You can do output specific edits as I described on a virtual copy (proof copy).
The RI you pick should honored in Print Module which is nice.

[Robert Ardill]

Thanks for your reply Rodney!

Yes, I can see why using the output profile as the working space means that the image is now 'burnt' to this printer/paper combination (which of course could be a nuisance at a later time if I want to print the same image with a different paper or printer).  But is there any other reason that you can see why it's wrong to do so?

I'll tell why I find this an attractive workflow for problematic images (for ones that are close to gamut there would be no need):

• If I develop in Lightroom to get the look I want, I then find that the image goes well out-of-gamut and bringing it back close to gamut messes up the effect I want. I think the Lightroom working space is so huge that it's really easy for this to happen.
• Opening and editing the image in Photoshop in ProPhoto has the same problem: it's very difficult to keep the image in gamut and still get the effect desired.
• Opening and editing the image in Photoshop in Adobe RGB is an improvement because Adobe RGB isn't too far off my monitor and paper gamuts - however the image gets clipped going from Lightroom to Photoshop, so already some damage has been done.

Doing it the other way (final edits in the paper color space):

• I make sure the image is well in gamut in Lightroom for my paper, so I'm not attempting any more than an initial edit to get the basics of the image right.
  
• There is no damage done to the image when I bring it into Photoshop because I use ProPhoto
• When I convert to the destination color space there is only limited damage done because the image is within the gamut of the output profile (this damage would presumably happen on printing anyway)
• I can then quite freely edit in Photoshop without concern for going out of gamut
• I can turn on soft-proofing with simulate paper color (and go to full-screen mode, which I can't do in Lightroom as it turns off softproofing in full-screen mode) to do any further tweaks

I have checked what appears to happen to a spot when the (fully in-gamut) image is converted using Relative and there is certainly a color shift (which seems to be corrected when the image is converted back to ProPhoto).  The same seems to happen with Perceptual, although the return to ProPhoto doesn't give quite the same color as the original (I had read that a Perceptual rendering is not destructive and that the reverse transform should bring the image back to the original, but that doesn't seem to be the case, at least with this profile (made with ArgyllCMS)).

So it would seem that converting to the destination color space is pretty much a one-way trip.

But I still don't see that there is anything fundamentally wrong with this approach providing one realizes that it's effectively burning the image to the printer/paper/profile ... but I'm concerned that I'm missing something fundamental (rather than only going outside of recommended best-practice).

Robert

[Schewe]

So I still don't see that there is anything fundamentally wrong with this approach ... but I'm concerned that I'm missing something fundamental (rather than only going outside of recommended best-practice).

The main reason why it's a really bad idea to use the output profile as an editing working space is that Photoshop (and any editing software) is presuming that the "working space" has the ability to have a neutral editing space when dealing with middle grey...normal editing spaces such as Adobe RGB, ProPhoto RGB and even sRGB all share the same neutral consistency of having equal numbers of RGB being neutral. The same can't be said of output profiles (nor input profiles).

Can you edit in an output space? Yes...is it a good idea? Not so much.

You seem to be trying to make thing much more complicated that needed. If you want to keep from clipping colors from a digital capture, the only color space to do so is ProPhoto RGB. So going from raw to PP RGB as a working space makes sense. Then edit in PP RGB to optimize the image. Yes, you can soft proof to the output color space (while staying in PP RGB) and then do a color transform from PP RGB > the output profile in the printing dialog.

Doing this will maintain as much color info as you can while maximizing the final output color.

Transforming into your output color space is, not really a good idea...

[Robert Ardill]

Thanks Jeff.

I actually modified my post while you were replying to me, and I can see that some of my assumptions were wrong.  What you've said is something I hadn't thought of and clearly a very critical point!

Yes, so stick to ProPhoto, soft-proof and let the CMM do the conversion on output.  Unfortunately this still leaves a very difficult edit for images that have parts that are quite a lot out of gamut.

So the next question I would have then is does anyone know of a good plug-in to select the out-of-gamut parts of the image to give a good grey-scale mask (I mean with the very out-of-gamut colors near white and the only a bit-out-of-gamut colors near black)?

I know I'm being a bit obsessive with this (!), but part of my reason is to try to understand the whole color management process better and to stop making silly mistakes as a result of not understanding what I'm doing.  In reality most of my images are well within the paper gamut as I'm a landscape photographer and I don't like very saturated images - but every now and then there's a flower or sunset or something that jumps outside the gamut.  I'm trying to find out what's the most effective workflow to deal with those situations.

I've just had a look at your two books and I wonder which you would recommend first (I'm sure I'll read both) for what I'm trying to understand here?  I've read Real World Color Management (Bruce Fraser et al) and although it's very good, it hasn't answered the sort of problems I'm trying to get my head around.

Robert

[Bart_van_der_Wolf]

So the next question I would have then is does anyone know of a good plug-in to select the out-of-gamut parts of the image to give a good grey-scale mask (I mean with the very out-of-gamut colors near white and the only a bit-out-of-gamut colors near black)?

Hi Robert,

I use something much better than a simple in/out-of gamut mask. I create a Hue/Saturation adjustment layer based on exactly how much the colors are OOG. I created a Photoshop Action to create the selection of OOG colors, which then is applied as a mask to the Hue/Sat adjustment layer, so only OOG colors are affected.

The basis of the action is, make a duplicate of your document (flattened), and convert the new document to to the destination colorspace (relative colorimetric intent). Copy that converted/clipped image and paste it as a layer in the original document (preserve appearance), in Difference blending mode.

Now you can use that to create an intensity mask for the degree of being OOG. Now creatively apply that as a mask to a Hue Saturation adjustment layer where you can set Saturation to -100% if necessary, or target specific colors. Because it is a layer, you can adjust the opacity if you only want to apply a subtle change.

Cheers,
Bart

[digitaldog]

I know I'm being a bit obsessive with this (!), but part of my reason is to try to understand the whole color management process better and to stop making silly mistakes as a result of not understanding what I'm doing.

Keep in mind, OOG is a fact of life and either you or the profile (or both) have to fit a gallon of water into a half gallon container (or less). If there are significant color shifts or important colors that block and lose detial, that would be an issue. If you start with a big container, at least you've stored the data until you funnel it into the smaller and/or different output space. If you look at the shapes of RGB working space and then output spaces, there's a lot of disconnect there too. Round holes that need to be fit into square peg shapes. I'd be a bit less obsessive for awhile, see how the output comes out. You might end up being a tad less obsessive since there isn't a lot you can do. If you find blocked up colors with no detail or a color shift, yes, pay attention and see if you can fix it, either manually (good luck) or with better profiles, a better selection of rendering intents, a different output device with a larger gamut and so forth.

Here's an example of my attempts, perhaps not well done, to 'fix' the OOG colors in LR instead of just letting a good profile do the job:
http://digitaldog.net/files/LR4_softproof2.mov

[Robert Ardill]

Hi Bart (have I got your first name right?),

Actually this is very interesting because I use exactly the same method (which I thought I had 'discovered' myself!).  But at the moment my head isn't able to figure out if this is a good method or not, although I have to say it seems to give pretty good results.  The other technique I've tried out is to use the HSL plug-in to make a saturation mask and then to use this to tweak the saturation selectively, then to really dial-it down by reducing the opacity until the image looks good (after all, as Rodney says, it's down to looks at the end of the day, and all we're attempting is to make the square peg fit into the round hole a bit better).

As a kind of weird twist on the technique you use, instead of adjusting the opacity, what I did was to create a 'Perceptual' layer with the Relative mask (as per your technique). To create the 'Perceptual' layer what I do is to copy the image, render it to the output space using Perceptual, convert it back to the working space, and use this.  As the perceptual rendering will bring the colors back into gamut, the effect is to get rid of the OOG pixels.  HOWEVER ... I think this may be doing even more messing with things I don't quite understand and which at the end of the day is probably no better than letting the CMM make the adjustments.

Even though this seems to be the wrong thing to do (and both Rodney and Jeff are pretty clear that it is), the best result I can get with a problematic image (and I haven't tried too many, to be fair) is to convert the image right after import into Photoshop to the output profile and to then edit it to bring it back as close as I can to the original (or to what I want, at any rate).

Interestingly, this certainly doesn't seem to be anything new (is anything?). For example, in 'Real World Color Management' there is this comment: "
• Early-binding workflow converts all the color into final output space as soon as possible—traditional prepress workflows that took output CMYK right from the scanner are a classic example.
• Late-binding workflow delays the conversion to final output as long as possible. In-RIP separations in the platesetter’s or imagesetter’s RIP represent an extreme late-binding workflow.

and then they go on to explain the pros and cons of the two options.  Converting to the output space early on is what they call 'Early Binding', I think - and it would seem that there are advantages to doing it this way; with the major disadvantage being that it burns the image to the printer/paper.

Still, what is really going on when you convert to the output profile?  Clearly there's an effect on the gamut, but also the white point is shifted and so are all the colors.  Then I'm viewing this on my monitor, so what's happening there?  There's potentially another gamut clipping, white point shift (back, presumably?), color shifts etc.  I just don't know enough about color management to be able to figure that out ... which is why I posted this question in the first place  .

I've just had a look at Rodney's video, and he makes a very good case for letting the system take care of things. And I do agree with him.  However, sometimes the system just doesn't do it properly, especially if there are fairly large areas well out of gamut - because then we get a flattened space with none of the life that should be in that part of the image.  Then we do need to do something - and it could be that your method or the HSL plug-in mask, or early-binding ... or something else! ... could help to correct the problem. I think that this is one place that means exit from Lightroom to Photoshop, because Lightroom just doesn't have the tools for this kind of very selective editing (IMO, at any rate).

Robert

[Eyeball]

I have been researching this topic of color space conversion quite a bit lately and find it quite interesting.

Another technique besides the saturation mask that I have found can work pretty well is using Curves in LAB to roll-off the extra-saturated values while preserving the in-gamut color and saturation.  It has the advantage of keeping the detail mostly in the luminance channel.  Some may not like it because of the round-trip into LAB or the lost data that can result but I think it can be a good learning technique for people to get their heads around what is happening for these large-to-small gamut scenarios.

For a simple technique, I have found that just dropping the right end-point of the Tone Curve in Lightroom can often accomplish wonders, obviously at some cost to the brightness of the image.

I, too, have found Andrew's video interesting and informative, although I do think he "stacked the deck" a bit with his example image.  I think sometime when he has some extra time it would be good to do a video that shows when relative colorimetric ISN'T good enough.

My feeling is that these large-to-small gamut conversion situations are essentially trade-off scenarios.  You need to think about what is most important to you in terms of saturation accuracy, hue accuracy, retention of detail, and to some extent exposure.  For example, if the clipped channel is not providing important or visible detail or if it is a smooth texture, then the clipping may not cause a significant problem at all, other than a little minor hue shift.  On the other hand, if you have a red rose and you want to be able to see that petal texture, then you are probably going to want to sacrifice some saturation and brightness to obtain that.

I do think this topic is worth communicating.  I still see a lot of people on photo forums that buy into the largely incorrect notion that their particular camera is "very sensitive" to reds, or "you need to reduce exposure in-camera when shooting flowers" or "camera light sensors are blind to certain colors", etc..  When shooting raw at least, most of the time the file is perfectly fine as far as clipping goes.

[Robert Ardill]

Hi Andrew,

I completely agree with you.  My own experience is that it's rare that I can do a better job manually than letting the CMM do it for me.  However, as you point out, there are times when the CMM leaves problems because ...  parts of the image are too far out of gamut, or the profiles are not very good ... or whatever.  Then it's good to first of all be able to recognize what has gone wrong, and then to have some strategy to fix the problems.

I have some techniques for fixing these problems - and I'm beginning to see which to use in different situations.  But it's a bit like trying to find the light-switch in the dark.  Perhaps it's because I'm an engineer by training that I have a need to understand what I'm doing (although engineers get by a lot of the time using rules-of-thumb  .

I still don't get it.  For example, if I think of an image in Adobe RGB (aRGB) being converted to the paper/printer profile (pProf) and back, it looks like this in my mind:

• Image RGB gets converted to Lab by the CMM using the aRGB profile
• Lab (PCS) data gets converted to printer RGB or CMYK by the CMM using the pProf profile
• (Converted image data can be sent as is to the printer)
• Converted image data is converted back to Lab using the reverse pProf
• Lab data gets converted back to image RGB using the aRGB reverse profile

Assuming that this is correct, what I would like to understand clearly is what happens exactly with a particular rendering intent (say Colorimetric): How out-of-gamut data is clipped; how in-gamut data is shifted in relation to the new white point; how the reverse conversion works (for example, presumably the clipped colors cannot be 'unclipped'; in theory, how well can the colors that have been shifted to the new white point be shifted back to where they were originally? what happens to data that has been clipped at the black point ... and white point? and so on).

What I've read so far seems to say: "It's all very simple.  The source data is mapped to the destination data.  To remove the need for nxm mappings it uses a standard reference space - the PCS. That's it." But either I have a tendency to complicate things, or there's a whole lot more to it than that!

Robert 

[Robert Ardill]

 Hi 'Eyeball',

I do agree with you that the OOG thing is just the tip of the iceberg.  I definitely would like to know more about the way color management actually works, in theory and practice, because it's so fundamental to what we do.  Not knowing what's going on is like a racing driver having no idea how an engine works.

I find that as I learn more about this topic (the more confused I get , of course) I start to see why I should do this and not do that ... and I do think my images are getting better as a result.  It isn't a simple subject, that's for sure, but neither is it impossible to understand.  The problem, I think, is that on the one hand you have people like Graeme Gill (ArgyllCMS) who is so into the technical stuff that he is unable to answer a question simply - and on the other hand there are lots of gurus who actually don't seem to know more than the general gist of ... "well, Relative shifts it this way and Perceptual shifts it that way".

I'm hoping that Andrew Rodney and Jeff Schewe and others on this forum can help us poor pilgrims along the way .

Robert

[digitaldog]

Robert. One area that's 'a bitch' about all this is the limitation in display gamut. We're often working with colors we can't see displayed. That's rough. About the only recent development I've seen that is useful comes in Lightroom's OOG using the display profile to show you "you can't see this dummy". But that's about it. Also, OOG overlay is so damn crude. Even if Adobe fixed the bugs that make it inaccurate, one blob over the image I'm editing, with all OOG being treated the same way is crude to be kind. ColorThink at least allows us to use three colors and set dE to represent what could be done with OOG overlays. But it's not on too many people's radar and it is unlikely we'll see more done but we can be hopeful. I'd love to see this in Lightroom someday.

[Robert Ardill]

ColorThink at least allows us to use three colors and set dE to represent what could be done with OOG overlays. But it's not on too many people's radar and it is unlikely we'll see more done but we can be hopeful. I'd love to see this in Lightroom someday.

Hi Andrew,

Yes, what makes the OOG thing interesting for me (as well as a nuisance!) is that it's at the stress-point of color management.  But of course this stress-point is all over the place as you point out: raw to tif, monitor, printer, scanner, press ... everywhere.

Actually, I would quite like to be able to develop my raw image to a working space that's the intersection of the raw workspace, the monitor workspace and the paper gamut, so that I would always be working in gamut.  I know this would limit the possibilities with different papers, etc, but it would also keep things very tight.  Getting a warning that you're out-of-gamut is one thing, fixing the problem is quite another as you show.  That's why I was interested in using my paper profile as the working space (but even that wouldn't fully address the issue as the paper gamut is wider in places than the monitor gamut.

I use GamutVision and it also has useful ways of representing an image's out-of-gamut areas both in color and with various different dE, dL, dC etc metrics.  I haven't used ColorThink although I've been tempted - the trial versions are so restricted that it makes it very hard to evaluate, and GamutVision does a pretty good job, although the user interface is a bit outdated.  Have you compared the two? 

It would certainly be great to have a feature like this in Photoshop - especially if it was possible to create a mask from it!  Perhaps Chromix would consider writing a plug-in for Photoshop?  I'll ask Norman Koren at Imatest, but they're so busy with test software that I can't see them being interested in a side-line like this.

It's amazing what holes there are in Photoshop/Lightroom, for such a mainline and powerful program.  It can do all kinds of weird and wonderful things (the brush engine, for example, is absolutely excellent) ... but for a basic thing like OOG processing it's hardly out of its nappies!

Robert

[Robert Ardill]

Hello again,

I thought I would try developing and exporting an image in Lightroom to sRGB, and comparing this to the same image, with the same Lightroom developed settings, taken in to Photoshop, converted to sRGB, processed a bit more (so no OOG problems because the image is now in sRGB) and then exported.

I picked this image because it has a lot of saturated yellows and greens (not for its beauty , most of which are outside the sRGB color space.

Here is the image with the Lightroom OOG warning:



And here is the image exported from Lightroom as an sRGB file:



And, finally, here is the image after conversion to sRGB in Photoshop, followed by some pretty basic saturation and tonal tweaking:



At first sight there doesn't seem to be all that much difference.  However, whether you prefer (or dislike one version over the other, I think it's clear on closer examination that the Lightroom export is generally flatter. For example, the right petal in the Photoshop version has clearer hues and tones in the reds/pinks, and the top petal is also better in the reds and also in the yellows; the yellows of the leaves at the bottom right are more clipped in the Lightroom export than in the Photoshop version; the top left leaf is better in the Photoshop version; contrast is generally better in the Photoshop version.  Mostly, I don't see anywhere where the Lightroom export is better. BTW, the Photoshop version looks sharper, but I didn't apply any sharpening in Photoshop; however I think the down-sampling may have used Bicubic Nearest Neighbour (hard edges) ... not paying attention!..., so that might account for it.

I've tried to be as honest as I can here - but if you would like to try it yourselves, here is the original: http://www.IrelandUpClose.com/customer/LL/W20865.dng

So, although this is a sample of one, and so is hardly conclusive, my own feeling is that conversion to the destination color space and finishing-off processing in Photoshop is likely to show improvements in the image over a straight export/conversion from Lightroom.  With further work more improvements are possible in Photoshop as it has better selective editing facilities - and, more importantly, this editing can be done in the destination color space.

But, sRGB is a clean working space, unlike a paper profile ... so whether the same possible benefit applies to conversion and editing to a paper profile is not so clear (although in the tests I've tried out so far it does seem to be so).

I would be interested in your views!

Robert

 

[samueljohnchia]

Certainly the Photoshop rendition appears less flat. Layering them on top of each other in PS and flashing-to-compare by hiding the top layer, several things are quite obvious - the Photoshop version has much higher tonal contrast. That's why LR looks flat. LR also looks warmer overall. The flower pinks of LR look more natural, even if they do have a yellow color cast. Various areas are also shifted in hue relative to each other. Both are perhaps a tad on a warm side.

Can the LR file be made to look more like the PS file? Certainly. Especially to match the tonal contrast better. But the ability to make saturation or OOG masks in PS specifically targeting those areas cannot be mimicked in LR. I do appreciate and use that advantage for my own pictures. Btw using the HSL filter does not create an accurate saturation mask. Using the selective color adjustment layer is the way.

I prefer to take Joseph Holmes' approach to the issue of choosing a working space. Your working space should be input centric, not output centric, for you never know what you are going to do with your pictures in future but you can select a working space that is large enough to encompass all the colors for that picture. Prevention of clipping is vital, and not doing so is one of the capital sins of poor digital imaging. It is far easier to build excellent printer profiles that perform top notch gamut mapping than to deal with colors already clipped because of your choice of working space. That's where his Dcam spaces are so brilliant. You can read more about them here. It's interesting to note that Dcam spaces are designed to encompass more efficiently most of the colors you will find naturally, like lots of yellow-greens (foliage) which are not found in Adobe or sRGB, and not any of those ridiculous cyans not found commonly in nature that cannot be printed anyway. Those yellow greens are the colors present in your example.

[Slobodan Blagojevic]

... here is the image after conversion to sRGB in Photoshop, followed by some pretty basic saturation and tonal tweaking:

Hmmm... wouldn't that invalidate the conclusion that PS export is less flat than LR?

[Robert Ardill]

Hmmm... wouldn't that invalidate the conclusion that PS export is less flat than LR?

Hi Slobodan,

Yes sure, I'm not suggesting that Photoshop does a better job of exporting or converting to sRGB than does Lightroom.  I would imagine that since both use the Adobe ACE engine (I think?), that the export/conversion would be identical.

What I'm getting at is that the conversion or export from Melissa/ProPhoto to sRGB is by no means great ... but that once the image is converted it should be possible to tweak it to improve how it looks.  Lightroom (as far as I know) only works in Melissa RGB, so even if you export the image and then edit the exported image in Lightroom you still can't force Lightroom to stay within the sRGB space.  This is something you can do in Photoshop.

Just to be clear - this is not a Lightroom v Photoshop discussion (not on my part at any rate).  I think they both have their strengths and weaknesses.  I use both for all my images (even if I do nothing in Photoshop but re-save the image to tiff or psd ... capture->Lightroom->Photoshop->tiff/psd->Lightroom->Print is just part of my workflow and I find it easier to stick to this for all images than to sometimes stay in Lightroom and sometimes go into Photoshop.

Robert

[Bart_van_der_Wolf]

I prefer to take Joseph Holmes' approach to the issue of choosing a working space.

Hi,

That approach is in principle not much different to using the Beta RGB colorspace that was designed by Bruce Lindbloom as a workingspace. Comfortably larger than AdobeRGB in the right places, and not as gigantic as ProPhoto RGB.

Cheers,
Bart

[Robert Ardill]

Hi,

That approach is in principle not much different to using the Beta RGB colorspace that was designed by Bruce Lindbloom as a workingspace. Comfortably larger than AdobeRGB in the right places, and not as gigantic as ProPhoto RGB.

Cheers,
Bart

Yes, well it would seem that using a custom working space might not be so hard (for example modifying AdobeRGB using IccXML).  Looking at my monitor space compared to aRGB (dotted line is aRGB):



it would seem possible to change to rgb XYZ values so that the working space was now the intersection of these two spaces. That way any editing would always be within the monitor gamut. At least then we would have WYSIWYG ... on the monitor, at any rate (printing would still have the same issues .

BUT ... no doubt it's more complicated than that 

Robert

[Robert Ardill]

Btw using the HSL filter does not create an accurate saturation mask. Using the selective color adjustment layer is the way.

I'm assuming you don't have some technique to use the selective color adjustment layer to create a saturation mask? The reason for a mask like the one that can be made with the HSL filter (or some other technique) is to have a mask that allows further editing in a proportional way (so if you adjust the red, say, the most saturated reds will be adjusted the most ... and since these are most likely to be the ones OOG, it makes sense to do it that way).

Having said that, I do think that trying to tweak OOG colors back into gamut is a quick way to get a headache .

Robert