Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Robert Ardill on June 20, 2014, 07:16:14 pm
-
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
-
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.
-
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
-
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...
-
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
-
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
-
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
-
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
-
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.
-
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
-
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
-
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.
-
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
-
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:
(http://www.IrelandUpClose.com/customer/LL/W20865-sRGB-Gamut-Warning-in-Lightroom.jpg)
And here is the image exported from Lightroom as an sRGB file:
(http://www.IrelandUpClose.com/customer/LL/W20865-Exported-to-sRGB-from-Lightroom.jpg)
And, finally, here is the image after conversion to sRGB in Photoshop, followed by some pretty basic saturation and tonal tweaking:
(http://www.IrelandUpClose.com/customer/LL/W20865-Converted-to-sRGB-and-adjusted-in-Photoshop.jpg)
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
-
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 (http://www.josephholmes.com/profiles.html). 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.
-
... 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?
-
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
-
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 (http://www.brucelindbloom.com/BetaRGB.html) 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
-
Hi,
That approach is in principle not much different to using the Beta RGB colorspace (http://www.brucelindbloom.com/BetaRGB.html) 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):
(http://www.irelandupclose.com/customer/LL/mon-argb.jpg)
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
-
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
-
Yes, well it would seem that using a custom working space might not be so hard (for example modifying AdobeRGB using IccXML).
You can build simple matrix profiles in Photoshop itself (Custom RGB in Color Settings).
Photoshop CC 2014 has a new Export CLUT where one can now create 3DL,CUBE,CSP, or ICC profiles.
(http://www.digitaldog.net/files/ExportCLUT.jpg)
-
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 :)).
A big issue. This is a big reason Photoshop divorced your specific display and how you edit the numbers and made working (editing) space agnostic (but display-like) color spaces back in Photoshop 5.
You're allow ignoring colors that could be out of that display gamut but defined from the raw data by virtue of the working space you select at the time of rendering from raw. It's why Adobe raw converters have a big honking and to some degree dangerous processing space.
-
Here is the image with the Lightroom OOG warning:
On this end (wide gamut display but color managed browser), I can't see how that overlay has any real relationship to either image. It shows a huge portion of solid red which seems rather alarming but the two images are rather similar. Further, the biggest visual difference I see immediately is the 'sharpness/contrast' reported.
The difference I see visually remind me of the recent discussions about sending PPI to the Epson and again, I just didn't see anything with the naked eye that made a non subjective difference. If I saw both images below individually I'd have no problem with either. I kind of like the sharper image better, totally subjective.
Looking closer I take that back, I'm seeing 'noise' and edges I don't like compared to the upper image. Subjective and I'm sure hugely influenced by display technology, calibration etc. Fun to go look on the iPad or iPhone...
-
Here is the image with the Lightroom OOG warning:...
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.
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
Between the audio engineering blog discussion I participate on pitch changes related to loudness wars remastering and this OOG discussion, I see so many similarities on what is getting missed.
You want to make it loud at the digital source? (yellow flower? Rhino remaster of Chicago V album?) Learn to know when you've screwed it up and then learn what tools to use to bring it back at the Raw source. You have to hear, think and feel the sound or image as it should look or sound on output be it a print or as CD audio. I was taught that early on as a child musician. I finally saw the similarities to this in digital imaging later on.
I've captured flowers shot brilliantly lit by direct sunlight and can get no clipped data (visually) on both my sRGB screen display and glossy paper print and I use "Printer Manages Color" on a $50 Epson "All In One". Gorgeous prints of flowers brightly lit full of detail. Your yellow flower is shot in overcast light. Why are you blaming OOG on why you can't enhance it? Almost every image I work on in ProPhotoRGB space and attempt to edit in order to make it loud and brilliant ALWAYS shows clipped data converting to sRGB. Loudness Wars! OOG! It's all the same.
You're problem is not OOG. It's that you haven't learned to use the editing tools and how they work and behave in relation to your perception to get you the look you want to convey as you remember the scene which is rarely ACCURATE. It's not your fault. It's the limits of how the software is designed to make it easy to use for those that don't have the time to figure this out.
It took me almost 5 years to figure out PV2003 advantages and disadvantages of the slightly linear behavior of the Exposure slider vs the behavior of the Brightness slider and to finally realize that these two don't always map the not so linearly recorded sensor data of my camera the way my mind sees it.
I started using the Parametric curve to build a curve to remap linearity back into both the sensor data and how the Exposure slider and Brightness slider act on the preview to push brightness while maintaining local contrast in highlights just as I purchased LR4 for its PV2012 which is no longer linear at all and is now quite difficult for me to figure out what's affecting what. It's like starting over from scratch. I see you're having the same difficulties in your LR vs PS edit of the yellow flower. It's a dull, dim and flat looking image and you want to give it some pop. OOG concerns are not where to look.
-
Hi,
That approach is in principle not much different to using the Beta RGB colorspace (http://www.brucelindbloom.com/BetaRGB.html) 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
Hi Bart, Beta RGB and the Dcam spaces do have significant differences in their design approach. Both Bruce and Joseph took the same approach of looking at many examples of where real world colors lie and designed their color spaces to encompass as much of them as possible. That is as far as they are similar. Bruce compared the colors from film based input, but also from color charts and printing gamuts. Which makes it both input and output centric. It is still one big honking color space (not as big as ProPhoto RGB as you pointed out), one size fits all. Unnecessary quantization will still occur in small gamut input.
Joseph looked at many examples of digital images made with digital cameras, and then edited them in a variety of ways and looking hard at how colors are moved around by such massaging. He remained entirely input centric in the approach to the design of his master Dcam spaces, and specific to digital camera input. There are 5 of them in total, from Dcam 1 (tiny gamut) to Dcam 5 (absolutely gigantic), so the discerning photographer may select the smallest possible space that encompasses all the colors of any given image. For example, a foggy grey picture would require Dcam 1, while Robert's picture would be better served by Dcam 3 at least. Joseph also designed a unique 1024 tone response curve to better match the perceptual linearity of the way the human eye sees, which coincidentally is a better match to a profiled inkjet printer's TRC, minimizing quantization errors during the conversion. He rejected gamma curves for being too flat near black.
Since we are talking about saturation here, I should say that Joseph has also designed what he calls "chroma variants", which I find to be far superior to any method of dealing with the colorfulness of my pictures. They exhibit almost no tonal shifts and hue shifts, unlike the saturation tools found in PS and LR, especially for dealing with yellow greens, where increasing saturation there always causes yellow to shift toward green and drives colors toward clipping far too easily.
-
I'm assuming you don't have some technique to use the selective color adjustment layer to create a saturation mask?
Robert
Of course I do.
There are probably 5 or 6 ways to create what others call a "saturation mask" in Photoshop. I prefer the term "chroma masking". All of them do not create accurate chroma masks (https://forums.adobe.com/message/1944670), except for the selective color method.
The selective color method is as follows:
1. New Selective Color Adjustment Layer
2. Absolute mode
3. In the color selection dropbox, all colors set black slider to 0%
4. All neutrals set black slider to 100%
5. Generate the mask from any one of the channels in the channels panel.
-
A big issue. This is a big reason Photoshop divorced your specific display and how you edit the numbers and made working (editing) space agnostic (but display-like) color spaces back in Photoshop 5.
You're allow ignoring colors that could be out of that display gamut but defined from the raw data by virtue of the working space you select at the time of rendering from raw. It's why Adobe raw converters have a big honking and to some degree dangerous processing space.
Yes, actually I'm not too pushed about this as Adobe RGB is really close to my monitor gamut, so I would need to be working with very saturated colors before I would risk not seeing them (which is a point you made in an earlier post). I would really be more interested in limiting my working space so that it's within my printer/paper space, so that, to the extent possible, I print what I see and I see what I print.
But again, this is really a learning exercise for me ... I'm just trying to understand what is and what isn't possible so that I don't make stupid mistakes.
Robert
-
You want to make it loud at the digital source? (yellow flower? Rhino remaster of Chicago V album?) Learn to know when you've screwed it up and then learn what tools to use to bring it back at the Raw source. You have to hear, think and feel the sound or image as it should look or sound on output be it a print or as CD audio.
Why are you blaming OOG on why you can't enhance it? Almost every image I work on in ProPhotoRGB space and attempt to edit in order to make it loud and brilliant ALWAYS shows clipped data converting to sRGB. Loudness Wars! OOG! It's all the same.
You're problem is not OOG. It's that you haven't learned to use the editing tools and how they work and behave in relation to your perception to get you the look you want to convey as you remember the scene which is rarely ACCURATE. It's not your fault. It's the limits of how the software is designed to make it easy to use for those that don't have the time to figure this out.
I see you're having the same difficulties in your LR vs PS edit of the yellow flower. It's a dull, dim and flat looking image and you want to give it some pop. OOG concerns are not where to look.
Hi Tim,
As I said when I posted the image of the flower, I didn't pick it because I think it's a beautiful image or a well-processed image (actually, I think it needs to be binned :)). I also think it can be simply improved just by adjusting the white balance, which, as has been pointed out, is much too warm. The reason I picked it is that it does have some quite out-of-gamut colors and I am interested in OOG because that is one of the areas that messes up the output. OOG causes Perceptual to shift all the colors and it causes Relative to clip them to the nearest in-gamut color (as we all know). How exactly this is done is out of my personal control because it depends on the CMM and the output profile. So, I do think that it is a good thing to keep the colors in gamut if possible, or at least to be aware of what can happen if you leave them out of gamut. Of course, soft-proofing helps a lot here and if it shows that all is well, then fine, there's no need to sweat the small stuff.
At the end of the day, what I may get from all of this is simply an awareness of what I may be doing when I, for example, use the Camera Raw Filter in Photoshop: The ACR image (I assume) will now be in ProPhoto (or equivalent), whereas my image might have been in Adobe RGB. I might then increase the luminance of the yellow, all seems well in ACR ... but unbeknownst to myself I have now pushed the image out of gamut.
Your points are well made though: I do agree that having a 'feel' for the image is the most important thing, and I also agree that it takes a long time for this to mature (assuming it ever does :)). But I also think that part of getting this 'feel' is understanding what, as you point out, things like the Exposure slider, White slider, Highlights sliders do and how they differ from each other. In other words I think we need to understand our tools.
Finally, if an artist wants to print highly saturated colors ... well then, that's his prerogative, and whether you or I like his work is essentially irrelevant (to my mind, at any rate). What he needs to understand is how to get the look he wants - and why his print just doesn't match what he sees on his monitor.
Robert
-
Of course I do.
There are probably 5 or 6 ways to create what others call a "saturation mask" in Photoshop. I prefer the term "chroma masking". All of them do not create accurate chroma masks (https://forums.adobe.com/message/1944670), except for the selective color method.
The selective color method is as follows:
1. New Selective Color Adjustment Layer
2. Absolute mode
3. In the color selection dropbox, all colors set black slider to 0%
4. All neutrals set black slider to 100%
5. Generate the mask from any one of the channels in the channels panel.
Hi,
At first glance, I fail to see how this specifically addresses the clipping caused by profile conversions, other than allowing to reduce total saturation for a few colors.
Cheers,
Bart
-
Hi,
Just to show that I do sort of understand that there are different ways to improve images, and not all require getting them into Photoshop (:)), here is a modified version of the flower I posted:
(http://www.irelandupclose.com/customer/LL/W20865.jpg)
compared to the previous version:
(http://www.irelandupclose.com/customer/LL/W20865-Exported-to-sRGB-from-Lightroom.jpg)
All I did here was to crop, adjust the white balance and darken and desaturate the background, soften the green bits (by reducing the Clarity) and desaturate them a bit. I also reduced the saturation in the yellows and reds in the flower and increased the overall contrast of the image. I did all of this in Lightroom.
I agree (before I get jumped on :)) ... that it still isn't beautiful ... this photo never will be (at least not in my hands, if for no other reason than it isn't worth wasting time over IMO).
But, I think you will, hopefully, agree that the flower appears more saturated/vibrant, even though it is less so. In fact the Lightroom image is pretty much fully inside sRGB and there is nothing to be gained by taking into Photoshop (well, not unless we want to do more things with it that can't be done in Lightroom, of course).
So, as the old saying goes, there's more way than one to skin a cat :)
Robert
-
At first glance, I fail to see how this specifically addresses the clipping caused by profile conversions, other than allowing to reduce total saturation for a few colors.
Just to clarify - I mentioned this technique of creating a saturation mask only because Robert mentioned that he creates them using the HSL plugin, which is a less accurate method of doing so. He wasn't aware of the details of this technique so I elaborated there. Of course a mask on its own cannot address clipping, it must be used in conjunction with other edits. To target specifically OOG colors, your method of creating an OOG mask is certainly a good way.
But, I think you will, hopefully, agree that the flower appears more saturated/vibrant, even though it is less so.
This attempt is much better! I believe that relative colorfulness is vital to making things appear more saturated than they are, and also proper white balancing. Now the centre yellow bit of the flower is not competing with the previously overly warm surroundings, so it looks cleaner and brighter and more colorful now. The greens also look much more natural.
I am also a believer that getting a feel for your tools and developing a refined taste for tone and color is more important. I would not worry so much about working with colors that may not be displayed. There's no way that a red would shift from red to green for example. What you should be afraid of is clipping colors in your working space of choice. You end up with featureless details, they are gone forever. A judicious photographer would never go completely crazy on the saturation slider anyway. Soft, natural looking renditions actually appear much cleaner and easy on the eyes. Like in your example, they can even cause the illusion of being more strongly coloful too.
Having excellent printer profiles with top notch gamut mapping to deal with OOG colors is preferred for me. I wouldn't want to work within the gamut boundaries of the printer, simply because that gamut changes all the time. Finding a better media setting, changing the ink load, changing the paper, changing your method of building your custom profiles etc all changes the output gamut. Printing technology advances over time too.
-
Soft, natural looking renditions actually appear much cleaner and easy on the eyes. Like in your example, they can even cause the illusion of being more strongly coloful too.
Having excellent printer profiles with top notch gamut mapping to deal with OOG colors is preferred for me. I wouldn't want to work within the gamut boundaries of the printer, simply because that gamut changes all the time. Finding a better media setting, changing the ink load, changing the paper, changing your method of building your custom profiles etc all changes the output gamut. Printing technology advances over time too.
Yes, I completely agree Samuel.
Regarding printer profiles ... I have a Z3100 which has a built-in spectrometer and it seems to calibrate well and create quite good profiles. I've also used ArgyllCMS with an i1Pro2 and it seems to get a better black point and wider gamut than either the Z3100 or the canned profiles from Canson (I've only tried this on the Canson Platine and Photo High Gloss - which I use for acrylic-mounted pictures). I'm also going to try these two papers using i1Profiler. I check out the profiles using GamutVision (Imatest).
Do you or does anyone have experience of the pros-and-cons of the different profiling tools for different papers ... and what can be done to improve the profiles (for example less/more patches, FWA compensation or not for papers that use optical brighteners (like the Canson Photo High Gloss) ...)?
Thanks!
Robert
-
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
With many of my images, my experience with letting the CMS manage out of gamut colors is similar to that of the DigitalDog. As an example, i have a still life image of some flowers rendered into ProPhotoRGB. Many of the colors are out of the gamut of my Epson 3880 with Epson Premium Glossy paper.
The gamut warning in Photoshop (or LR) is not particularly helpful, since there is no indication of the extend to which the colors are out of gamut--just a little or by a wide margin.
(http://bjanes.smugmug.com/Photography/LR-Softproofing/i-73P8czL/0/O/PhotoshopGamu%3Bt.png)
ColorthinkPro can show pseudocolor gamut map, but the process is laborious. One must downsize to small images because of the slow performance of the program, convert to a color list and then active the DeltaE facility. Results for the image in consideration is shown.
(http://bjanes.smugmug.com/Photography/LR-Softproofing/i-7Z7jQjB/0/XL/ColorThink-XL.png)
The Gamutvision program by Norman Koiren, the author if Imatest, can create a pseudocolor mapping of the extent of the out of gamut colors directly and the results are here. I would encourage interested readers to look at this program, which is modestly priced in comparison to ColorThinkPRo.
(http://bjanes.smugmug.com/Photography/LR-Softproofing/i-bF7v5t2/0/L/Gamutvision-L.png)
It would be helpful if LR and Photoshop would create such out of gamut displays. However, in this case, I get the best results by printing the image with relative colorimetric and letting the out of gamut colors clip. They do not appear blocked up in the print. The colors are out of gamut to the extent that perceptual rendering makes little difference.
Bill
-
We have to pay very close attention to the display, the weak link, as we edit. We might be altering OOG numbers that exist that we can't see. Here's where an overlay in three straights with opacity control (let me see the detail that's OOG, don't cover it with a Red stain) would be really useful. And I but Eric could do all this. But how many customers would care or aid considering the engineering other costs? I still hear more complain about dark prints, that's a bigger fish to fry IMHO
Going back to OOG, there might be a way to do this using ColorThink and Photoshop....
-
We have to pay very close attention to the display, the weak link, as we edit. We might be altering OOG numbers that exist that we can't see. Here's where an overlay in three straights with opacity control (let me see the detail that's OOG, don't cover it with a Red stain) would be really useful. And I but Eric could do all this. But how many customers would care or aid considering the engineering other costs? I still hear more complain about dark prints, that's a bigger fish to fry IMHO
Going back to OOG, there might be a way to do this using ColorThink and Photoshop....
Such an overlay would be nice, but that fact that it is not available may be that most of are satisfied with what we have and have been getting good results without laborious attempts at manual gamut mapping, which often make the image look worse. The display is often the weak point, as you point out, but there is a gamut shape mismatch between the output space of the display and printer. As an example, here is a Colorthink plot of my printer (solid color), my display (wireframe), and the previously discussed image . At high luminance values, the display actually has a larger gamut than the printer. The printer excels in low luminance saturated greens, but such colors are not present in the current image and the extent to which ones perception of these low luminance colors is sensitive is in question. Intuitively, I would think that high luminance colors would likely attract most notice with observers.
-
The Gamutvision program by Norman Koiren, the author if Imatest, can create a pseudocolor mapping of the extent of the out of gamut colors directly and the results are here. I would encourage interested readers to look at this program, which is modestly priced in comparison to ColorThinkPRo.
Bill
Yes, GamutVision is really excellent (can't compare with ColorThink Pro as I don't use it). In fact, one way of getting a good saturation map is to use the 'Read Image for Analysis' feature with the analysis set to Delta-C*ab with a Grayscale color map.
(http://www.irelandupclose.com/customer/LL/gm.jpg)
The grayscale saturation map can then be copied into a mask and resized to fit. A little laborious, but not so bad ... and certainly using GamutVision to check out the image does give a load of very interesting information.
For example, this 3D plot of Input to Output (in this case the image from sRGB to print) shows that the OOG pixels are mostly in the red and green, but at quite low luminance (the lines ending in circles show the transform, with the size of the circles giving an indication of the frequency of the color):
(http://www.irelandupclose.com/customer/LL/gm2.jpg)
Robert
-
We have to pay very close attention to the display, the weak link, as we edit. We might be altering OOG numbers that exist that we can't see. Here's where an overlay in three straights with opacity control (let me see the detail that's OOG, don't cover it with a Red stain) would be really useful. And I but Eric could do all this. But how many customers would care or aid considering the engineering other costs? I still hear more complain about dark prints, that's a bigger fish to fry IMHO
Going back to OOG, there might be a way to do this using ColorThink and Photoshop....
Hi Andrew,
You've mentioned, a couple of times, the problem of potentially not being able to see OOG colors because the monitor gamut is smaller than the working space. However, when I suggested modifying the working space to fit the monitor gamut (effectively using the monitor gamut as the working space) you seemed quite against the idea. I can see why using non-standard working spaces is generally not a good idea, but I don't understand what the danger is if it's done with awareness.
If we do the final edit in ProPhoto we're at great risk of being OOG both on the monitor and printer. So surely it's better to do the final edit in Adobe RGB; and by the same token even better to do it in the monitor color space, because then we only need to worry about the print OOG.
As Bill points out, the paper gamut is often bigger in places than the monitor gamut. Here, for example you can see that the printer gamut is a bit bigger in the higher luminance orange-greens and lower luminance green-blues ... but everywhere else the monitor gamut is much bigger (and this is a really good paper!).
(http://www.irelandupclose.com/customer/LL/gm4.jpg)
So I would have thought that the final edit would be much better done with the image converted to the printer profile, with the awareness that there are some colors, as in the plot, that are potentially dangerous. I understand that there are issues with this (in the same way that soft-proofing should be used with caution because the eye doesn't adapt chromatically to a monitor as it does to paper). But I don't understand what else could be a problem. If you have the time I would really appreciate an explanation.
Robert
-
As Bill points out, the paper gamut is often bigger in places than the monitor gamut.
Exactly!
-
Exactly!
Meaning that it only matters if the image has very saturated colors in the C/M/Y axes, for which the printer has specific inks and the display only has R/G/B primaries ...
Cheers,
Bart
-
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
Hi Bart,
I wanted to go back to this technique because it's really quick and easy using an action - and it makes sense to me. You are specifically targeting OOG colors (so it's not just a saturation map as with the HSL filter technique). As I mentioned, I thought I had invented this technique myself ... ah well, Lamark must have felt like this when Darwin published 'The Origin' ;D
Anyway, what I found is that the technique doesn't just give OOG colors, but also dark-point clipping, so there's a need to do a small levels adjustment on the mask to remove the dark shadow (but now that I say that I see that I'm being ridiculous because these dark areas won't be printed anyway :)).
What I would like to understand (and from a post I saw on another thread I can see that you know your maths) is what happens exactly when we use this technique. I'll try to explain what I think happens and perhaps you would be good enough to set me straight if I've got it wrong.
OK, when we convert from the working space to the paper profile using Relative, every OOG pixel will be shifted to the nearest in-gamut color. What that color is depends on the CMM and the profile, but it could include saturation, hue and lightness shifts. So lets say that a particular pixel gets shifted from red (Lab 50,80,70) to orange (Lab 50,50,70) (could happen, right?).
Then, when we convert back to the working space, the CMM and reverse profile may or may not shift that color again. Let’s say that this particular color is inside the gamut of the print but outside the gamut of the working space. Then there could be a shift to, say, Lab 50,60,70, to bring it back into the working-space. Correct?
If we then use the difference between the round-trip image and the original, we’ll get a difference … but the difference won’t be quite correct.
I assume, and I could be absolutely and entirely wrong here (!!) that in the round-trip, the white point shift that occurs in the working-space to print profile direction will be reversed correctly in the print profile back to working-space conversion. But if it’s not, then there are a whole load of colors that will show a difference even though they aren’t OOG at all. Presumably what actually happens is down to how good the CMM and profile are … but do you know what is supposed to happen?
At any rate this doesn’t mean that the mask that’s generated isn’t 90% correct (and if it is it’s good enough for me!). But I would really like to understand what actually happens (or is supposed to happen) when we convert from one profile to another … and then back again. I would seriously appreciate an explanation … either from you or from anyone who knows and has the time to give it!
Robert
-
If we then use the difference between the round-trip image and the original, we’ll get a difference … but the difference won’t be quite correct.
Most likely not. All the CMM understands is what it is feed, numbers in Lab. It has no idea what source color space built that set of Lab numbers.
-
Hi Bart,
I wanted to go back to this technique because it's really quick and easy using an action - and it makes sense to me. You are specifically targeting OOG colors (so it's not just a saturation map as with the HSL filter technique).
Hi Robert,
Yes, I'm targeting OOG colors because they tend to be pushed to the 255 (in 8-bit) boundary in the smaller gamut colorspace. However, we're not getting only those OOG colors, but also smaller differences e.g. due to converting back and forth between different illuminants and some other color shifts. But the more extreme differences will indeed allow to address the OOG colors.
Anyway, what I found is that the technique doesn't just give OOG colors, but also dark-point clipping, so there's a need to do a small levels adjustment on the mask to remove the dark shadow (but now that I say that I see that I'm being ridiculous because these dark areas won't be printed anyway :)).
Spot on! We are altering colors, so it is more about taming the magnitude of difference, and the relevance of those colors.
The fact that we also get some colors with smaller differences will allow a sort of Perceptual (I'm using this very loosely) adjustment of adjacent colors that were still more or less in gamut. Afterall, we cannot only wrestle the OOG colors into gamut submission, because that would essentially be similar to a Relative Colorimetric intent, and would lose color differentiation/detail.
What I would like to understand (and from a post I saw on another thread I can see that you know your maths) is what happens exactly when we use this technique. I'll try to explain what I think happens and perhaps you would be good enough to set me straight if I've got it wrong.
OK, when we convert from the working space to the paper profile using Relative, every OOG pixel will be shifted to the nearest in-gamut color. What that color is depends on the CMM and the profile, but it could include saturation, hue and lightness shifts. So lets say that a particular pixel gets shifted from red (Lab 50,80,70) to orange (Lab 50,50,70) (could happen, right?).
Then, when we convert back to the working space, the CMM and reverse profile may or may not shift that color again. Let’s say that this particular color is inside the gamut of the print but outside the gamut of the working space. Then there could be a shift to, say, Lab 50,60,70, to bring it back into the working-space. Correct?
If we then use the difference between the round-trip image and the original, we’ll get a difference … but the difference won’t be quite correct.
You've got it. It won't be absolutely correct, but it will be somewhat weighted towards the magnitude of the absolute difference.
I assume, and I could be absolutely and entirely wrong here (!!) that in the round-trip, the white point shift that occurs in the working-space to print profile direction will be reversed correctly in the print profile back to working-space conversion. But if it’s not, then there are a whole load of colors that will show a difference even though they aren’t OOG at all. Presumably what actually happens is down to how good the CMM and profile are … but do you know what is supposed to happen?
Correct again, however, the largest differences will still be in the clipped colors.
At any rate this doesn’t mean that the mask that’s generated isn’t 90% correct (and if it is it’s good enough for me!).
That's it. It won't be 100% correct, but it will have a weighting towards the OOG colors.
But I would really like to understand what actually happens (or is supposed to happen) when we convert from one profile to another … and then back again. I would seriously appreciate an explanation … either from you or from anyone who knows and has the time to give it!
Solutions like Gamutvision and Colorthink will allow to get much closer, however it remains to be seen how that accuracy in converted into a practical solution. Identifying a problem is nice, identifying it very accurately is nicer, but not being able to solve the issue is worthless.
Based on the OOG weighted initial mask, we can adjust the mask, and we can adjust the corrective layer on which that mask will be used. We can make an overall desaturated layer and apply the (adjusted) mask to that, but we can also choose to do something different.
Cheers,
Bart
-
Hi Bart,
Many thanks for taking the time to answer my questions!
Here is a comparison between an error mask created using GamutVision (dE94) and Bart's OOG technique (BOOG ... previously called ROT for Robert's OOG Technique :)).
The top mask is BOOG and the bottom one is GV:
(http://www.irelandupclose.com/customer/LL/GVvCD.jpg)
As you can see they are very close.
The only areas that might need adjustment in this particular image are the ones that are very bright, actually, so if I was adjusting an image with these masks I would apply a levels adjustment to the BOOG mask, like this:
(http://www.irelandupclose.com/customer/LL/CD-levels.jpg)
and probably also apply a bit of blurring.
So really good on this sample of one!
I might write a script to make it easier to use (than actions) with different profiles (or perhaps picking the profiles automatically from the working space and Soft-Proof selection).
Robert
-
Here is a comparison between an error mask created using GamutVision (dE94) and Bart's OOG technique (BOOG ... previously called ROT for Robert's OOG Technique :)).
The top mask is BOOG and the bottom one is GV:
[...]
As you can see they are very close.
Hi Robert,
Thanks for that comparison with GV. While not perfect, my suggestion is apparently not all that bad, especially for a free solution that can be scripted/'action'ed and also works with older versions of Photoshop.
Cheers,
Bart
-
Hi Bart,
Yes, it's pretty good. But ... the question is what do you do once you have the mask! I find that Hue/Saturation does a pretty bad job of it. Vibrance seems a lot better. Selective Color is also not so bad. For this particular image I found that a combination of Vibrance (which fixes the yellows pretty well) and Selective Color (which finishes off the OOG greens) is good.
After all, there's not much point in using this sort of technique if the CMM does a better job all on its own!
This could be why Adobe hasn't bothered with an OOG mask: it's interesting, but is it useful? The jury's still out for me, although I suspect that it has its place, used with discretion :).
Robert
-
... This could be why Adobe hasn't bothered with an OOG mask: it's interesting, but is it useful?...
I think Adobe realized the problem has been solved long time ago. More precisely, when Shakespeare wrote a play about it: "Much Ado About Nothing" ;)
-
I think Adobe realized the problem has been solved long time ago. More precisely, when Shakespeare wrote a play about it: "Much Ado About Nothing" ;)
Could be :). I think like Socrates I am becoming wise ... because I edging towards knowing that I do not know :).
-
I thought I would try to summarise what I've learnt here about OOG issues.
1. When we work in Lightroom we are working in a huge gamut (Melissa RGB), much bigger than the web or monitor or printer. So it’s very easy to push the image OOG for the intended destination.
2. When we import the image into Photoshop from Lightroom, we should import into ProPhoto to ensure that there is no clipping, as ProPhoto has the same gamut as Melissa RGB.
3. Before conversion to a destination profile (or to another working space like Adobe RGB) it’s very important to do a soft-proof to see how the conversion alters colors. The OOG warnings in Lightroom and Photoshop are useful as a pointer where to look, but not for much more as they don’t give an idea of how much or how little individual pixels are OOG.
4. In general, the CMM does a better job of converting OOG colors to in-gamut colors than attempting manual adjustments.
5. If manual adjustments are necessary because the CMM has not done a proper job, then:
a. The first thing is to look at the image to see if an alternative adjustment could yield a better result that would not have the same OOG problems (for example, simulating highly saturated colors by having low-saturation areas nearby).
b. Less is more: so if possible, it should be done selectively, only where the CMM has failed.
c. An OOG mask can be produced using GamutVision (possibly ColorThink Pro also?) or using the OOG technique explained by Bart in this thread, or even manually.
d. Using the OOG mask, combinations of Hue/Saturation, Vibrance and Selective Color adjustments (and maybe others!) can be used selectively to corral the pixels back into gamut. All that’s needed is to bring them reasonably back into gamut (again, less is usually more) … the CMM should be able to do the rest of the job. The idea in general is to fix those areas that look badly flattened (or clipped) in the soft-proof: these are likely to be fairly large areas of fairly uniform color.
6. Where it is not possible to process the image as desired without ending up with badly OOG regions, an alternative is to convert the image to the destination space (making sure that the image is mostly within gamut before the conversion) and then to finalise the adjustments in the destination space. This will ensure that there are no OOG colors in the output file and it will also make it possible to see visually how colors are being squashed towards the gamut boundaries. One thing to bear in mind here is that the monitor gamut may be smaller than the destination space, so it may not always be possible to see what’s happening. In this case it may be useful to soft-proof to the monitor profile – the Photoshop OOG warning will give an indication of where we can no longer see the changes we’re making.
7. Using a tool like GamutVision or ColorThink Pro is really useful as it shows where there are mismatches between the source and destination profiles, how good the profiles are, where to watch out for OOG problems … and a lot more.
Please correct me if I’ve left things out or if I’ve said things that are not true!
And thanks for your help and advice!!
Robert
-
I thought I would try to summarise what I've learnt here about OOG issues.
[...]
Hi Robert,
Seems like a fair summary, it's mostly how I also see things. The only exception is with point 4, where Photoshop uses a Relative Colorimetric intent (which simply clips to gamut boundaries) even when Perceptual is selected. That's not a good job, that's brutal.
Cheers,
Bart
-
Hi Robert,
Seems like a fair summary, it's mostly how I also see things. The only exception is with point 4, where Photoshop uses a Relative Colorimetric intent (which simply clips to gamut boundaries) even when Perceptual is selected. That's not a good job, that's brutal.
Cheers,
Bart
Thanks Bart - it's good to know I'm not too far off-course.
My understanding is that any conversion from, say ProPhoto or Adobe RGB to, say sRGB (actually I think it's to any matrix-based profile) is always Relative (even if Perceptual is specified) ... so there's no point in trying out one or other intent in conversions with these types of profile. As you say, the clipping in that case is going to be whack, bye-bye! So, actually, converting an image for the web is one of the places one has to be the most careful (now that I think of it ... thanks for pointing it out!).
However with profiles that use LUT tables (which would include all print profiles, I would think), the conversion is done by whatever CMM is picked (Adobe ACE, for example) using the profile tables. Then what happens is not necessarily just a clipping ... there could also be a hue and lightness change, as well as a saturation change (at least it seems like that when I've compared an image before and after conversion). In that case the clipping will depend on the conversion intent used ... and also on the CMM and tables ... and if these are well implemented the clipping shouldn't be too brutal. Do you agree?
Robert
-
1. When we work in Lightroom we are working in a huge gamut (Melissa RGB), much bigger than the web or monitor or printer. So it’s very easy to push the image OOG for the intended destination.
To clarify, Melissa RGB is the color space for the histogram and numbers you see outside of soft proofing, it's ProPhoto RGB primaries with an sRGB like tone curve. The internal color space (more important) that is used for the processing has no name. It's also ProPhoto RGB primaries but uses a 1.0 TRC. It isn't what you're seeing in the Histogram or RGB numbers. What the OOG colors use as a source space, which IMHO is moot, it's not accurate, is something maybe Eric can define.
-
Thanks Bart - it's good to know I'm not too far off-course.
My understanding is that any conversion from, say ProPhoto or Adobe RGB to, say sRGB (actually I think it's to any matrix-based profile) is always Relative (even if Perceptual is specified) ... so there's no point in trying out one or other intent in conversions with these types of profile. As you say, the clipping in that case is going to be whack, bye-bye! So, actually, converting an image for the web is one of the places one has to be the most careful (now that I think of it ... thanks for pointing it out!).
That's exactly why I mentioned it, in particular conversions for Web publishing (typically to the small gamut sRGB colorspace) need a second look. Loss of feature detail may, or may not, be important for certain image content. Small tweaks (saturation, or even hue, or lightness) in LR, based on the Proof preview, may already be enough. The goal is not to prevent clipping all together, that would be detrimental to overall image quality. All we need to do is mitigate the detrimental effects, if any. Going from a wide gamut to a narrow one is supposed to challenge the gamut boundaries if we start with a colorful image.
However with profiles that use LUT tables (which would include all print profiles, I would think), the conversion is done by whatever CMM is picked (Adobe ACE, for example) using the profile tables. Then what happens is not necessarily just a clipping ... there could also be a hue and lightness change, as well as a saturation change (at least it seems like that when I've compared an image before and after conversion). In that case the clipping will depend on the conversion intent used ... and also on the CMM and tables ... and if these are well implemented the clipping shouldn't be too brutal. Do you agree?
Yes.
Cheers,
Bart
-
I thought I would try to summarise what I've learnt here about OOG issues.
4. In general, the CMM does a better job of converting OOG colors to in-gamut colors than attempting manual adjustments.
Robert,
Thanks for an excellent analysis. Current CMMs are dumb--that is, with perceptual rendering, they do not look at the actual colors in the image, but merely perform a predetermined amount of compression to the color gamut whether or not such a compression is needed. This is explained well by Mike Chaney in a nearly 10 year old post (http://ddisoftware.com/tech/articles/july-2005-understanding-rendering-intents/). Contrary to what some believe, the gamut of the image is not compressed to the gamut of the printer, and clipping of the most out of gamut colors may occur.
What is needed is an intelligent CMM that looks at the colors actually in the image in order to determine the amount of compression needed and which colors need to be compressed. This ICC post (http://www.color.org/whyusev4.xalter) mentions the possibility of an intelligent CMM--see the link V4 raison d'etre... As far as I know, such an intelligent CMM is not available for general use, but there is some hope that such a CMM may be available sometime in the future.
Regards,
Bill
-
To clarify, Melissa RGB is the color space for the histogram and numbers you see outside of soft proofing, it's ProPhoto RGB primaries with an sRGB like tone curve. The internal color space (more important) that is used for the processing has no name. It's also ProPhoto RGB primaries but uses a 1.0 TRC. It isn't what you're seeing in the Histogram or RGB numbers. What the OOG colors use as a source space, which IMHO is moot, it's not accurate, is something maybe Eric can define.
Enough to give anyone a headache!! I suppose there has to be some rationale to all of this, but it seems that it's piling complexity on top of complexity ... and one wonders how the poor CMMs (not to mention us) can hope to see the wood from the trees!
Robert
-
Enough to give anyone a headache!! I suppose there has to be some rationale to all of this, but it seems that it's piling complexity on top of complexity ... and one wonders how the poor CMMs (not to mention us) can hope to see the wood from the trees!
Robert
There is a rationale for the Melissa space for the LR readouts and histograms. Editing in a linear space has many advantages, but a main disadvantage is that a linear space is not perceptually uniform. A small change in the sliders would have a much greater impact on the darker tones than the highlight tones so that the sliders would be touchy (overly sensitive) in the shadows. The Melissa response for the sliders and histograms enables one to edit with a linear tone curve, but with the appearance to the user that he/she is using a more perceptually uniform space with a sRGB tone curve.
Bill
-
What is needed is an intelligent CMM that looks at the colors actually in the image in order to determine the amount of compression needed and which colors need to be compressed.
Thanks Bill.
I can't help feeling that what we currently have is a solution that has grown (slowly and painfully) to fix a problem (or rather, lots of problems) and what may be needed is to clear the decks and start again. If you think about it: we have an input device that's wrong; a display device that's wrong; an output device that's wrong ... and so what we do is to try to fix the wrongness in all of them so that they can sort of talk to each other. It's like UN translators using Esperanto as an intermediate language!
Graeme Gill of ArgyllCMS said this to me today: "Figuring out what the applications that use the profiles are actually doing is the hard part because typically the software vendors give you no clue, and hide behind inscrutable "user friendly" buttons such as 'Simulate Paper Color'".
He's a guy who's a giant in this business, and you can just hear the frustration in his words!
I can't see any particular reason why all devices couldn't have the intelligence to understand a common language directly ... and for it to be their problem to follow the orders (to the best of their ability, taking into account their inherent limitations).
But I suppose that would be akin to getting the world to speak one language ... maybe your intelligent CMM has better chances of seeing the light of day! It remains to be seen how 'intelligent' it manages to be :)
Robert
-
There is a rationale for the Melissa space for the LR readouts and histograms. Editing in a linear space has many advantages, but a main disadvantage is that a linear space is not perceptually uniform. A small change in the sliders would have a much greater impact on the darker tones than the highlight tones so that the sliders would be touchy (overly sensitive) in the shadows. The Melissa response for the sliders and histograms enables one to edit with a linear tone curve, but with the appearance to the user that he/she is using a more perceptually uniform space with a sRGB tone curve.
Bill
Thanks for that explanation Bill. So effectively we can ignore what happens below Melissa RGB, right? That's just the internals ... and it doesn't introduce any risks that we need to be aware of?
Robert
-
Enough to give anyone a headache!! I suppose there has to be some rationale to all of this, but it seems that it's piling complexity on top of complexity ... and one wonders how the poor CMMs (not to mention us) can hope to see the wood from the trees!
I think the rationale for programs like Lr is to provide a simpler user experience by hiding the complexity. Ps takes the other approach for the most part, exposing it completely (if you know where to look). The advantage of the Lr approach is that it provides an easier-to-learn alternative. The disadvantage is that advanced users sometimes can produce better results when they know what's going on under the covers (or inside the black box), and the Lr approach is much less transparent than the Ps approach.
If you want a more transparent raw developer, you might look at Iridient (http://www.iridientdigital.com/). Only runs on the Mac, though, and doesn't have the organizer/printing/publishing capabilities of Lr.
Jim