Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: HSakols on May 27, 2015, 10:54:15 am
-
I'm curious what others typically do while soft proofing. I always just check the difference between relative and perceptual and have played a little with contrast. I understand that this question is dependent on the media you are printing on.
-
Anything the photo requires, except for sharpening and noise mitigation which are not affected. Generally you should expect much more adjusting for matte papers than for luster or glossy.
-
Anything the photo requires, except for sharpening and noise mitigation which are not affected. Generally you should expect much more adjusting for matte papers than for luster or glossy.
+1
I pay extra attention to any unprintable saturated deep blues in an image & try & tweak them so they shift towards green rather than purple. ( Less offensive to my eyes ).
I usually whack up the clarity / midtone contrast before printing.
-
I don't. I just do work prints.
-
I pick the rendering intent I visually prefer per image.
IF I see a difference in the soft proof, with the simulate paper and ink on that I don't care for, I may try to do a slight, output specific edit to bring it closer to the original. There's only so much one can do in this respect and the edits are often small. Slight curves adjustment, maybe a tiny tweak to saturation and HSL or in PS, Hue/Sat. In PS I can drag and drop all these layers onto other similar files so I don't have to reinvent each edit. In LR, it's all done on a Proof Copy, again one can copy and paste these output specific corrections to other similar images for print.
-
All Photoshop editing is soft proofed . In addition to standard edits, including those already mentioned , I may reassign colour spaces into variants, check changed blending modes and masks. Out of gamut colours are corrected usually by selective desaturation but sometimes by hue.Multiple profiles may be compared.
-
Out of gamut colours are corrected usually by selective desaturation....
Ouch. I need to work on a video showing why this is a great technique for those charging by the hour and not so great for any other purpose ;D
-
Ouch. I need to work on a video showing why this is a great technique for those charging by the hour and not so great for any other purpose ;D
Andrew, Much of what Brian describes above being implemented very quickly. Yes, one prefers the faster/more automated methods, but sometimes the more arcane interventions are useful and needn't take much time at all with the tools we're using nowadays.
-
Andrew, Much of what Brian describes above being implemented very quickly. Yes, one prefers the faster/more automated methods, but sometimes the more arcane interventions are useful and needn't take much time at all with the tools we're using nowadays.
It's more than speed, it's about quality and control. Considering that the OOG overlay treats any degree of OOG the same, there's zero granularity in seeing, selecting and editing this misinformation (the overlay is inaccurate and buggy), it's a bit like color correcting on a grayscale display system. The output profile isn't blind to this one bit!
-
It's more than speed, it's about quality and control. Considering that the OOG overlay treats any degree of OOG the same, there's zero granularity in seeing, selecting and editing this misinformation (the overlay is inaccurate and buggy), it's a bit like color correcting on a grayscale display system. The output profile isn't blind to this one bit!
Well, you mentioned the speed aspect (charging by the hour), not me. But focusing on the substance - agreed - I never ever use those OOG overlays. As you say, inaccurate and opaque. If we're talking about handling OOG colours, I think there are two basic approaches: either edit the colour so it becomes IG, or as you say, let the output profile deal with it. I believe what Brian achieves by desaturating OOG colour is that some desaturation brings the colours more into gamut and therefore allows suppressed detail to be revealed. I think we've all seen how this can play out - can be very useful, depending.
-
Well, you mentioned the speed aspect (charging by the hour), not me.
I mentioned it because it's the only reason to go down that path IMHO.
-
...I think there are two basic approaches: either edit the colour so it becomes IG...
How? We've got OOG overlay up. We could manually use the Sponge Tool set to desaturate until it's gone. We could use Color Range and select OOG colors, then do similar or apply Hue/Sat and move saturation slider down till all OOG goes away. I've tried both and the results compared to just using the profile are pretty awful looking. What else would other's do? Would you attempt to remove all of the OOG overlay, most, at what point is this complete?
-
I mentioned it because it's the only reason to go down that path IMHO.
No we don't have the OOG overlay up - I just said I agree with you it's of very limited usefulness. Here's another scenario that makes more sense: Let us say between the non-softproofed monitor image and the soft-proofed one you notice for example that detail in the reds has been compromised in the latter but not the former. By making a carefully controlled leftward saturation slider move of the red group in the LR HSL panel you bring back much of the lost detail under softrpoof with less saturated reds. How far you go is a trade-off - the detail and tonal differentiation improves but the reds become less "rich". So like a lot else in photo editing it's a matter of balance. Where you hit the sweet spot. Maybe it's never "complete" - it's a compromise; depending on the photo what you do with this technique may look better than just letting the profile rip, or it may not; it takes only a moment to find out. We all know - many ways of skinning the cat, so you try this or that to see what works best for the image at hand.
-
Mark and others, I'd like to focus on the OOG overlay behavior and what to do with it.
I just found something odd on this end. I opened an image in ProPhoto RGB that has a lot of saturated colors (part of my Gamut Test File, can post if people need it).
1. Setup a soft proof using my Epson 3880 profile, RelCol.
2. Ask to see OOG overlay. Note that if I go back into Proof Setup and toggle to another profile, the OOG overlay updates as expected. Return back to Epson profile.
3. Open Proof Setup and toggle between RelCol and Perceptual, I see NO difference in OOG overlay which is odd.
4. Duplicate this image. It still has the proof setup with Epson profile, I turn OFF OOG.
5. On duplicate, I use Color Range to select OOG. I then invoke the Quick Mask so I can see what's been selected.
Expected results: Quick Mask overlay and OOG overall in original match.
Actual results: They don't match at all! Not even close.
Color Range is selecting far more colors than what I see with OOG overlay, what's up with that?
-
Grateful if you could send me your gamut test file.
-
Grateful if you could send me your gamut test file.
http://digitaldog.net/files/OOGtest.tif
The full file is here:
http://www.digitaldog.net/files/Gamut_Test_File_Flat.tif
-
Thanks Andrew, I shall do some playing along the lines you suggest as soon as time permits and revert.
Mark
-
Thanks Andrew, I shall do some playing along the lines you suggest as soon as time permits and revert.
One more oddity just noticed.
Open the image, ask for OOG overlay.
Go into Color Settings and change the RGB working space. I have mine set for ProPhoto RGB but it doesn't appear to matter.
Result: Image updates and OOG overlay looks darker or lighter (no difference in size of OOG).
Turn OFF OOG and try again, toggle makes no visible difference on-screen. Only when OOG is on does altering RGB working space change the appearance, why?
-
Color Range> OOG is useless, it's using the CMYK profile selected in color settings, not the soft proof for doing it's thing. Shame. Be useful if Adobe would fix that, tie the profile selected in custom soft proof into the selection here.
-
I tried the technique outlined here for creating two adjustment layers:
http://www.earthboundlight.com/phototips/taking-control-gamut-warnings.html
I'd suggest doing this non-destructively by adding two new image layers, each with a specific blending mode. First, hold down the Alt key (Option key on OS X) and click on the "new layer" icon at the bottom of the layers panel. In the resulting pop-up dialog, select a blending mode of "Soft Light" from the Mode dropdown. Click on the "Fill with Soft-Light neutral color (50% gray)" box that appears at the bottom of the window and then click on "OK." Then create another new layer with a blending mode of "Saturation." There is no neutral color for saturation so just leave this layer empty for now.With these two adjustment layers created, you can paint on one to darken, or paint on the other to destasturate. Set your brush to a low opacity black and paint as needed on the out-of-gamut color areas.
I didn't try to completely eliminate every OOG pixel and you can see the 'before and after' OOG here:
(http://digitaldog.net/files/OOG.jpg)
I then just used the ICC profile that produced the OOG overlay to convert to that color space using RelCol. The two versions are seen here:
(http://digitaldog.net/files/OOGfix.jpg)
One version took less than a second to complete, the other a couple of minutes and yes, I could have spent more time and done a more precise job. WHY?
At least on this end, the version converted to the profile looks much better to me.
-
This sentence threw me:
"I then just used the ICC profile that produced the OOG overlay to convert to that color space using RelCol."
I don't understand what you are doing here. If printing, I would use the profile for my printer/paper combination in ProPhoto space. If there were OOG colours, I could select between RC and Perpetual to decide which handling of those OOG colours I prefer. The result should be no OOG colours one way or another. Is this what you are getting at?
-
Yes, I've gotten in trouble trying to fix out of gamut colors while soft proofing. In the end, I discovered that it was best just to not bother. Thanks for all the good information.
-
This sentence threw me:
"I then just used the ICC profile that produced the OOG overlay to convert to that color space using RelCol."
I don't understand what you are doing here. If printing, I would use the profile for my printer/paper combination in ProPhoto space. If there were OOG colours, I could select between RC and Perpetual to decide which handling of those OOG colours I prefer. The result should be no OOG colours one way or another. Is this what you are getting at?
Output is to Epson 3880 Luster. Loaded that into Customize Proof Setup. Select OOG overlay which is based on that profile unlike Color Range. Used profile to convert from ProPhoto RGB to Epson Luster versus adjusting as suggested using Saturation layer, then converting.
-
Output is to Epson 3880 Luster. Loaded that into Customize Proof Setup. Select OOG overlay which is based on that profile unlike Color Range. Used profile to convert from ProPhoto RGB to Epson Luster versus adjusting as suggested using Saturation layer, then converting.
OK, So basically replicating the normal printing workflow for moving from ProPhoto to Printer/paper space.
-
OK, So basically replicating the normal printing workflow for moving from ProPhoto to Printer/paper space.
Yes. IOW, two attempts; use the profile to deal with OOG or do so manually then convert.
-
Yes. IOW, two attempts; use the profile to deal with OOG or do so manually then convert.
Interesting, because I have processed some photos where I was able to improve upon the automatic profile rendition by doing some taming of saturation before converting, but given the very wide gamut I anyhow obtain from a 4900 with IGFS paper, this is infrequent.
-
Interesting, because I have processed some photos where I was able to improve upon the automatic profile rendition by doing some taming of saturation before converting, but given the very wide gamut I anyhow obtain from a 4900 with IGFS paper, this is infrequent.
Improve using what kind of editing technique? Painting out OOG didn't work well for me at all. I think it's due to the lack of any kind of ability to know how far OOG the overlay is from other adjacent pixels. I may have been heavy handed in the brush work.
-
Improve using what kind of editing technique? Painting out OOG didn't work well for me at all. I think it's due to the lack of any kind of ability to know how far OOG the overlay is from other adjacent pixels. I may have been heavy handed in the brush work.
Oh - brushwork is a last resort. I prefer "natural selection". In the case we're discussing, as I process 99.5% of everything I do in LR, it would be the HSL panel colour groups. When needed, it's usually a "soft touch" on one or perhaps two contiguous groups. And no overlays. It's strictly how the tonal separation, detail and colours contribute to IQ - IMO.
-
Oh - brushwork is a last resort. I prefer "natural selection". In the case we're discussing, as I process 99.5% of everything I do in LR, it would be the HSL panel colour groups. When needed, it's usually a "soft touch" on one or perhaps two contiguous groups. And no overlays. It's strictly how the tonal separation, detail and colours contribute to IQ - IMO.
Can you be more specific? I'm not suggesting brushing away OOG is the best solution (in my mind it clearly isn't).
If I'm to believe that OOG editing is as useless as I do, I have to further test other processes.
Is there a way to accomplish your techniques in Photoshop or only LR?
-
The same kind of tools exist in PS - as adjustment layers - in this case usually working HSL, and depending on the need, perhaps small subsequent adjustments in Exposure, or Curves. It's slower than just selecting a profile, but it can be helpful periodically. The more usual scenario for me, starting from raw files imported to LR with all settings zeroed, is the need to increase Vibrance and contrast rather than the reverse. But again, depends on the photo - no rules - that's why it's art.
-
The same kind of tools exist in PS - as adjustment layers - in this case usually working HSL...
Hue/Saturation command? Globally? Or you first target a specific color (not master) then move Sat slider down?
-
Specific.
-
Andrew - the key point here is that if you are editing under soft-proof for your printer/paper combination and a colour group looks "smashed", and you're missing some tonality and detail, that is the virtual visualization of the output profile having done its thing, whether in RelCol or Perceptual as you wish; it is at that point one would resort to manual desaturation etc. to see whether one can improve on tonality and detail while retaining adequate vibrancy.
-
I ended up with four Hue/Sat adjustment layers after targeting with the eyedropper tool the most egregious areas that had an overlay, then reducing saturation until most but not all the OOG overlay disappeared. The other was again just using the profile alone. I don't think it's necessary to label which is which ;D:
(http://digitaldog.net/files/OOG_HSL.jpg)
Your technique is much better than using a brush! I didn't go too far as I did in the first example where the magenta blanket in the upper right looks over done. And it was faster. But not as fast as just converting and letting the profile deal with OOG.
I'm going to try this in Lightroom although I did this way back when LR got soft proofing for my video on that subject.
Manually removing OOG just appears to go way too far, reducing saturation too much compared to the profile. Obviously I'd like the widest gamut possible. While the top version looks fine, it's a far lower gamut/saturation than the bottom image using the profile. Might need to compare in ColorThink too.
-
Andrew - the key point here is that if you are editing under soft-proof for your printer/paper combination and a colour group looks "smashed", and you're missing some tonality and detail, that is the virtual visualization of the output profile having done its thing, whether in RelCol or Perceptual as you wish; it is at that point one would resort to manual desaturation etc. to see whether one can improve on tonality and detail while retaining adequate vibrancy.
The smashed look appears to some degree in the converted image due to so many colors being outside display gamut (and I'm using a wide gamut display).
-
Your technique is much better than using a brush! I didn't go too far as I did in the first example where the magenta blanket in the upper right looks over done. And it was faster. But not as fast as just converting and letting the profile deal with OOG.
.................
Manually removing OOG just appears to go way too far, reducing saturation too much compared to the profile. Obviously I'd like the widest gamut possible. While the top version looks fine, it's a far lower gamut/saturation than the bottom image using the profile. .............
If just using the profile preserves tonality and detail without sacrificing vibrancy that's the way to go. But if you're in a situation where you can't get all three so easily, that's where the tinkering and balancing becomes useful. As I said, not something I need to do habitually.
-
A general hue/sat color range adjustment always takes too much, because it works over the entire tonal range. OOG is usually confined to either the low or high end, and that's all you need to target.
There is a simple way to identify and select out of gamut areas: Make a copy, convert, and look at individual channels. Solid black or solid white is out of gamut, and easily selected using Color Range. Make a mask and drag it back to the original image.
A quick and dirty way is to use a Channel Mixer layer on these selected areas, and lower the opacity as needed to bring it into gamut. It usually works surprisingly well.
-
There is a simple way to identify and select out of gamut areas: Make a copy, convert, and look at individual channels. Solid black or solid white is out of gamut, and easily selected using Color Range. Make a mask and drag it back to the original image.
To be clear, I'm not really interested in detecting OOG although your technique sounds interesting. My goal is to see if attempting any manual adjustment rather than letting the profile do it's job produces a better print.
A quick and dirty way is to use a Channel Mixer layer on these selected areas, and lower the opacity as needed to bring it into gamut. It usually works surprisingly well.
Now that sounds interesting and I'll give that a try with the above technique and report back, thanks.
-
Understood, and agreed. I usually don't find it worth the trouble to do this manually, and normally I just let the profile do its thing.
But occasionally, for important images, it's worth it, just for the sheer kick of being fanatically perfectionist...sometimes that can be fun ;D
-
There is a simple way to identify and select out of gamut areas: Make a copy, convert, and look at individual channels. Solid black or solid white is out of gamut, and easily selected using Color Range. Make a mask and drag it back to the original image.
Question to make sure I understand the steps.
Converted to output color space, that much is clear.
Set Channels to show B&W (not color). So far so good.
Color Range on individual color channels has an option to select shadows or highlights, not black or white. I assume that's what you're referring to?
If that's the case, it appears I'll end up with 6 masks (one for shadow/black, one for highlight/white for each of the three channels)?
I'm not clear on why shadow/black, and highlight/white solely contain OOG colors.
-
OK, I've attached an example of the channel mixer method (not a good one, but the best I could find in a hurry).
First an Adobe RGB original.
Converted to sRGB, the lower part of the green water clips to 0 in the red channel. So open the Color Range dialog, and use the eyedropper to pick blacks (with only the red channel active in the Channels panel). Obviously, this will pick all blacks, including true black - but that doesn't matter because this doesn't contain any color information anyway. So all channels are equal here and nothing will change.
Go back to RGB and put a channel mixer layer on top, with red channel as output, settings +50 red, +25 green and +25 blue. Set opacity as needed to get a good blend.
The third example is the corrected red channel with channel mixer. Everything looks good, and no more clipping.
In this particular example it actually didn't do much visually, but it shows the principle.
-
Converted to sRGB, the lower part of the green water clips to 0 in the red channel.
None was black prior to conversion?
So open the Color Range dialog, and use the eyedropper to pick blacks (with only the red channel active in the Channels panel).
Ah, that was what I was missing thanks. You're targeting via eyedropper, not a preset (Shadows). I assume you're viewing the numbers to nail black (zero).
Obviously, this will pick all blacks, including true black - but that doesn't matter because this doesn't contain any color information anyway. So all channels are equal here and nothing will change.
Got it. Was there a reason you didn't do the same with Red and Blue, it's just this image didn't have a black in the other channels?
-
No, this particular red channel clipping happens in the conversion to sRGB. In Adobe RGB it's within gamut.
There is in fact a very tiny amount of blue channel clipping in the sun-lit foliage, but not enough to bother with.
As I said, I could probably have found a better example - one in which the clipping is more objectionable than it is here - but the basic procedure is illustrated fairly well. The point is that only the clipped areas are targeted, and very specifically so, leaving everything still in gamut strictly alone. So you don't lose colors you haven't already lost, so to speak.
With this method it's also possible to "reuse" the mask for, say, a selective color layer, to compensate for any unwanted hue shifts.
-
No, this particular red channel clipping happens in the conversion to sRGB. In Adobe RGB it's within gamut.
I'm looking for something color space agnostic, does this still apply?
I'm still not clear on why the image areas that are black in the channel represent OOG.
I was hoping I could do something with Calculations but I'm not getting anywhere. I tried converting from ProPhoto to sRGB then back, using Difference to produce something I could select. Doesn't appear to be working as expected, the result isn't anything like the OOG overlay.
I'm getting to the point where I'm thinking my original idea of just using the profile to handle this is the way to go. If we convert using the profile and then attempt to examine the results to select something, in a copy, it appears that we're back to asking the profile to do all the work anyway.
It's too bad that using Color Range to select OOG doesn't work on the current profile selected in Proof Setup. Only CMYK in Color Settings. But then I would have to believe that the OOG being selected is correct in the first place and I don't know if that's really true. I could try using Color Range on RGB data using the CMYK profile, then convert and see in ColorThink if the two match.
-
I'm still not clear on why the image areas that are black in the channel represent OOG.
Well, that's the clipping. Anything that wants to go higher than 255 or lower than 0 in any channel, in any specific color space, is out of gamut. So it clips to 255 or 0. You could consider that a definition of OOG (among others).
You'll have to excuse me for telling you things you already know; I just need to establish the logic behind this...
Of course, what confuses the issue somewhat is the fact that "true" black or "true" white will also be included in the selection. In any given channel, the two can't be separated. But as already concluded, this is of no practical consequence because with pure black or white the channels are already equal, and nothing will change. So that can simply be ignored.
(side note - in "phenomenological" terms, I think you could consider gamut clipping and exposure clipping the same. It's just anything outside the surface of the color space, or color sphere in a more general view. Exposure clipping is just a special case because it affects all channels, so nothing can be recovered).
Now. The catch here, what makes this somewhat less than an ideal tool for dealing with OOG, is the fact that it only works on an already converted file. Soft proof does not reflect the clipping in individual channel view (I wish it did!); only in the composite RGB. So to use this method you either have to go the roundabout way of doing it on a copy and reimport the selection/mask - or do what I called a "quick and dirty" repair using the channel mixer.
Either way, you still have the advantage of not touching in-gamut areas, so there's no need for "wholesale" desaturation of all blues, all greens and so on. As I said, it's a bit of work, but every once in a while it can be worth it. For normal everyday work it usually isn't.
As for the color space agnostic bit, I don't quite follow-? As you well know, clipping can't be color space agnostic, it clips in this space but not the other.
-
I apologise for leaving the table. There were a lot of other activities on. I did not expect such a long thread and will work through it all carefully. The reference to OOG was intended as a minor point. I very seldom have OOG colours . When i do it is usually quite small areas. If using HSL I select the colour as narrowly as possible using the "colour wheel" sliders and then juggle desaturation and hue to return detail with minimum disturbance of colour appearance. This normally takes no more than a minute or two.If a longer method seemed justified i might use an action to create a set of luminosity channels and set HSL layers over them. That might take a few minutes. I am somewhat concerned re comments that the OOG indication is inaccurate. Would it be beneficial to use ColorThink as an editing aid?
-
Well, that's the clipping. Anything that wants to go higher than 255 or lower than 0 in any channel, in any specific color space, is out of gamut. So it clips to 255 or 0. You could consider that a definition of OOG (among others).
Well the OOG overlay doesn't work that way, at least as I see it. I've got a black to white 21 step ramp in Adobe RGB (1998), if I soft proof for sRGB and ask to see the overlay, none of this is shown as OOG. That's why I asked about your targeting of black with the eyedropper, if it represents "colors" that clip.
Of course, what confuses the issue somewhat is the fact that "true" black or "true" white will also be included in the selection.
That's my concern, and it appears the current OOG overlay doesn't target those true blacks or true whites for one.
In any given channel, the two can't be separated. But as already concluded, this is of no practical consequence because with pure black or white the channels are already equal, and nothing will change. So that can simply be ignored.
I guess so ;D
Now. The catch here, what makes this somewhat less than an ideal tool for dealing with OOG, is the fact that it only works on an already converted file.
Understood. That's not a huge, big deal and we did discuss that the profile is used for this operation so there's no way to put any toothpaste back into the tube if you will from this approach. It seems to underscore my original concept to just examine visually what the profile will do via a soft proof (display gamut limitations recognized) select a rendering intent one visually prefers and letting the conversion take place. That could allow for some output specific edits to be applied prior to the conversion while viewing the soft proof if necessary.
As for the color space agnostic bit, I don't quite follow-? As you well know, clipping can't be color space agnostic, it clips in this space but not the other.
I could have been more clear by saying destination color space agnostic. I was confused by your statement about sRGB as if the technique was based upon that destination color space. I'm looking for an alternative to "just use the profile" that would work with all destination profiles, working space or output.
-
I am somewhat concerned re comments that the OOG indication is inaccurate. Would it be beneficial to use ColorThink as an editing aid?
I don't see it on all images in all color spaces. I do see it here:
http://digitaldog.net/files/Printer%20Test%20file.jpg
The image in ColorMatch RGB. If I select that in Proof Setup and use the OOG command, I see some areas of overlay and of course I shouldn’t. Same in Lightroom, I think they share the same code.
As for ColorThink, it's ideal but you have to feed it tiny files or it will barf. 300x300 pixels is what I usually send to CT for analysis which means severe resampling to plot the image.
-
Well the OOG overlay doesn't work that way, at least as I see it.
I'm getting a very close congruence, and I still think my method holds up. If anything, the OOG overlay is somewhat conservative and there seems to be a small threshold before it kicks in. That makes sense. I still insist that areas that are clipped in the converted file will show up as solid black or solid white in individual channels, since they are clipped to either 0 or 255.
Another example.
In the first I used the Lightroom OOG overlay, raw original soft proofed to sRGB.
Second "my method" showing blue channel clipping - plus black as noted, but there's very little of that here. Third ditto green channel clipping. There's no red channel clipping here.
As this is, again, a low-key image, all the clipping occurs in the low end. High-end clipping is what you get in your typical sunset, and that would show up as white.
If you add these two, the blue and the green channel, you get pretty much pixel-perfect what the Lr OOG overlay indicates.
-
BTW I'm just using sRGB as a convenient small-gamut space here. There's no special significance to sRGB.
-
I'm getting a very close congruence, and I still think my method holds up.
I'll continue to to look into this, thanks!
-
I'm getting a very close congruence, and I still think my method holds up. If anything, the OOG overlay is somewhat conservative and there seems to be a small threshold before it kicks in.
I'm seeing the conservative nature you point out in a recent test but I'm not certain about close congruence but it may not matter, nothing I know of proves the OOG overlay is 'correct'. Maybe the opposite.
I uploaded my test file which is part of the Gamut Test File. Here's what I did:
1. Duplicate the ProPhoto RGB image, convert to sRGB.
2. View first the Red Channel, use Color Range with the eyedropper to select a color/tone. I made sure with the info palette I was hovering over pixels at 0/0/0. Note, the one attribute I'm not sure of is Fuzziness. I see two different values in your examples. All blacks in Red Channel gets selected. I then used Save Selection and targeted the original ProPhoto RGB image to create an Alpha Channel.
3. Repeat step #2 on Green and Blue channel.
4. Back in the original ProPhoto RGB image I used Load Selection three times (adding the selection from Green and Blue Alpha to the Red to produce one selection of all three). I then saved that composite into a single Alpha Channels.
I went back to the sRGB image and reset History so I now have two images in ProPhoto RGB to compare.
Now I can show the selections from each, one is OOG using the old Photoshop command, the other the custom selection. Here's the results of the two where 'Black' is the selection:
(http://digitaldog.net/files/Mask.jpg)
On the left is OOG from Photoshop where I've set the overlay to black, 100%. On the right is your technique. Not identical, but an interesting selection.
So assuming I'm doing this correctly and can trust the selection, the next thing I have to test is what to do with the OOG colors selected.
I've uploaded the TIFF with all the Alpha channels if anyone wishes to comment. It's set with the Quick Mask on so at least on this end, after saving and opening again, that is 'sticky' so you'll see an overlay I believe although based on your PS preferences, it may not be in black at full opacity. It's here:
http://digitaldog.net/files/OOG.tif
-
Couple further comments. I didn't target white or 255/255/255 from the three channels in this image but I don't see any such values in the individual color channels so I hope that's OK.
I have a selection but I'm not sure what to do and how far to go with any edit. With the OOG overlay, what's useful is it begins to disappear as you affect the image. But of course, doing so until it's even close to fully disappearing hoses the image.
I converted one copy from ProPhoto RGB to sRGB to use as a visual guide. Now the trick is using the selection to do something to get it into gamut and appear better than the other copy using the profile and I'm not sure that's possible.
The selection technique is pretty cool, no question. But I'm not sure what to do after producing it. The sRGB version looks OK. The one area I don't see detail is the very vivid magenta towel in the upper right corner. Using Channel Mixer, a tool I'm far from savvy with and lowering Red a tad does appear to bring back detail but unfortunately affects other colors with red component in a less than ideal way. Plus 86 Red (from 100) really helps the magenta but not the yellow's and oranges elsewhere.
-
Ah well, that's a tricky one... ;D
Here you have pushed even ProPhoto almost to the limit, and the sRGB clipping here is so massive that I won't even attempt it. It'll just be an across the board desaturation.
I did manage to make an Adobe RGB version without clipping - although I admit to cheating a bit, as I used your sRGB masks. But I think it clearly does look better than just letting the profile do it, which is what I wanted to find out (attached with ARGB profile embedded). In particular, the magentas and the central yellow regain texture that was mostly absent (even viewed on a wide gamut monitor).
There's no way this beast can be tackled with a single mask. This one has to be dealt with mask by mask, channel by channel, color by color.
A few additional selective color and hue/sat adjustments were required after the basic mask treatment - not to desaturate further, but to compensate for hue shifts. Most colors basically survive.
The masks seem sound. Yes, there are a few small discrepancies with the Photoshop overlay, mostly in oranges - which is because there is a little highlight clipping in the red channel here.
I spent a little more than an hour on this. Is it worth it? Could well be. Thanks for an interesting hour ;)
(had to post as jpeg with channels stripped)
-
Ah well, that's a tricky one... ;D
That was the plan, the rest of the test file is equally difficult!
Here you have pushed even ProPhoto almost to the limit, and the sRGB clipping here is so massive that I won't even attempt it. It'll just be an across the board desaturation.
In the end, I just use the old Sponge Tool to carefully deal with the magenta cloth, then using Fade, brought it down to see some detail there in sRGB. Considering what role sRGB plays for me, it isn't worth the effort, it's just going onto the web. What's interesting is converting to my Epson 3880 profile, plenty of detail after the conversion both on-screen and on the print. So part of the fault is Satanic RGB.
There's no way this beast can be tackled with a single mask. This one has to be dealt with mask by mask, channel by channel, color by color.
Not worth the effort to post as an sRGB image to the web or mobil devices.
The masks seem sound. Yes, there are a few small discrepancies with the Photoshop overlay, mostly in oranges - which is because there is a little highlight clipping in the red channel here.
Cool. I do like the mask technique, so that's worth all the effort (on this end).
I spent a little more than an hour on this.
Ouch.
So another tactic that didn't seem to work was using ColorThink Pro to build a ColorCast profile. I used an sRGB to CMYK transform with the idea I could then use Color Range to select OOG. It worked but not like either your masking technique or Photoshop's OOG. The CMYK profile selected plays a role. I really wanted an sRGB profile that lived in a CMYK shell to fool Photoshop to use Color Range. That part worked somewhat, it could be accessed and it perfectly matches the OOG overlay but again, since the CMYK profile part of the ColorCast process plays a role, I have no idea what to use for that part of the transform.
What we need is for Adobe to tie the current Proof Setup to be accused in Color Range to select OOG, not the CMYK profile in Color Settings. We need them to fix the inaccuracies of what's defined as OOG. Then we need two or three OOG colors to represent small, medium and large amounts of OOG. Until then, I'm not convinced I'd manually do anything much more than convert after viewing a soft proof and maybe doing a < 5 minute selective edit in areas like we see in the Magenta cloth.
Oh BTW, I tried converting the image to sRGB using the V4 ICC Profile that provides a Perceptual rendering intent and the results were even worse on the Magenta cloth than using RelCol.
Thanks for your time, I learned a lot!
-
An hour is nothing for me. Back when I had a darkroom (the chemical kind), I could spend a week on one single negative. That was my Ansel Adams period... of course nobody else saw any difference.
These days, as a full-time employed photographer, where deadlines queue up every day, I usually don't have that luxury. But every once in a while, an image is considered so important that I can spend an hour or two on it. And it usually shows. But most of it is CMYK for books and magazines, so most of the time is spent getting around the inherent limitations.
An interesting discussion. I wouldn't mortgage my house on this, not yet, but I have a feeling there's something here. I'll keep trying it out, and I'm sure this will come up again ;)
-
Just a side note —
Here's a test image that I made for exploring OOG issues. The colors in the image are from outer surface of the prophoto space in xyY projected onto the xy plane. Since the colors are from the outer surface of the space, every color will have at least one coordinate that is 255. This means that the entire colored area of the image should be outside the gamut of sRGB. Photoshop's gamut warning overlay shows a few stripes of color that it thinks are within the sRGB gamut. I'm not sure why it does this, but Andrew has mentioned on several occasions that it's not very accurate.
One interesting thing about this image is that even though the entire images is within the prophoto gamut, D Fosse's technique will suggest the whole colored area is clipping. It's an example of the fringe case where 255 really is 255 rather than a greater value that has been clipped.
Another thing this image illustrates is the danger of using xy chromaticity to evaluate gamut. If you overlay the sRGB triangle onto this you might think the values in the center of the image should be within the sRGB gamut, but they're not. Even though sRGB can contain colors with these xy values, these particular colors are out of gamut because they sit outside the 3d hull of the sRGB solid in xyY space.
-
Something just occurred to me, maybe a flaw in my reasoning. When you look at an individual channel in Photoshop, it is displayed according to your gray working space, not the original color space of the file. This mainly affects the TRC, but maybe it also affects the clipping point, especially considering the linear section in the sRGB TRC. I need to think about this.
On the other hand, what else can out-of-gamut be, other than colors that want to push channels above 255 or below 0? If a color can be expressed as an RGB triplet in any given space, then that's what that color is. It has to be in gamut.
-
Something just occurred to me, maybe a flaw in my reasoning. When you look at an individual channel in Photoshop, it is displayed according to your gray working space, not the original color space of the file.
I don't see the numbers changing, just the preview which kind of makes sense. Much like the numbers of an untagged document don't change as you update the RGB working space, only the preview.
-
This means that the entire colored area of the image should be outside the gamut of sRGB. Photoshop's gamut warning overlay shows a few stripes of color that it thinks are within the sRGB gamut. I'm not sure why it does this, but Andrew has mentioned on several occasions that it's not very accurate.
Here's an example of OOG being shown that shouldn't using my old Printer Test File which was in ColorMatch RGB and soft proofed to the same profile. Green is OOG overlay:
(http://digitaldog.net/files/OOGnoAccurate.tiff)
Doing the same in Lightroom produces the same issue although it's not identical. The two app's don't correspond.
So going back to your investigation, does it make sense to suggest that while PS's OOG overlay isn't accurate in all cases, it's closer than using the Mask built from other RGB channles? The former doesn’t provide a way to select these colors which would be useful, the later does but it sounds like it might not be an accurate selection of OOG. Where does that leave us?
-
On the other hand, what else can out-of-gamut be, other than colors that want to push channels above 255 or below 0? If a color can be expressed as an RGB triplet in any given space, then that's what that color is. It has to be in gamut.
I think this is correct with the single caveat that you can't distinguish between numbers that are clipped to 255 or 0 and those that legitimately are 255 and 0 without clipping.
-
Well the OOG overlay doesn't work that way, at least as I see it. I've got a black to white 21 step ramp in Adobe RGB (1998), if I soft proof for sRGB and ask to see the overlay, none of this is shown as OOG. That's why I asked about your targeting of black with the eyedropper, if it represents "colors" that clip. That's my concern, and it appears the current OOG overlay doesn't target those true blacks or true whites for one.
Why should there be OOG when softproofing gray scale images between Adobe RGB and sRGB as the gamuts from L*a*b 0,0,0 to 100, 0, 0 are the same, as far as I know. In a Colorthink plot, there is a straight line extending from L*a*b 100, 0, 0 to 0, 0, 0. In other words, their gamuts with regard to luminance are the same. Their gamuts diverge when chroma is involved and a and b diverge from zero. Isn't this the case?
Regards,
Bill
-
Why should there be OOG when softproofing gray scale images between Adobe RGB and sRGB as the gamuts from L*a*b 0,0,0 to 100, 0, 0 are the same, as far as I know.
That's why I asked the question. Photoshop doesn't show any OOG overlay, using the technique to pick via an color channel as described earlier does.
These are not grayscale images but rather a grayscale channel of a color image. That said, I think what Mark wrote in his last reply might indicate this process isn't selecting just OOG colors which might make it's selection process an issue.
-
That's why I asked the question. Photoshop doesn't show any OOG overlay, using the technique to pick via an color channel as described earlier does.
These are not grayscale images but rather a grayscale channel of a color image. That said, I think what Mark wrote in his last reply might indicate this process isn't selecting just OOG colors which might make it's selection process an issue.
Perhaps I mis-spoke in referring to gray scale images. A gray scale image can be encoded in a single channel file or as a 3 channel RGB file in which all the RGB values are equal. My point was that your black to white wedge scale in Adobe RGB can be fully encoded in sRGB since the luminance ranges of the two spaces are equal. My original points are demonstrated in this plot.
Bill
-
My point was that your black to white wedge scale in Adobe RGB can be fully encoded in sRGB since the luminance ranges of the two spaces are equal.
And Photoshop's soft proof honors that, the other technique doesn't if I'm understanding the comments correctly. So what to do? Use an interesting technique to select OOG/clipped colors? Use the Photoshop OOG overlay and not select those colors to then do some kind of edit?
Or as I've proposed from the beginning, soft proof with the profile, let it do it's business expect in rare cases where the soft proof, NOT the OOG overlay indicates some selective editing is in order, as I illustrated with the magenta cloth losing detail?
-
All right. I'd like to zoom in on one specific aspect of this, just for one moment. No examples, no color space plots, just a simple question:
If you convert a file and you get clipping because a color is out of gamut:
How can it possibly show up in the converted file, other than as 0 or 255 in one or two channels? It's just not possible for an out of gamut color to turn up in the middle of the histogram for all channels. If it did, it wouldn't be out of gamut, would it?
I know the histogram is out of fashion and you're supposed to ignore it. But let's just treat it as a diagnostic tool, nothing more. If you see the blue channel solidly rammed against the left wall, what else could it be than gamut clipping?
-
I know the histogram is out of fashion and you're supposed to ignore it. But let's just treat it as a diagnostic tool, nothing more. If you see the blue channel solidly rammed against the left wall, what else could it be than gamut clipping?
Out of fashion and best ignored according to whom? A proper histogram is a valuable tool. One prominent author, Jeff Schewe, in his writings on ACR has indicated that when one is rendering into a narrower color space such as sRGB or AdobeRGB and the histogram hits the wall with one color, this may be due to saturation clipping and one should try rendering into a wider color space such as ProPhotoRGB. This has worked many times for me. In some cases, one can eliminate such clipping by adjusting the exposure, but this darkens the image and is not recommended.
Bill
-
Exactly, Bill, and this is my hypothesis: When you see the histogram hitting the wall for one color, left side or right side, that is the gamut clipping. So clipped colors have a common feature: one channel is either 0 or 255, black or white.
Most discussions on gamut clipping tend to concentrate on the 255 side. I don't know why, but maybe because that's the typical clipping you get in a very typical scenario - the sunset. And a clipped sunset is very objectionable to everyone. Or a bright red or yellow flower, also a common example.
But, at least for the type of photography that I do, I see clipping on the 0 side just as frequently. And it can be just as objectionable, because it tends to kill light and "air" in these areas.
So. Can this common feature - 0 or 255 - be used to selectively target these areas, with minimum collateral damage to unclipped areas?
-
Exactly, Bill, and this is my hypothesis: When you see the histogram hitting the wall for one color, left side or right side, that is the gamut clipping. So clipped colors have a common feature: one channel is either 0 or 255, black or white.
But is that telling us via a selection of the channel if it's color clipping or tonal clipping? There lies my confusion and the reason why Photoshop's OOG overlay doesn't show me areas that are tonal clipping but does show me color clipping. A properly built Histogram shows us the difference too. So it's useful, no question.
Clipping colors and tonal clipping still share a common feature? If the concept you outline is to select OOG colors, something I'd prefer Color Range to do on RGB files or anything setup in Proof Setup, we appear to be selecting tone and color clipping and I'd think we'd only want to select and edit color clipping.
If you convert a file and you get clipping because a color is out of gamut:
Colors or tones or both?
-
Yes, that is indeed the main problem. The distinction seems to be whether all channels clip, or just one. Or perhaps two, but at any rate not all three.
But how to separate them? Maybe subtracting low and high Lab values might be possible. In my posts above I suggested merely ignoring this, as there most likely isn't any color information there anyway. But maybe there's a better way.
This is getting very elaborate...and ultimately perhaps not worth it. But if you look at it from the other end - not with the objective to "fix" all clipping, which is clearly overkill - but to avoid desaturating unclipped areas in the event some remapping is required anyway. Just as a protective mask when brushing, or something similar.
-
Yes, that is indeed the main problem. The distinction seems to be whether all channels clip, or just one. Or perhaps two, but at any rate not all three.
But how to separate them?
Good question. I'm not sure we can. I was hoping we could select 0/0/0 from each color channel and add those selections to a new, single alpha channel, then subtract anything that's neutral, avoiding color and thus OOG. But Color Range doesn't have this capability. Two other issues with the technique as I understand it:
1. The Color Range selection is based on the Eyedropper sampling. So obviously setting point vs. 3x3 vs. other settings affect what Color Range selects.
2. Fuzziness also affects the selection. No feather would be more precise in what gets selected. But the final selection channel if loaded and some edit applied (you used Channel Mixer) can produce some ugly selections of edges.
So I'm not sure this technique can work, again based on my understanding of the steps. We want only OOG colors, not clipped colors or rather clipped tones. We want to select OOG only so we can edit just those pixels but that's looking difficult to do with the tools provided.
So this takes me back to one possible solutions. Just soft proof, let the profile handle OOG and if an area looks poor, like the Magenta fabric that has no detail, deal with that selectively prior to conversion while soft proofing. Forget the OOG overlay completely. Use the sponge tool set to desaturate with a low level of strength (flow) and along with the Fade command if necessary to fix this problem pretty quickly. The technique can be done on a layer so it's "non destructive". Instead of using Sponge tool:
1.Create a new layer above the image, set blend mode to Saturation.
2.Set color to Black (or any neutral color value).
3.Select a brush with low opacity and paint onto OOG to desaturate. The Fade command is useful to fine tune but operates after each brush stroke.
If you go too far, set color to fully saturated color (R0/G255/B0) Paint saturation back in.
The other alternative is if the soft proof looks OK, just pick the rendering intent, and move on.
-
All right. I'd like to zoom in on one specific aspect of this, just for one moment. No examples, no color space plots, just a simple question:
If you convert a file and you get clipping because a color is out of gamut:
How can it possibly show up in the converted file, other than as 0 or 255 in one or two channels? It's just not possible for an out of gamut color to turn up in the middle of the histogram for all channels. If it did, it wouldn't be out of gamut, would it?
You should test this theory with LUT based profiles such as printer profiles. This will allow you to also test with different rendering intents that are more complex than simple matrix multiplications. You will find that you often have out of gamut colors that get mapped into the destination space with some breathing room and don't look like they are clipping. For example for the ProPhotoRGB color [10, 250, 10] photoshop give a LAB value of [86, -128, -128]. Converted to Epson's 3880 standard profile give an RGB value of [134, 252, 45] = LAB [87, -84, 85]. The gamut warning says it's out of gamut, the color shift is significant, but the technique of finding clipped color values will fail to identify this as out of gamut.
-
You should test this theory with LUT based profiles such as printer profiles. This will allow you to also test with different rendering intents that are more complex than simple matrix multiplications.
You've outlined yet another problem with Adobe's OOG overlay. Toggling the differing RI's don't produce any difference.
-
You've outlined yet another problem with Adobe's OOG overlay. Toggling the differing RI's don't produce any difference.
I'm not sure it should. Unless I'm misunderstanding something, the rendering intent shouldn't change whether a color is out of gamut — it should only change how out-of-gamut values are mapped to the destination.
-
I'm not sure it should. Unless I'm misunderstanding something, the rendering intent shouldn't change whether a color is out of gamut — it should only change how out-of-gamut values are mapped to the destination.
What I've done is opened an image in ProPhoto RGB and set an Epson profile for soft proofing. I then ask to see the OOG overlay. I'd expect that as I toggle between Perceptual and RelCol, the overlay would change somewhat. But perhaps you're right now that I think of it, RelCol clips OOG to the boundaries, Perceptual would affect other colors. If true, it still makes the overlay far less useful than a soft proof which of course does change what we see on-screen.