Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Robert Ardill on July 09, 2014, 12:09:30 pm
-
I apologize in advance if this topic has already been discussed, as it no doubt has.
I would prefer to use Beta RGB as a working space than ProPhoto or Adobe RGB because ProPhoto is just too big IMO (colors not visible to the eye, more likely to have quantization errors than in a smaller working space) and Adobe RGB is just a bit small (so that there is the possibility of clipping colors that are printable, and there is little elbow-room). Unfortunately Lightroom doesn't allow the selection of the Lightroom working space nor does it allow opening the image into Photoshop in anything except sRGB, AdobeRGB or ProPhoto RGB.
So I have to work in Lightroom's version of ProPhoto, open into Photoshop as ProPhoto ... and then convert to Beta RGB: this is my normal workflow. As long as there are no colors that are outside the Beta RGB space there is no damage to the image.
One thing I didn't realize, and which is very nice I think, is that if the image is opened as a Smart Object and immediately converted into Beta RGB (or the workspace of choice), then editing the Smart Object in ACR is constrained by the Photoshop working space, not the ACR working space. So if I edit the Smart Object from the Beta RGB workspace, all the edits in ACR are constrained by Beta RGB.
Since I always use a Lightroom -> Photoshop -> Lightroom -> Print/Web workflow (in other words, all my images go through Photoshop), I can delay (some of) the raw processing until I am in Photoshop, doing it in ACR rather than Lightroom, all safely in Beta RGB.
Of course there is the disadvantage of much bigger file sizes because of the embedded Smart Object.
It's a workaround that I think will work for me for most of my images ... but clearly this wouldn't be of interest to anyone who primarily works within Lightroom.
I would be interested in your feedback on this workflow and especially if you see reasons why this is not a good way to do things.
Robert
-
In the CC version of ACR (v8.5) you can convert into any color space for which your computer has a profile. For some reason LR5 does not permit this.
kirk
-
I have been using Beta RGB as my working space for years, quite successfully, for all my color work from digital captures. I decided on it for pretty similar reasons as you. (for monochrome or B&W output, 16-bit Beta RGB is obviously overkill, so those are 8-bit sRGB)
However, I rarely use Edit in Photoshop straight out of LR, because as you note, the choice of working spaces is limited (and yes, ACR takes a different route here). Instead, I Export > Tiff or .psd, which allows exporting directly to Beta RGB, 16-bit. Anything that needs a visit to Photoshop gets this treatment.
My workflow is probably a bit different, due to the fact that it started before LR appeared, so I have a substantial body of legacy .psd's & .tif's, printed through either Photoshop or RIP software. This influenced me to eventually develop two LR catalogs - one is exclusively raw capture files, the other is "prints", the images that merited further work in PS, and were finalized for output (along with legacy files).
I must admit to being a bit reluctant to go the smart object route - I use them during editing, but rasterize at conclusion, wanting to avoid any possible nasty surprise years hence…
my 2 cents, YMMV
John
JWL Images
Emeryville
-
I would prefer to use Beta RGB as a working space than ProPhoto or Adobe RGB because ProPhoto is just too big IMO (colors not visible to the eye, more likely to have quantization errors than in a smaller working space) and Adobe RGB is just a bit small (so that there is the possibility of clipping colors that are printable, and there is little elbow-room).
So, you know for a fact that ProPhoto RGB is "too big"? You've actually seen "quantization errors" using ProPhoto RGB? Or is what you "believe" based upon your internet reading?
I ask because I've never seen any quantization errors when working in a ProPhoto RGB color managed workflow...
If you were on Bruce Lindbloom's web site reading about it, you should note that page was last updated on Sun, 20 Apr 2003 09:06:14 GMT which was about the time that Adobe released Camera Raw v1. There is a reason why Thomas Knoll chose ProPhoto RGB and linear gamma as the internal working space for ACR and then LR.
-
I must admit to being a bit reluctant to go the smart object route - I use them during editing, but rasterize at conclusion, wanting to avoid any possible nasty surprise years hence…
Hmm - interesting point, which ties in to CC and backward compatibility. I can see myself having to do a batch flatten to tiff when I can no longer afford CC :).
Robert
-
So, you know for a fact that ProPhoto RGB is "too big"? You've actually seen "quantization errors" using ProPhoto RGB? Or is what you "believe" based upon your internet reading?
I ask because I've never seen any quantization errors when working in a ProPhoto RGB color managed workflow...
If you were on Bruce Lindbloom's web site reading about it, you should note that page was last updated on Sun, 20 Apr 2003 09:06:14 GMT which was about the time that Adobe released Camera Raw v1. There is a reason why Thomas Knoll chose ProPhoto RGB and linear gamma as the internal working space for ACR and then LR.
Well Jeff, as it happens I'm an engineer with post-graduate degrees in computer science, so I don't have to entirely rely on the internet to inform me of these things, fortunately :)
To be honest, I'm not really concerned about quantization errors with ProPhoto (although it doesn't take advanced maths to figure out that a resolution of 1 in 65535 is better than 1 in 55,000, so the smaller your working space the better use you make of the bits available to you and the more you manipulate the image, the truer this is).
What is of concern to me is that it is too easy in ProPhoto to end up with colors that are completely out of gamut for viewing or printing purposes. To have to turn on soft-proofing with gamut warning during editing is a nuisance: for me it's better to use a working-space that is more limited. Of course, even though Beta RGB is smaller than ProPhoto, it's still possible to end up with OOG colors for the destination, so even though it's better than ProPhoto from an OOG point-of-view, it isn't perfect.
I've no doubt Thomas Knoll had good reasons for choosing ProPhoto with a gamma of 1.0 for Lightroom. But he could have allowed export to Photoshop using any icc profile (as does ACR, presumably with Thomas' blessing), and he could have implemented a user-selectable gamut constraint within Lightroom. What I mean by that is that it would be very useful to be able to select, say, Adobe RGB as the limiting gamut in Lightroom: what goes on under the hood isn't my concern ... but as a user I want to be able to work safely in a more constrained setting. I very much doubt I'm the only person who feels that way.
But I think you missed the point of my post: there is a work-around to this problem, thanks no doubt to Thomas Knoll: and that is to open the raw image as a smart object into Photoshop, convert to whatever working-space takes your fancy, and then perfectly safely edit the raw object in ACR :)
Robert
-
In the CC version of ACR (v8.5) you can convert into any color space for which your computer has a profile. For some reason LR5 does not permit this.
kirk
Very good point ... it would be nice if Adobe could keep Lightroom and ACR in sync! It beats me why ACR isn't just the develop module of Lightroom ... but maybe Adobe likes to duplicate work.
BTW ... another excellent improvement with ACR 8.5 as a result of allowing any profile, is the ability to soft-proof to any working space or to any destination profile (while editing a raw smart object). Great!
Now, if they could add a button Limit To Profile Gamut I would be in heaven.
Robert
-
But he could have allowed export to Photoshop using any icc profile (as does ACR, presumably with Thomas' blessing), and he could have implemented a user-selectable gamut constraint within Lightroom.
You can select any profile using the Export command but not Edit In (which might be nice).
-
What is of concern to me is that it is too easy in ProPhoto to end up with colors that are completely out of gamut for viewing or printing purposes. To have to turn on soft-proofing with gamut warning during editing is a nuisance: for me it's better to use a working-space that is more limited. Of course, even though Beta RGB is smaller than ProPhoto, it's still possible to end up with OOG colors for the destination, so even though it's better than ProPhoto from an OOG point-of-view, it isn't perfect.
I think you are far too enamored with OOG issues...any digital camera will be capturing colors that can not be seen on prints and displays. What's important is to use soft proofing to see what the colors will look like if they are OOG and do something about it.
So, you admit that Beta RGB is still too wide for displays and prints and it's just as easy to drive colors OOG as it is in ProPhoto RGB? So, you are still clinging to the ProPhoto RGB is too large and inefficient why? Is your argument theoretical or practical? Can you show how ProPhoto RGB is too big on a practical basis? I don't care about the math...I care about images. Show me where an image is better with Beta RGB vs ProPhoto RGB.
-
I think you are far too enamored with OOG issues...any digital camera will be capturing colors that can not be seen on prints and displays. What's important is to use soft proofing to see what the colors will look like if they are OOG and do something about it.
So, you admit that Beta RGB is still too wide for displays and prints and it's just as easy to drive colors OOG as it is in ProPhoto RGB? So, you are still clinging to the ProPhoto RGB is too large and inefficient why? Is your argument theoretical or practical? Can you show how ProPhoto RGB is too big on a practical basis? I don't care about the math...I care about images. Show me where an image is better with Beta RGB vs ProPhoto RGB.
Well Jeff,
I'm glad you didn't ask me to do anything too complicated :).
So, here's a simple example, and you can replicate it yourself easily.
To make it easier to see, take an image that is quite saturated (so it will have OOG colors for the destination). Duplicate it. Then convert the original to the destination profile using Perceptual. To make the test more obvious, use a destination profile that has a small gamut, like an Epson Enhanced Matte profile for example. Then convert the copy to Beta RGB (it will be a Relative conversion of course). Convert that to the Epson Enhanced Matte profile (using Perceptual). Then compare the two images.
Here is an example for you, to save you the trouble:
(http://www.irelandupclose.com/customer/LL/pp-brgb.jpg)
The top image is the one that suffered a direct ProPhoto to destination hit. The bottom one is the one that went through Beta RGB. The reason why the ProPhoto to Destination image looks so bad (OK, I admit, they both look bad! but the top one has lost most of its (very oversaturated) colors) is that the Perceptual shift squeezes the whole ProPhoto gamut into the Epson Enhanced Matte gamut, resulting in very desaturated colors. The same damage cannot be done with Beta RGB because it's much smaller than ProPhoto (not to say that damage isn't possible, it's just likely to be less severe).
To be honest ... I think it would have been much better to have all gamuts limited to triangles, just as the working-spaces are, so we wouldn't be continuously trying to fit triangular pegs into oval-or-worse shaped holes. Then I wouldn't have been offered the opportunity of wasting people's time whingeing about what to do with OOG colors!
Robert
-
To be honest ... I think it would have been much better to have all gamuts limited to triangles, just as the working-spaces are, so we wouldn't be continuously trying to fit triangular pegs into oval-or-worse shaped holes.
It's a problem but there isn't a thing we can do about it. Those simple triangular shapes are due to the color spaces being simple and theoretical. Output (and capture) color spaces are far different in shape and that mushing of shapes is just a fact of life. Toggle a couple rendering intents, pick the one that looks best, maybe do some minor tweaks (there's only so much you can do while soft proofing the destination color space). Move on.
-
I would be interested in your feedback on this workflow and especially if you see reasons why this is not a good way to do things.
Robert
For what reason are you interested?
So you can formulate arguing points toward folks already quite knowledgeable and experienced in both post processing and background history of the technology?
Why add more unnecessary workarounds to your processes? As time consuming post processing already is I don't think you're going to find a lot of adopters.
-
What we need here for the engineering minded to understand about digital imaging technology is the equivalent for someone to provide a perspective on its limitations, best practices and expectations as is demonstrated in the YouTube video below on the myths about digital audio in this instance dithering and bit depth (issues shared by digital imaging sensor recordings)...
https://www.youtube.com/watch?feature=player_detailpage&v=BYTlN6wjcvQ#t=2075
It's another hobby of mine that acts as a respite from digital imaging but find has similar online enthusiasts just as obsessive about the details and issues of the technology whether they exist or not in the course of creating content.
It helps to listen with headphones. Jump to the section about recording at certain bit depths. At what bit depth do you hear a difference.
-
I don't care about the math...
not only you, there is one Ph.D with "6 stops of DR advantage" ;)
-
not only you, there is one Ph.D with "6 stops of DR advantage" ;)
Yeah, well I never agreed with him about that either...(and his Ph.d was in some sort of nuclear stuff not imaging science)
-
it doesn't take advanced maths to figure out that a resolution of 1 in 65535 is better than 1 in 55,000, so the smaller your working space the better use you make of the bits available to you and the more you manipulate the image, the truer this is
Tell me the noise level and the maximum signal to noise ratio (SNR) and I will tell you which one is better. Don't be fooled by the digits, otherwise the solution to improving quality would be just to add bits or digits.
BTW, Photoshop uses signed integers so in practice you use 15 bits, not 16
-
I don't follow the OP's logic.
If you first open the image in Lightroom, then you've already converted to ProPhoto RGB. Any quantisation errors (noise) resulting from this large colour space will already have occured. Converting to Beta RGB can't undo those errors. However, by doing another colour space converstion (to Beta RGB) simply introduces another small source of noise.
As FranciscoDisilvestro hints, all this is quite likely to be well below the SNR in the image anyway (working at 16 bits encoding), so is of little consequence.
But I can't see how converting to Beta RGB improves things.
-
For what reason are you interested?
So you can formulate arguing points toward folks already quite knowledgeable and experienced in both post processing and background history of the technology?
Why add more unnecessary workarounds to your processes? As time consuming post processing already is I don't think you're going to find a lot of adopters.
Actually, the reason for my post was that I found, inadvertently, that when I edited a raw Smart Object, that ACR retained the color space from Photoshop. I had assumed that it would not, and would use ProPhoto, so I was concerned by the possibility that my edits might throw the image OOG in relation to my working space. I was really delighted to find that this was not the case, and I thought that I might share this with you ... as perhaps some people reading this post may not have realized this (as I did not until I stumbled upon it).
If many of you know this already, as I have no doubt you do, ... then what harm has been done? If you know a reason why doing what I am doing is a bad idea ... well then you can tell me; if you think it's a good idea, great!
I'm not in the least interested in arguing about this or anything else with you or 'folks knowledgeable and experienced in both post processing and background history of the technology'. My interest is to learn, and because my experience of color management and post processing is quite limited, there is a lot that I still have to learn ... and already this forum has helped me a lot, for which I'm very thankful.
If I am wasting your time then I'm truly sorry.
Robert
-
If I am wasting your time then I'm truly sorry.
You're not wasting our time, that's what we're all here for - to debate and learn.
My thoughts are that you might be wasting your time.
If the image goes through Lightroom, it gets converted to ProPhoto RGB on the way. This conversion - any conversion - introduces a small amount of quantisation noise arising from the quantisation levels in the destination colour space, and simply the action of changing from one colour space to another. However, the image starts in 12 or 14 bits raw and already has other sources of noise probably at least as large as the 12 or 14 bit quantisation noise. The quantisation noise introduced by conversion to 16-bit ProPhoto RGB, even though greater than that of Beta RGB, is likely to be significantly lower than the SNR already in the image data, and so is unlikely to be perceptually discernable.
Converting then from ProPhoto RGB to Beta RGB is another conversion, introducing another processing step, and another (small) source of noise. Again, not likely to be significant, but the conversion can't undo any (small) quantisation noise introduced by the conversion to ProPhoto RGB introduced by Lightroom.
Further noise introduced by processing in Photoshop might be a bit lower if the processing is done in Beta RGB as compared to ProPhoto RGB, and I'd be interested to see any tests that show if this can be discerned in the image. Personally I doubt it's significant, but I'm open to being shown otherwise.
As others have said, I can't follow the logic of any benefit of Beta RGB with regard to colours out-of-gamut for real devices.
-
I don't follow the OP's logic.
If you first open the image in Lightroom, then you've already converted to ProPhoto RGB. Any quantisation errors (noise) resulting from this large colour space will already have occured. Converting to Beta RGB can't undo those errors. However, by doing another colour space converstion (to Beta RGB) simply introduces another small source of noise.
As FranciscoDisilvestro hints, all this is quite likely to be well below the SNR in the image anyway (working at 16 bits encoding), so is of little consequence.
But I can't see how converting to Beta RGB improves things.
Hi Simon,
The conversion to Beta RGB or Adobe RGB or any smaller space isn't going to improve things in itself, of course (and as you say, any conversion will most likely introduce some small errors) so it would be a pointless thing to do unless there was some benefit down the line.
The question is, do you think, like Jeff Schewe, that it's totally fine to work in ProPhoto and that I am over-concerned about OOG colors? ... or do you think, as I do, that there is a real risk of damage to the image in the final conversion to the destination, and that the larger your working-space the greater the risk? That's your call of course ... and what you decide certainly makes no difference to me.
As far as I'm concerned it's like this: experts like Jeff Schewe can work perfectly safely in ProPhoto because they know what they are doing and are aware of the possible problems and don't fall into the kinds of traps that I have fallen into (for example changing to Lab mode and doing bonker things without any understanding of the consequences). I'm getting closer to that point as I get a better understanding of what is under the hood and what to watch out for ... but I'm certainly not there yet. Not too long ago, it was like giving a Lamborghini to a kid on speed!
Robert
-
The question is, do you think, like Jeff Schewe, that it's totally fine to work in ProPhoto and that I am over-concerned about OOG colors? ... or do you think, as I do, that there is a real risk of damage to the image in the final conversion to the destination, and that the larger your working-space the greater the risk? That's your call of course ... and what you decide certainly makes no difference to me.
Thinking about the OOG issue, both Beta RGB and ProPhoto RGB are bigger colour spaces than any likely real device. They're also probably larger than the effective colour space of the camera sensor (yes, I know camera sensor data doesn't have a colour space, I'm talking about the capability of the sensor to capture colour, once converted to a colour space). So both colour spaces can correctly represent all colours out of the camera, and any conversion issues resulting from conversion to the smaller colour space of a real device will be the same in both cases. This is because, although the colour spaces are different, the colours being represented are the same. Just different numbers.
Of course, in processing it's possible to introduce new colours outside the camera sensor's gamut. For example, if you work in either Beta RGB of ProPhoto RGB and screw the saturation right up, you can end up with colours that the sensor could not have created. You won't be able to see them on the monitor either, as few monitors go much wider than Adobe RGB. So to that extent, if one gets a bit too liberal with the saturation (or similar) controls, then one can create colours further out of gamut in ProPhoto RGB than in Beta RGB. I think one would have to have a Ken Rockwell liking for uber-saturated colour for that to be a significant danger.
I'm struggling to see how the choice of two working spaces, both larger than that of any real device, and larger than the capability of the camera sensor, makes a significant difference.
-
You're not wasting our time, that's what we're all here for - to debate and learn.
My thoughts are that you might be wasting your time.
If the image goes through Lightroom, it gets converted to ProPhoto RGB on the way. This conversion - any conversion - introduces a small amount of quantisation noise arising from the quantisation levels in the destination colour space, and simply the action of changing from one colour space to another. However, the image starts in 12 or 14 bits raw and already has other sources of noise probably at least as large as the 12 or 14 bit quantisation noise. The quantisation noise introduced by conversion to 16-bit ProPhoto RGB, even though greater than that of Beta RGB, is likely to be significantly lower than the SNR already in the image data, and so is unlikely to be perceptually discernable.
Converting then from ProPhoto RGB to Beta RGB is another conversion, introducing another processing step, and another (small) source of noise. Again, not likely to be significant, but the conversion can't undo any (small) quantisation noise introduced by the conversion to ProPhoto RGB introduced by Lightroom.
Further noise introduced by processing in Photoshop might be a bit lower if the processing is done in Beta RGB as compared to ProPhoto RGB, and I'd be interested to see any tests that show if this can be discerned in the image. Personally I doubt it's significant, but I'm open to being shown otherwise.
As others have said, I can't follow the logic of any benefit of Beta RGB with regard to colours out-of-gamut for real devices.
Hi Simon,
I hope I answered you in my post that overlapped with yours! It's unfortunate that I mentioned quantization errors because that's a complete red herring (a case of TMI!). Sure, there probably is some (no doubt insignificant) additional rounding-type errors when we use a larger working space and perhaps this is of interest to people like Bruce Lindbloom, but it isn't to me because I probably couldn't measure it and I for sure can't see it.
My post had to do with the potential problem of working in a very large working space from a gamut-mapping perspective. I think I demonstrated one aspect ... Perceptual mappings to the destination space ... above. Another issue is that it's very easy to push some colors OOG in any working space, but the larger the working space, the further you can push the colors OOG, and so the more the clipping that may occur on conversion to the destination.
Going to a smaller space like Beta RGB limits the problem but it doesn't make it go away.
I like to keep things contained and not to have to spend too much time watching Gamut Warnings, and then sometimes having to fix the OOG colors because they look bad on output. But that's just a preference ... if you prefer to do it the other way then fine, it's just as valid a way of working.
What I didn't mention is that my final working space is the print space. So I convert to Beta RGB first and ready the image for print; then I convert to the print space and do the final edits in that space. That way I can see the potential problems (I also turn gamut warning on for my monitor, so I know that I'm seeing what is going to go to the printer) and any edits I do are automatically constrained to the print space. I know you can achieve something similar with soft-proofing, but soft-proofing doesn't limit you, whereas the working space does. Again, this is just a question of preference.
I do appreciate your concern that I might be wasting my time, and perhaps you're right :). However, how much time does it take to convert an image from one working space to another? Once this step is in one's workflow the additional time taken is really insignificant (especially if you set the workspace in Photoshop to Beta RGB ... or whatever workspace you like) - and it would be completely insignificant if Lightroom allowed one to open the image in Photoshop using profiles other than sRGB, Adobe RGB or ProPhoto RGB.
Robert
-
Thinking about the OOG issue, both Beta RGB and ProPhoto RGB are bigger colour spaces than any likely real device. They're also probably larger than the effective colour space of the camera sensor (yes, I know camera sensor data doesn't have a colour space, I'm talking about the capability of the sensor to capture colour, once converted to a colour space). So both colour spaces can correctly represent all colours out of the camera, and any conversion issues resulting from conversion to the smaller colour space of a real device will be the same in both cases. This is because, although the colour spaces are different, the colours being represented are the same. Just different numbers.
Of course, in processing it's possible to introduce new colours outside the camera sensor's gamut. For example, if you work in either Beta RGB of ProPhoto RGB and screw the saturation right up, you can end up with colours that the sensor could not have created. You won't be able to see them on the monitor either, as few monitors go much wider than Adobe RGB. So to that extent, if one gets a bit too liberal with the saturation (or similar) controls, then one can create colours further out of gamut in ProPhoto RGB than in Beta RGB. I think one would have to have a Ken Rockwell liking for uber-saturated colour for that to be a significant danger.
I'm struggling to see how the choice of two working spaces, both larger than that of any real device, and larger than the capability of the camera sensor, makes a significant difference.
Well, to quote Andrew Rodney on Photo.net (just checking on sensor 'gamuts'): "... These arbitrary gamut boundaries do not necessarily and often don't get close to defining the gamut possibilities of the sensor (if we have to use the word gamut) ". As usual, Andrew is a bit above my head, but I think he means that more colors can potentially be recorded by a camera sensor than will fit in many color spaces (thus the choice of ProPhoto for raw processing).
I don't think it's hard at all to get colors that fall outside the destination gamut in large workspaces like ProPhoto. Here is a typical example. The top image is in Beta RGB, the bottom one in ProPhoto. Gamut warning is turned on for the print destination for both.
(http://www.irelandupclose.com/customer/LL/gw-brgb.jpg)
(http://www.irelandupclose.com/customer/LL/gw-pp.jpg)
As you can see, there are colors in the ProPhoto version that are OOG, but not in the BetaRGB.
OK, this is a sunrise, so perhaps the colors are a bit extreme. But what about quite dark colors, greens for example, that appear quite unsaturated, but in fact are pushed out beyond the print capability? What happens to them when you print? Same thing, right? They are going to have to be clipped if you print using Relative Colorimetric (which I almost always do).
Robert
-
then I convert to the print space and do the final edits in that space. That way I can see the potential problems (I also turn gamut warning on for my monitor, so I know that I'm seeing what is going to go to the printer) and any edits I do are automatically constrained to the print space. I know you can achieve something similar with soft-proofing, but soft-proofing doesn't limit you, whereas the working space does. Again, this is just a question of preference.
Just bear in mind that output color spaces are not necessarily gray balanced (r=g=b =/= neutral) nor perceptually uniform, so your edits might have unintended consequences (except OOG colors). Additionally, if you need to adjust white balance, then you would be much better off working with a large space and softproofing.
-
OK, this is a sunrise, so perhaps the colors are a bit extreme. But what about quite dark colors, greens for example, that appear quite unsaturated, but in fact are pushed out beyond the print capability? What happens to them when you print? Same thing, right? They are going to have to be clipped if you print using Relative Colorimetric (which I almost always do).
Robert
You might have to work with individual masks, individual channel saturation, vibrance, etc. if you want optimal results. Just relying on color space conversion and rendering intents is sub-optimal
-
Just bear in mind that output color spaces are not necessarily gray balanced (r=g=b =/= neutral) nor perceptually uniform, so your edits might have unintended consequences (except OOG colors). Additionally, if you need to adjust white balance, then you would be much better off working with a large space and softproofing.
True about the gray balance and perceptual uniformity ... and I am aware that what I'm seeing is not what goes to the printer, but is an AtoB mapping back to the PCS/ Working Space / Monitor. If all is well, it should be close to the output, but of course it won't be exact.
This is also true of soft-proofing.
Still, I'm not entirely sold on the idea of doing the final (small) edits in the destination space. It's just something I'm playing around with. Graeme Gill's comment on this way of working was: "It's a reasonable approach, if you know what you are doing.". At this point I'm not quite convinced that I know what I'm doing :) ... yet.
Robert
-
You might have to work with individual masks, individual channel saturation, vibrance, etc. if you want optimal results. Just relying on color space conversion and rendering intents is sub-optimal
Yes ... well working with individual masks, channels etc., is exactly what I'm trying to avoid having to do. In my experience (and this may have to do with my lack of skill) these edits often end up with a worse result than letting the CMM do the mapping. What I'm trying to do is to make the CMM's job easier and more likely to be effective: break down its task into smaller chunks and make the overall task smaller ... that sort of thing.
Robert
-
It's a problem but there isn't a thing we can do about it. Those simple triangular shapes are due to the color spaces being simple and theoretical. Output (and capture) color spaces are far different in shape and that mushing of shapes is just a fact of life. Toggle a couple rendering intents, pick the one that looks best, maybe do some minor tweaks (there's only so much you can do while soft proofing the destination color space). Move on.
Good advice. I'm happy with my workflow and it works for me, so move on I shall :)
-
As other's have stated, in an Adobe raw workflow, you're using ProPhoto RGB gamut whether you like it or not. There's some assumed camera primary values that get converted to ProPhoto primaries, that's that. I susect this is true of all raw processors (expect camera primaries to internal color space isn't always ProPhoto primaries and gamut, Aperture uses Adobe RGB (1998)).
That being the case, it's rather ponintless to convert from ProPhoto or anything you can select in LR/ACR to Beta RGB. It might help you in the OOG department but cause issues elsewhere. And you're still stuck with a big triangle shape that's a poor fit for other output spaces. Fact of life. I can only speak for my images and output, OOG isn't a big deal. I'm more concerned with what I can't see on my wide gamut display to be honest. I could be editing colors I can't see (scary). For output, I pick an RI from the soft proof and with rare exceptions where I do a tad of output specific tweaks, I'm done. There are far, far more issues with color management and workflow IMHO than OOG colors.
As you can see, there are colors in the ProPhoto version that are OOG, but not in the BetaRGB.
I see an ugly red blob which obviously isn't what I"ll see on the print. What I can't see is what the affect of the RI and conversion has on the actual print and that's really all I care about.
In my experience (and this may have to do with my lack of skill) these edits often end up with a worse result than letting the CMM do the mapping.
Exactly! It's probably not a lack of skill.
-
So, you know for a fact that ProPhoto RGB is "too big"? You've actually seen "quantization errors" using ProPhoto RGB? Or is what you "believe" based upon your internet reading?
I ask because I've never seen any quantization errors when working in a ProPhoto RGB color managed workflow...
If you were on Bruce Lindbloom's web site reading about it, you should note that page was last updated on Sun, 20 Apr 2003 09:06:14 GMT which was about the time that Adobe released Camera Raw v1. There is a reason why Thomas Knoll chose ProPhoto RGB and linear gamma as the internal working space for ACR and then LR.
The fact that Bruce's post on BetaRGB is old does not necessarily mean that it no longer applicable -- physical constants do not change. There is a concept of Real World Surface Colors (see this thread (http://www.cambridgeincolour.com/forums/thread25715.htm) and the link to the Norman Koren site (http://www.normankoren.com/color_management_2.html) further discussing the matter). Whatever space one is using for editing, it should include these colors. According to Mr. Koren, AdobeRGB includes most of these and the eye is not extremely sensitive to chroma differences in highly saturated colors, suggesting that AdobeRGB might be adequate for most work. A wider space would include more colors, but there may not be much perceivable difference in the outputs with real world scenes.
Lindbloom's reference color set used in choosing the primaries for BetaRGB seems to consist primarily of the colors found in photographic films and printing paper, and may be out of date in the digital age where we are using digital sensors and inkjet printers. The extent that this color set includes these real world surface colors is not documented.
My own take is that BetaRGB may make sense if one is using an 8 bit color depth, but with a 16 bit color depth, quantization errors with ProPhotoRGB are negligible and not perceptible and the increased gamut may be useful in some situations. For my own work with Adobe applications I use 16 bit ProPhotoRGB since these applications use ProPhoto primaries and out of gamut colors in printing are not a significant problem when one uses reasonable editing.
Bill
-
As other's have stated, in an Adobe raw workflow, you're using ProPhoto RGB gamut whether you like it or not. There's some assumed camera primary values that get converted to ProPhoto primaries, that's that. I susect this is true of all raw processors (expect camera primaries to internal color space isn't always ProPhoto primaries and gamut, Aperture uses Adobe RGB (1998)).
That being the case, it's rather ponintless to convert from ProPhoto or anything you can select in LR/ACR to Beta RGB. It might help you in the OOG department but cause issues elsewhere. And you're still stuck with a big triangle shape that's a poor fit for other output spaces. Fact of life. I can only speak for my images and output, OOG isn't a big deal. I'm more concerned with what I can't see on my wide gamut display to be honest. I could be editing colors I can't see (scary). For output, I pick an RI from the soft proof and with rare exceptions where I do a tad of output specific tweaks, I'm done. There are far, far more issues with color management and workflow IMHO than OOG colors. I see an ugly red blob which obviously isn't what I"ll see on the print. What I can't see is what the affect of the RI and conversion has on the actual print and that's really all I care about.Exactly! It's probably not a lack of skill.
I agree ... often OOG isn't a big deal and the CMM handles it just fine. As you say, pick the RI that you like best and it's usually fine.
But if you are trying to get the best from your image and you want a Perceptual mapping because you think it looks better than a Relative mapping, then you will get a better result if you first go Relative to a smaller color space and then do the Perceptual mapping. That is a fact, simply because Perceptual squeezes the whole source gamut to the destination gamut, so the smaller the source gamut the less the squeeze, and the less the squeeze the less impact on all colors, but the most saturated the least.
You can see it with the test image I posted earlier:
(http://www.irelandupclose.com/customer/LL/gc.jpg)
The top one is a 2-step mapping, the bottom 1-step. Both the oranges and yellows are flattened in the bottom image, and in some places the yellows have even merged into the oranges. It may not be all that easy to see on the sRGB crop here, but if you would like to see it better, here is the tif crop (top layer is the 2-step mapping): http://www.irelandupclose.com/customer/LL/W58825.tif (http://www.irelandupclose.com/customer/LL/W58825.tif)
My question is this: if a really simple step like this yields some improvement (even if it's not much) ... why not do it? OK, it takes an extra few seconds, but you can still work in ProPhoto up to the end if you want to and any damage to the file going from ProPhoto to Beta RGB or Adobe RGB (or whatever) is absolutely minimal ... so why not do it?
Robert
-
I'm not in the least interested in arguing about this or anything else with you or 'folks knowledgeable and experienced in both post processing and background history of the technology'. My interest is to learn, and because my experience of color management and post processing is quite limited, there is a lot that I still have to learn ... and already this forum has helped me a lot, for which I'm very thankful.
If I am wasting your time then I'm truly sorry.
Robert
Hi Simon,
The conversion to Beta RGB or Adobe RGB or any smaller space isn't going to improve things in itself, of course (and as you say, any conversion will most likely introduce some small errors) so it would be a pointless thing to do unless there was some benefit down the line.
Argumentative AND speculative seeing you're just learning and aren't quite knowledgeable about this technology as you've professed. And no, I don't know what answer to give you in order to learn and/or teach because you've setup a complicated workflow scenario where you've found some tiny aspect of the behavior of the software that in the time to figure it out anyone reading this and trying to learn already edited several images and printed with no problems.
You want to learn something? Here's a teaching moment.
Post the best looking image you created with edits in your favorite imaging software and tell us how long it took you to turn into a print and all the difficulties you faced. That's all that matters. I and many others reading this thread will in turn learn from your experience.
Keep in mind the preview you see on your display is a fantasy that was formed by so many variables under the hood not just with imaging software but with your display and the OS that it's a miracle it works as good as it does without trying to speculate how the math is being manipulated in forming the preview. You're never going to know for sure in order to develop a more consistent and efficient workflow. That's the goal!
The work has already been done in the software you paid dearly, so there's no point in reverse engineering with speculative suppositions regarding working spaces/OOG, bit depth, dithering all of which clearly don't help anyone create a better looking image>print a lot quicker than their current setup.
-
But if you are trying to get the best from your image and you want a Perceptual mapping because you think it looks better than a Relative mapping, then you will get a better result if you first go Relative to a smaller color space and then do the Perceptual mapping. That is a fact, simply because Perceptual squeezes the whole source gamut to the destination gamut, so the smaller the source gamut the less the squeeze, and the less the squeeze the less impact on all colors, but the most saturated the least.
Robert
It's not a fact if it doesn't work that way on every image on a consistent basis especially when using the subjective term "looks better".
To drive home the point even further that the digital image and its processing is a fantasy and not some precision scientific endeavor that can be controlled and measured on a consistent basis using hardware and software whose low pricing doesn't reflect precision,predictability and consistency, I submit the image below and ask how do you determine the color gamut capture capability of my DSLR camera shooting Raw compared to its incamera processing.
The answer is that there are too many choices, options and methods that get in the way in allowing anyone to know precisely what the gamut is at least on level that's predictable and controllable. So what's the point in trying to figure all this out even if you now understand what it is. It's still not useful in making a better looking image and print far much faster and consistently.
-
According to Mr. Koren, AdobeRGB includes most of these and the eye is not extremely sensitive to chroma differences in highly saturated colors, suggesting that AdobeRGB might be adequate for most work. A wider space would include more colors, but there may not be much perceivable difference in the outputs with real world scenes.
Hi Robert,
I kind of agree with you: use as big a space as you need but no bigger. How big of a space? How about your camera's? If you don't know how big your camera's space is then go for the output device. Most monitors (and many printers) cannot do more than some variant of AdobeRGB. Come to think of it my monitor and 55 incher TV only do AdobeRGB, as does my printing service. So I guess you know what my working color space is.
Some people want to future proof their files, I am not one of them. 99% of images get seen in sRGB, so I convert them to that from raw before sending them off. A few get printed. Every time I print one of my images, old or new, I like to re-work them from raw with all the latest and greatest toys I've collected and with the new skills I've developed - it's amazing how differently I process images today than I did just five years ago - and I do that while choosing the appropriate color space for the output device at hand at that time.
So no need for cavernous color spaces where colors get lost in. Small (well, relatively) is beautiful, start from raw and just use what you need at the time. If you don't know what you need, go for s or aRGB depending on your monitor.
Jack
-
Hi Robert,
I kind of agree with you: use as big a space as you need but no bigger. How big of a space? How about your camera's? If you don't know how big your camera's space is then go for the output device. Most monitors (and many printers) cannot do more than some variant of AdobeRGB. Come to think of it my monitor and 55 incher TV only do AdobeRGB, as does my printing service. So I guess you know what my working color space is.
Some people want to future proof their files, I am not one of them. 99% of images get seen in sRGB, so I convert them to that from raw before sending them off. A few get printed. Every time I print one of my images, old or new, I like to re-work them from raw with all the latest and greatest toys I've collected and with the new skills I've developed - itìs amazing how differently I process images today than I did just five years ago - and I do that while choosing the appropriate color space for the output device at hand at that time.
So no need for cavernous color spaces where colors get lost in. Small (well, relatively) is beautiful, start from raw and just use what you need at the time. If you don't know what you need go for s or aRGB depending on your monitor.
Jack
Thank goodness ... I'm not entirely alone any more (just joking, I know that the discussion so far has been mostly constructive and helpful ... and it hasn't all been disagreement).
Yes, AdobeRGB is just fine for me ... I just feel that it's a little tight, that my printer can print outside of it ... bla bla. But in reality I would be very happy to stay within that space and I VERY much doubt I would see any difference if I go to a bigger space.
I also agree that (as long as we keep our raw images) that we are quite future-proofed enough ... and as you say, if we have to redo the image in 5 years time to fit into what may then be a wider gamut ... well, hopefully our skills will have improved and we will end up with a better image, and not just because of the wider gamut.
As you point out, small(ish) is beautiful (literally, when I think of some of the 'HDR' images I've seen in the past few years!!).
Robert
-
Thank goodness ... I'm not entirely alone any more (just joking, I know that the discussion so far has been mostly constructive and helpful ... and it hasn't all been disagreement).
Actually, I sort of agree with you too! sRGB is an underrated colour space. By that I mean that most pixels in most images have colours within sRGB. I have two monitors: one with a gamut wider than Adobe RGB, and one approximates to sRGB colour gamut. Both are calibrated and profiled, and when I use Lightroom (which uses Adobe RGB for previews), I can see no difference between the rendering of colour on the two monitors on most of my 35,000 plus raw images. In other words: few pixels outside sRGB on most of my raw images. Of course, I can create blobs of 100% saturated colour in ProPhoto RGB, and the difference between the two monitors is very, very obvious. But not for most real raw images. sRGB is a perfectly satisfactory colour space for most purposes.
My reason for disagreeing with your workflow, slightly, is that I take the view that if you start in a wide-gamut, you might as well stay there until the last stage, when you convert to the output colour space (or to sRGB if it's for the web). Lightroom uses ProPhoto RGB as its working space - no choice about that - so I stay there until the that last stage.
I also go with the future-proof argument. If the image is in ProPhoto RGB, there is virtually no chance that any future device will have a larger colour space (even if relatively few images need more than sRGB).
-
sRGB is an underrated colour space.
How so?
By that I mean that most pixels in most images have colours within sRGB.
It is the image data that have colors outside sRGB we can output that's, far more prevalent.
There's only one actual device that sRGB defines and it's an old CRT of which that space was designed to mimic. What's underrated about that one theoretical device?
-
Actually, I sort of agree with you too! sRGB is an underrated colour space. By that I mean that most pixels in most images have colours within sRGB. I have two monitors: one with a gamut wider than Adobe RGB, and one approximates to sRGB colour gamut. Both are calibrated and profiled, and when I use Lightroom (which uses Adobe RGB for previews), I can see no difference between the rendering of colour on the two monitors on most of my 35,000 plus raw images. In other words: few pixels outside sRGB on most of my raw images. Of course, I can create blobs of 100% saturated colour in ProPhoto RGB, and the difference between the two monitors is very, very obvious. But not for most real raw images. sRGB is a perfectly satisfactory colour space for most purposes.
My reason for disagreeing with your workflow, slightly, is that I take the view that if you start in a wide-gamut, you might as well stay there until the last stage, when you convert to the output colour space (or to sRGB if it's for the web). Lightroom uses ProPhoto RGB as its working space - no choice about that - so I stay there until the that last stage.
I also go with the future-proof argument. If the image is in ProPhoto RGB, there is virtually no chance that any future device will have a larger colour space (even if relatively few images need more than sRGB).
That's fair enough. There certainly are good arguments for staying in the big space until the end, especially if one knows what one is doing and especially if one is careful.
One of the nice things about using a raw smart object in Photoshop is that you can convert it back and forth from ProPhoto to sRGB to AdobeRGB etc, so that you are not stuck in one working space (admittedly this involves duplicating the image, converting the smart object on it's own, copying the adjustment layers over ... a bit messy, but do-able). Apart from the flexibility of being able to (relatively) easily have variants for print and web, it's also a pretty good way to future-proof yourself (assuming smart objects don't vanish into the Creative Cloud in some foggy future!).
Robert
-
How so?
It is the image data that have colors outside sRGB we can output that's, far more prevalent.
There's only one actual device that sRGB defines and it's an old CRT of which that space was designed to mimic. What's underrated about that one theoretical device?
I'm sure Simon is well capable of answering this himself, but I'll throw in my take on it. The reason sRGB is underrated is that many of us think it's inferior because it's smaller ... whereas, in reality, its gamut is quite large enough for most of our images. That pretty much fits under the definition of 'underrate' I think.
We think it's OK for the web, because there's no choice really, but, sure, it's not good enough for printing, is it?
Robert
-
The reason sRGB is underrated is that many of us think it's inferior because it's smaller ... whereas, in reality, its gamut is quite large enough for most of our images.
No my images ;D It's far too small. Even output to CMYK (SWOP V2), sRGB clips colors. Did you see my video on gamut?
We think it's OK for the web, because there's no choice really, but, sure, it's not good enough for printing, is it?
It's OK for web because of how it's based. It's not ideal for print, there are no sRGB printers. If you are concerned with gamut clipping, sRGB isn't the space you'd ever consider using for anything but posting to the internet. And someday, should wide gamut displays be the norm, we'll point towards Adobe RGB (1998) instead of sRGB.
-
It is the image data that have colors outside sRGB we can output that's, far more prevalent.
And that image data can only be seen on a device that can reproduce them and currently that being wide gamut displays but there are limits to that as well. It would be helpful for many photographers to understand when to know what colors they're shooting in the real world that needs future proofing.
I've already had a real world experience printing a shot of a turquoise rayon dress and printing on a Fuji Frontier drylab whose gamut in the cyans & turquoise extend beyond AdobeRGB but couldn't be seen on my sRGB display, but that is the exception rather than the norm and so far is the only evidence of a color captured that needs future proofing I've come across in the five years I've been processing Raw. Most of my Raw captures I can make look as they appeared no matter the saturation level, but of course it requires a luminance hit like the orange flower example posted above.
Has someone measured or determined by other methods real world colors that can't be seen in a digital capture due to limitations of current display gamut or even printer gamut but can be captured by the digital sensor and passed onto image editing software in the future for devices that can show them?
-
No my images ;D It's far too small. Even output to CMYK (SWOP V2), sRGB clips colors. Did you see my video on gamut? It's OK for web because of how it's based. It's not ideal for print, there are no sRGB printers. If you are concerned with gamut clipping, sRGB isn't the space you'd ever consider using for anything but posting to the internet. And someday, should wide gamut displays be the norm, we'll point towards Adobe RGB (1998) instead of sRGB.
Hi Andrew,
I'm not suggesting that sRGB is the best working-space for print. I was simply agreeing with Simon that for many images it's quite adequate and with a bit of tweaking, images in sRGB will look fine, whether they are printed or viewed on a monitor. Having extra gamut doesn't necessarily make a better image!
Also, sRGB won't cause any clipping on output. The clipping occurs because the destination gamut is smaller than the working space, not the other way around (as you know, of course). In fact if you want to avoid clipping on output you are much better off working in sRGB than in Adobe RGB, Beta RGB, ProPhoto RGB or any of the working spaces that may be bigger than the output gamut.
Robert
-
Has someone measured or determined by other methods real world colors that can't be seen in a digital capture due to limitations of current display gamut or even printer gamut but can be captured by the digital sensor and passed onto image editing software in the future for devices that can show them?
No, I haven't seen any analysis of this kind, but it would be interesting to know the capture range of a typical modern sensor, considering its response to the different light wavelengths, the effect of noise etc.
But in relation to monitors ... well the best monitors can only do a bit better than Adobe RGB, and printers not a whole lot better: current camera sensors can certainly capture more than that. So there's plenty of head-room for what could be done in the future.
Robert
-
I'm not suggesting that sRGB is the best working-space for print.
It isn't by a long shot! It's only ideal for one use, the internet.
I was simply agreeing with Simon that for many images it's quite adequate and with a bit of tweaking, images in sRGB will look fine, whether they are printed or viewed on a monitor. Having extra gamut doesn't necessarily make a better image!
I disagree with both ideas. First, it's not ideal, it's suboptimal for print output. The output may be 'fine' whatever that means but it's not the best output that can be achieved all things being equal (capture color space and output gamut). The sRGB JPEG's your camera produces are fine too, I'll stick with the setting for raw data.
Also, sRGB won't cause any clipping on output.
The 3D gamut maps suggest otherwise:
(http://www.digitaldog.net/files/sRGBvsSWOP.jpg)
That red blob falling outside sRGB gamut is SWOP TR001, sRGB doesn't even have sufficient gamut space for that kind of output. Next, there are no native sRGB capture devices so whatever data you have in sRGB, it was converted to that gamut and I'll bet you dollars to doughnuts that native gamut was larger. The clipping DID happen when you converted to sRGB, I submit that unless the output is to the internet, you shouldn’t have done that conversion.
The clipping occurs because the destination gamut is smaller than the working space, not the other way around (as you know, of course).
The clipping occurred because you selected sRGB from some larger color space! Again, did you see my video on gamut?
In fact if you want to avoid clipping on output you are much better off working in sRGB than in Adobe RGB, Beta RGB, ProPhoto RGB or any of the working spaces that may be bigger than the output gamut.
I started with raw data, or a scan in scanner RGB. I end up by your suggestion in sRGB. There was no gamut clipping? The red in SWOP gets clipped going from sRGB to CMYK because sRGB is a shitty sized working space. The data got clipped before it became sRGB too!
Everything you thought you wanted to know about color gamut:
A pretty exhaustive 37 minute video examining the color gamut of RGB working spaces, images and output color spaces. All plotted in 2D and 3D to illustrate color gamut.
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q
-
It isn't by a long shot! It's only ideal for one use, the internet.I disagree with both ideas. First, it's not ideal, it's suboptimal for print output. The output may be 'fine' whatever that means but it's not the best output that can be achieved all things being equal (capture color space and output gamut). The sRGB JPEG's your camera produces are fine too, I'll stick with the setting for raw data.
The 3D gamut maps suggest otherwise:
(http://www.digitaldog.net/files/sRGBvsSWOP.jpg)
That red blob falling outside sRGB gamut is SWOP TR001, sRGB doesn't even have sufficient gamut space for that kind of output. Next, there are no native sRGB capture devices so whatever data you have in sRGB, it was converted to that gamut and I'll bet you dollars to doughnuts that native gamut was larger. The clipping DID happen when you converted to sRGB, I submit that unless the output is to the internet, you shouldn’t have done that conversion.
The clipping occurred because you selected sRGB from some larger color space! Again, did you see my video on gamut? I started with raw data, or a scan in scanner RGB. I end up by your suggestion in sRGB. There was no gamut clipping? The red in SWOP gets clipped going from sRGB to CMYK because sRGB is a shitty sized working space. The data got clipped before it became sRGB too!
Everything you thought you wanted to know about color gamut:
A pretty exhaustive 37 minute video examining the color gamut of RGB working spaces, images and output color spaces. All plotted in 2D and 3D to illustrate color gamut.
High resolution: http://digitaldog.net/files/ColorGamut.mov
Low Res (YouTube): http://www.youtube.com/watch?v=n0bxSD-Xx-Q
For a real world example, I rendered an image of a tulip into ProPhotoRGB using ACR with the AdobeStandard profile, using no saturation boost (default settings). The following images are in sRGB for web display.
One can use the gamut warning in Photoshop with AdobeRGB as the target. Many colors are out of gamut, but the extent of OOG is not determined with this type of warning.
(http://bjanes.smugmug.com/Tulip-Study/i-DmNDQTw/0/O/TulipComposite.png)
One can use Colorthink to calculate a color list and determine the DeltaEs (as per the DigitalDog's movie). A DeltaE of 2 or less is minor, whereas a DeltaE of 2 to 8.5 is moderate, and a DeltaE of greater than 14 is major.
(http://bjanes.smugmug.com/Tulip-Study/i-vwzK2C3/0/XL/TulipsColorLists-XL.png)
For printing, I used the Epson 3880 with Premium Glossy as an example. Many of the yellows and reds are out of gamut of both AdobeRGB and the printer gamut. However, if one uses AdobeRGB as the working space, there are relatively few colors that the printer is capable of printing that are outside of the AdobeRGB gamut so that one does not lose much if he is using AdobeRGB rather than ProPhotoRGB as the working space. The printer gamut for mid luminance greens and teals is considerably wider than AdobeRGB, but these colors are not in the current image.
(http://bjanes.smugmug.com/Tulip-Study/i-hgnS7xd/0/M/TulipTriGamut-M.png)
Bill
-
For printing, I used the Epson 3880 with Premium Glossy as an example. Many of the yellows and reds are out of gamut of both AdobeRGB and the printer gamut. However, if one uses AdobeRGB as the working space, there are relatively few colors that the printer is capable of printing that are outside of the AdobeRGB gamut so that one does not lose much if he is using AdobeRGB rather than ProPhotoRGB as the working space.
On this image, I'd agree. Be useful to see something representing very saturated greens and blues. Atkinsion's Lab test image (from Tango scans), Roman 16's (we need something from a camera)?
Be nice to have a super computer to run ColorThink on ;D
If the source is raw with an Adobe raw process, you're getting ProPhoto RGB primaries, why ad another conversion prior to output?
-
No one is arguing that sRGB has a wider gamut than Adobe RGB (and I assume that no one is arguing that Adobe RGB has a wider gamut than Beta RGB and Beta RGB a wider gamut than ProPhoto RGB etc., etc).
Here it is: Adobe RGB is the wider gamut, sRGB the smaller one:
(http://www.irelandupclose.com/customer/LL/srgb-argb.jpg)
No one is arguing that saturated colors in ProPhoto will not get clipped when going to sRGB.
No one is arguing that print gamuts often are wider than sRGB.
That does NOT make sRGB a 'shitty sized working space', to quote you Andrew. It just makes it a smaller working space.
It's the wrong working-space to use if your image has colors that are outside it, full stop. If all the colors in your image are within its gamut, then it's as good, or possibly better, a working space to use than one that has a larger gamut. Using a larger gamut will gain you nothing when going to print, because the colors are not there.
If your image has colors outside of sRGB then of course you should use a working space that can accommodate them. But if your image has colors that are within your larger workspace, but outside the gamut of your destination, well then all you've done is to create a problem for yourself ... and you can either fix the image or let the CMM do it for you ...but either way the image IS going to get squashed or clipped on its way to output.
So it's horses for courses ... there are pros and cons, but it is simply not true to say that sRGB is a bad workspace: limited, yes, bad, no.
Robert
-
If the source is raw with an Adobe raw process, you're getting ProPhoto RGB primaries, why ad another conversion prior to output?
Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut. If you do a conversion to a smaller workspace first (it will be a Relative conversion) then the subsequent Perceptual mapping is less drastic (so that saturated colors will get flattened/desaturated less). Of course there is the possibility of clipping when converting from the larger working space to the smaller one, so the choice of intermediate working space (or whether to use one at all) is something that needs to be considered.
-
Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut. If you do a conversion to a smaller workspace first (it will be a Relative conversion) then the subsequent Perceptual mapping is less drastic (so that saturated colors will get flattened/desaturated less). Of course there is the possibility of clipping when converting from the larger working space to the smaller one, so the choice of intermediate working space (or whether to use one at all) is something that needs to be considered.
That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false. Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering. Even if there are no OOG colors in the original image, the arbitrary fixed compression is applied. See this article (http://www.steves-digicams.com/knowledge-center/understanding-rendering-intents.html#b) by Mike Chaney.
Bill
-
Very simple: if you do a Perceptual mapping to the destination from ProPhoto you are squeezing the whole of ProPhoto into your destination gamut.
Boy, I don't think so, if what you mean is some kind of linear 3D compression. Including the parts of PPRGB that aren't visible? That would be a pretty crazy way to write a perceptual 3D LUT. Do you have any evidence that people populate the look-up tables that way?
Jim
-
That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false. Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering. Even if there are no OOG colors in the original image, the arbitrary fixed compression is applied. See this article (http://www.steves-digicams.com/knowledge-center/understanding-rendering-intents.html#b) by Mike Chaney.
Bill
Actually the CMM only does what the mapping table (or matrix) tells it to do, and the mapping table depends on the algorithm used, and the algorithm is up to the author of the profile (because the ICC does not specify exactly how it should be done). The 'arbitrary' value is the difference between the larger color space and the smaller one (there is no squeezing or stretching if the destination space is larger than the source in the case of a Perceptual mapping). There should be NO OOG colors after a perceptual mapping, but there may be after a saturation mapping (in order to force as much saturation in the output as possible).
Boy, I don't think so, if what you mean is some kind of linear 3D compression. Including the parts of PPRGB that aren't visible? That would be a pretty crazy way to write a perceptual 3D LUT. Do you have any evidence that people populate the look-up tables that way?
Jim
Well not some sort of linear 3D compression, obviously ... but a 3D compression, yes, absolutely. Directly from Graeme Gill of ArgyllCMS, and if he doesn't know what a Perceptual mapping does, then I don't know who does. Also, have a look at this excellent tutorial: http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm (http://www.cambridgeincolour.com/tutorials/color-space-conversion.htm) (although the section on Absolute Colorimetric is misleading).
Robert
-
I can see Robert has learned quite more than he lets on to be able to counter to folks in this thread with knowledge of how CMM algorithms map color data from one space to another. What's your thoughts on Euclidean math, Robert? Have you looked into that aspect of the math that operates under the color management hood?
It wouldn't matter if you knew or not because as usual in discussions of this sort none of the information is of any practical use in helping photographers make better pictures.
It's sort of like folks who seem to practice shade tree math and color science relying only on graphical analyzers to make them come across as if they know how the map was drawn, understand the map intimately and know the code and gps coordinances that function under the hood but never seem to go anywhere or help others to their destination.
-
That does NOT make sRGB a 'shitty sized working space', to quote you Andrew. It just makes it a smaller working space.
I think it does based on it's gamut size which is what separates the men from the boys in terms of a working space. A working space only has three attributes. The TRC gamma and white point are pretty immaterial in color managed app's for which such spaces are designed. It's the primaries and thus gamut that make the big differences here. There's one useful end point for sRGB, I've told you what that is. It's inferior/sub optimal for just about anything else one would convert to for output from the wide gamut master. It's actually inferior for output to something we expect not to have a wide gamut (SWOP CMYK)! That is, if you have any hope to reproduce the colors you have that the output device could reproduce.
-
It wouldn't matter if you knew or not because as usual in discussions of this sort none of the information is of any practical use in helping photographers make better pictures.
Actually, Tim, it is very much of practical use. You surely can't be serious when you say that there is no value in understanding what happens when an image is mapped from one color space to another? Or perhaps I've misunderstood you.
If you prefer to work entirely by experience then that's totally fine: it is another and entirely valid way of finding out what works and what doesn't. Experience cannot be replaced by theory - I don't dispute that. But why knock an attempt to understand what actually happens when A gets transformed to B?
Robert
-
I think it does based on it's gamut size which is what separates the men from the boys in terms of a working space. A working space only has three attributes. The TRC gamma and white point are pretty immaterial in color managed app's for which such spaces are designed. It's the primaries and thus gamut that make the big differences here. There's one useful end point for sRGB, I've told you what that is. It's inferior/sub optimal for just about anything else one would convert to for output from the wide gamut master. It's actually inferior for output to something we expect not to have a wide gamut (SWOP CMYK)! That is, if you have any hope to reproduce the colors you have that the output device could reproduce.
Yes, Andrew, I agree with you when you say "That is, if you have any hope to reproduce the colors you have that the output device could reproduce". This assumes that you want to make full use of the output gamut, and the only way you can do that is for your working-space to fully encompass the output gamut: no debate there! However, I will repeat, perhaps using slightly different words in order to make myself clear, that for an image whose gamut is within sRGB , there is NO advantage to using a working space with a larger gamut and there may well be an advantage (particularly if you use a Perceptual mapping to the output) in using the smaller sRGB space.
If we are to choose only one working space, should that working space be sRGB? Well, of course not, not unless all our output is going to the web. If we prefer to use only one working space then surely our preference will lead us to Adobe RGB or larger. But if we are happy to use different working spaces for different images ... well then sRGB could be a perfectly excellent choice for some images (but surely not for all).
Robert
-
This assumes that you want to make full use of the output gamut, and the only way you can do that is for your working-space to fully encompass the output gamut: no debate there!
That's what I want. I don't think giving my data a sloppy sex change operation is best practice. If the output is the internet, it's sRGB. Anything but that, it's different.
If we are to choose only one working space, should that working space be sRGB?
No, ProPhoto RGB. One can convert to sRGB from there, not the other way around (that be pointless). Remember what a working space really is (an output agnostic editing space primarily). If every means of previewing image data on the internet were indeed color managed, we'd have zero need for sRGB.
http://www.adobe.com/digitalimag/pdfs/phscs2ip_colspace.pdf
There are no prefect RGB working spaces.
Edit: typeface repaired.
-
Andrew, if you quote me I would appreciate you not adding bold to what I've written or quoting only part of a comment: that's not cricket, as the Brits would say.
Robert
-
If I were to choose only one working space it would be ProPhoto RGB, no question. Actually that is the only working space I use!
I'm suitably awed by all the 3-D diagrams showing how sRGB is sh... well not at big as other colour spaces. I've also seen elsewhere countless posts showing myriad dots of pixels way outside sRGB colour space.
Only, I come back to the fact that most of my images don't look very different on my larger-than-Adobe-RGB gamut monitor compared to the sRGB monitor that sits right next to it. Both are calibrated and profiled, and I can clearly see the difference between fully-saturated Adobe RGB colours on the two monitors. Sure, if I take pictures with bright colours, I can open the raw in Photoshop, and with soft proofing set to sRGB, the gamut warning will show me areas of OOG colours (usually quite small areas), but the difference is barely visible on the images. And yes - I do have normal colour vision.
That's why I think sRGB is by no means ideal, but not quite a disaster.
And quite often my stuff ends up on the web, or is sent electronically to people with monitors not profiled or calibrated, and has to be in sRGB anyway.
-
No one called it a disaster, it's just shitty as a working space (hence the s in the name ;)). It's just great for viewing on the media it was designed for, that's not print.
Simple matrix profiles of RGB working spaces like sRGB when plotted 3 dimensionally illustrate that they reach their maximum saturation at high luminance levels. They are based on an emissive device. The opposite is seen with print (output) color spaces. Printers produce color by adding ink or some colorant, while working space profiles are based on building more saturation by adding more light due to the differences in subtractive and additive color models. To counter this, you need a really big RGB working space like ProPhoto RGB due to the simple size and to fit the round peg in the bigger square hole the output device space encompasses.Then there is the issue of very dark colors of intense saturation which do occur in nature and we can capture with many devices. Many of these colors fall outside Adobe RGB (1998) and when you encode into such a space or smaller, you clip the colors to the degree that smooth gradations become solid blobs in print, again due to the dissimilar shapes and differences in how the two spaces relate to luminance. So the advantage of ProPhoto isn't only about retaining all those out-of-gamut colors it's also about maintaining the dissimilarities between them, so that you can map them into a printable color space as gradations rather than ending up as blobs.
-
Understood, Andrew, and I agree with that point.
-
I would like to correct what I said regarding the Perceptual gamut mapping from the working space to the destination. How this is achieved does depend on the profile maker and not all profiles will map the whole of the source gamut to the destination gamut. The reason for this is not necessarily that mapping part of the source gamut is better (although it may be) but rather because with many profiling programs, the source profile is not specified, so the mapping table has no knowledge of it. In that case I suppose it would have to use some arbitrary figure, which could leave OOG colors. With ArgyllCMS the source gamut must be specified and so it does know how to construct the Perceptual and Saturation mappings in relation to the source profile (the mapping has to be in relation to something, of course).
This link explains things better than I can, in relation to Argyll at any rate: http://www.argyllcms.com/doc/iccgamutmapping.html (http://www.argyllcms.com/doc/iccgamutmapping.html)
My apologies,
Robert
-
I would like to correct what I said regarding the Perceptual gamut mapping from the working space to the destination.
Thank you for that, Robert.
Warning: off topic part starts here.
And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.
http://www.google.com/patents/US5450216
It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe the concepts are available to all.
Jim
-
Thank you for that, Robert.
Warning: off topic part starts here.
And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.
http://www.google.com/patents/US5450216
It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe the concepts are available to all.
Jim
Hi Jim,
A plain English interpretation of this mapping system would be appreciated!
A quick look through the patent gives me this impression: that the both the luminance and chrominance of out of gamut colors (and also in-gamut colors) are mapped on the basis that:
- we are more susceptible to chroma that also has a high luminance
- for that reason, for every hue angle, the luminance for the maximum chroma is found
- OOG colors for each hue angle are then mapped in the direction of that luminance, with more OOG colors mapped a larger distance and small OOG filtered out
- in-gamut colors are also mapped in the same way, but to a lesser extent, to avoid ugly banding-type artifacts
- the chrominance of the mapped colors is also adjusted so that colors that have been lightened will have their chroma increased whereas colors that have been darkened will have their chroma decreased.
Is that the general gist of it?
It seems like a good idea, but I imagine that the implementation would be very difficult (not the maths of it, but getting the image to look right ... that is, what algorithms to use, exactly and how to go about tuning the model for a good visual effect ...).
Still, it would be nice to have this as an extra mapping intent within the ICC model. Perhaps someone could convince the ICC to add an extra intent called 'Experimental' :).
Robert
-
Actually, Tim, it is very much of practical use. You surely can't be serious when you say that there is no value in understanding what happens when an image is mapped from one color space to another? Or perhaps I've misunderstood you.
If you prefer to work entirely by experience then that's totally fine: it is another and entirely valid way of finding out what works and what doesn't. Experience cannot be replaced by theory - I don't dispute that. But why knock an attempt to understand what actually happens when A gets transformed to B?
Robert
I haven't seen you provide a better looking image directly connected to knowing how this works, nor have I produced a better looking image and I do understand what's going on.
It's just the work as been done and I paid for it in the software. I don't need to know how the code was written and how it produces the preview on my display or on my print. If the code doesn't give me what I want, I don't look under the hood to figure out what's wrong. I find other ways to get what I want which turns out to be a lot faster and better than your approach.
-
I haven't seen you provide a better looking image directly connected to knowing how this works, nor have I produced a better looking image and I do understand what's going on.
It's just the work as been done and I paid for it in the software. I don't need to know how the code was written and how it produces the preview on my display or on my print. If the code doesn't give me what I want, I don't look under the hood to figure out what's wrong. I find other ways to get what I want which turns out to be a lot faster and better than your approach.
I really do get it Tim ... you think I'm wasting my time, your time, everyone's time and that I should quit and go process some images. Well, as it happens I have to agree with you ... if I don't follow your advice I won't be able to pay the bills next month :'(
Robert
-
Thank you for that, Robert.
Warning: off topic part starts here.
And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today. It is more computationally-intensive than a straight 3D interpolation, but I don't think it would materially increase print times. I think it could be implemented in a manner compatible with ICC-managed systems. Mapping is performed independent of the source space.
http://www.google.com/patents/US5450216
It's not exactly unknown; it's been referenced 181 times by other patents. The patent has lapsed and I believe the concepts are available to all.
Jim
Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?
-
Mapping is performed independent of the source space.
Jim,
As you seem to be interested in this general topic and seem knowledgeable, I wonder if you would be kind enough to explain to me how a mapping is done without reference to the source (without an intelligent CMM that examines the image data and computes the mapping on the fly, that is)?
Referring to the image below, the top sketch is essentially how ArgyllCMS does it: because it knows the gamut of the source it can relatively intelligently work out how far the OOG pixels need to be mapped to bring them into gamut, and also how far the in-gamut pixels need to be mapped.
In the bottom sketch I show just the output gamut. Clearly the profile cannot know how far the pixels might be out of gamut. So on what basis is the mapping done? It would have to make an assumption on the source gamut, surely ... perhaps picking an intermediate gamut like Beta RGB? Then smaller gamuts would be mapped too much and larger ones would end up with pixels outside the intermediate gamut effectively clipped to the destination gamut. Is that not so?
(http://www.irelandupclose.com/customer/LL/src-v-nonejpg.jpg)
And would this also not apply to the method proposed in the patent?
BTW ... now that we seem to have gotten off the subject of sRGB etc., one of the reasons I use Beta RGB (and not sRGB :)) is that I can make a Perceptual profile for it that is optimized for its gamut. I could make multiple profiles for different working spaces, of course, but that would really be Gilding the Lilly!
Robert
-
Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?
I have to give it to you Tim ... you have me convinced! Never in the history of mankind has so much hot air been expended for so little elevation! (I have hot air baloons in mind). But, it's kind of fun ... and I suspect you get some fun out of it too, or you wouldn't be reading and commenting on the posts :).
Robert
-
A plain English interpretation of this mapping system would be appreciated!
A quick look through the patent gives me this impression: that the both the luminance and chrominance of out of gamut colors (and also in-gamut colors) are mapped on the basis that:
- we are more susceptible to chroma that also has a high luminance
- for that reason, for every hue angle, the luminance for the maximum chroma is found
- OOG colors for each hue angle are then mapped in the direction of that luminance, with more OOG colors mapped a larger distance and small OOG filtered out
- in-gamut colors are also mapped in the same way, but to a lesser extent, to avoid ugly banding-type artifacts
- the chrominance of the mapped colors is also adjusted so that colors that have been lightened will have their chroma increased whereas colors that have been darkened will have their chroma decreased.
Is that the general gist of it?
It seems like a good idea, but I imagine that the implementation would be very difficult (not the maths of it, but getting the image to look right ... that is, what algorithms to use, exactly and how to go about tuning the model for a good visual effect ...).
I think you've pretty much got it, Robert. The idea is to be able to change the luminance, not just the chroma, so that we don't have to make as big changes to the chroma as we otherwise would have to. Further, when we're making luminance changes, do it at low spatial frequency so that the viewer doesn't twig to the fact that we're messing with the luminance. Think of it as dodging and burning, but with the luminance changes averaged over neighborhoods, in the direction that makes the amount of chroma change you need to be smaller than it otherwise would be.
It ran fairly slowly on the computers of the day, but it took a minute or so to open a PhotoCD image on them.
In testing the algorithm, it worked very well if you didn't get too greedy -- make big luminance changes. There were color combinations that made it fail -- think of one color that needed its luminance raised right next to a color that needed its luminance lowered -- but in most implementations the result was to leave the luminance alone. There was no big win, but no loss either.
The whole thing depended, as do all gamut mapping algorithms that I know of, on having a color space in which you could adjust chroma and keep the same hue. Lab and Luv were just fair at that. Now, thanks to Bruce Lindbloom and others, we have spaces that are a lot closer to ideal in this respect.
Jim
-
Jim, can you produce a print of an image that takes advantage/benefits from this algorithm and take a photo of it and post it here, so we can all see how this is going to make our gamut mapping lives much easier?
Tim, I'd have to implement the algorithm in my present programming environment: Matlab. That'll take a week or so of coding. And, if I did it, I'd want to figure out how to use Bruce Lindbloom's modification of Lab. Still, it's a neat idea, and I'd like to try it if I get some time.
Jim
-
Jim,
As you seem to be interested in this general topic and seem knowledgeable, I wonder if you would be kind enough to explain to me how a mapping is done without reference to the source (without an intelligent CMM that examines the image data and computes the mapping on the fly, that is)?
The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.
Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.
Jim
-
I hope this isn't cold water thrown on an otherwise good thread, but BetaRGB does not contain the gamut of some current ink/paper combinations. I used BetaRGB for years, never had any problem with it, and though I'm not sure I saw a significant improvement, was secure in the knowledge all was well due to the comparison's and explanations on Bruce's sight. One improvement for sure, it was much easier to fit the profiled and color managed gamut of drum scanned color film into BetaRGB, than having to massage some colors down to fit into AdobeRGB.
When I got the 9900 and began testing and profiling many papers, I was surprised to find some combinations could print colors outside of BetaRGB. So in my opinion, there is still no ideal working space, to convert "from", if your primary work is editing for print, and printing. Joseph Holmes newer spaces look interesting, but those are smaller the 9900 gamut as well. ProPhoto, and maybe one or two others a bit obscure, (Wide Gamut?), are the only ones big enough, assuming printer gamut containment is THE criteria. As others in the thread have shown, they may be less than ideal.
Tyler
-
One improvement for sure, it was much easier to fit the profiled and color managed gamut of drum scanned color film into BetaRGB, than having to massage some colors down to fit into AdobeRGB.
Tyler
Referencing what I had to do with the orange flower edit demo posted earlier in the thread, what do you mean by "fit" the gamut of drum scanned color into BetaRGB that wouldn't fit in AdobeRGB and what did that involve? How did it manifest to tell you that was the problem? Do you mean you had to edit color detail so it didn't turn into blobs of posterized color as I had to do in the orange flower? Or was all this "not fitting" manifested in the print?
-
Joseph Holmes newer spaces look interesting, but those are smaller the 9900 gamut as well.
Not D Cam4 or D Cam5 (http://www.josephholmes.com/propages/gamuts/DCam5.jpg). This profile (DCam 5) makes ProPhotoRGB looks small and it is the only profile I have seen that ecompasses all visible colors (not even LAB)
-
The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.
Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.
Jim
Jim, thanks for this. I hope what you propose continues to evolve and gets into commercial software soon.
-
Hmm, well it's entertaining (and somewhat informative, I must admit) to see a rip-roaring tussle over working spaces again. Thanks!
Not to hijack the thread, but I did see a couple posts that seemed reminiscent of the concept about converting to a final output space that is small, e.g., sRGB - what is the current thinking about the idea advanced in the past that one can get a better final result by converting in steps - e.g., from ProPhoto (large) original to AdobeRGB (smaller) as a transition, then to final destination sRGB?
Some of the image examples posted earlier in this thread seem intended to support this scheme, no?
John
JWL Images
Emeryville, CA
-
The algorithm that I proposed does examine the image data and computes the mapping on the fly. All it requires is the image in a color space appropriate to gamut mapping (like Bruce's modification of Lab) and the gamut of the output device in that same space. The gamut of the space in which the image was created is irrelevant.
Knowing the source space could be useful in supplying "hints" to the gamut mapping algorithm, sort of like Postscripts hints help in rasterizing fonts. I think explicit hints to gamut mappers could help a lot. You could say we already have one set: rendering intent, but a bunch of knobs with labels like "maximize chroma", "concentrate on these [ a list of values] colors", "make it pop", "make it subtle", etc. There may be some of that slipping into custom ICC profiles; X-Rite lets you build printer profiles that are optimized (in what way I don't know) for certain images.
Jim
Jim, thanks for the clarification on the algorithm ... I had missed the (crucial) point of the luminance changes being limited to low spacial frequencies.
OK, so this is effectively a new CMM which incorporates the gamut-mapping strategy, which is surely a better way to go if you want a good Perceptual mapping (algorithm and performance issues aside). How do you see it fitting in with the current ICC model (the only way I can see it myself is that the new CMM would override the Perceptual mapping in existing profiles).
Robert
-
Hmm, well it's entertaining (and somewhat informative, I must admit) to see a rip-roaring tussle over working spaces again. Thanks!
Not to hijack the thread, but I did see a couple posts that seemed reminiscent of the concept about converting to a final output space that is small, e.g., sRGB - what is the current thinking about the idea advanced in the past that one can get a better final result by converting in steps - e.g., from ProPhoto (large) original to AdobeRGB (smaller) as a transition, then to final destination sRGB?
Some of the image examples posted earlier in this thread seem intended to support this scheme, no?
John
JWL Images
Emeryville, CA
Hey John ... you most certainly are not hijacking the thread because I started it and the whole thrust was the advantage of using as small a workspace as possible, so that Perceptual mappings would cause the least damage possible.
The corollary to this is that if you prefer to work in a large working space, as many of us do for various reasons, then there may be an advantage when doing a Perceptual mapping to first convert the image to a smaller working space. The reason for this, as I've tried to explain with little success :), is that a Perceptual mapping effectively 'squeezes' the working space gamut (or some approximation of it) into the destination gamut. The result may be that saturated colors in the image will end up less saturated. As i1Profiler says: "The perceptual intent is intended to preserve the look and feel of the original image, maintaining tone and detail as a first priority, and saturation/color accuracy as a second priority" (bold on 'saturation' and 'second priority' from me).
The idea behind the 2-step mapping is that the first step is a Relative Colorimetric one from the large working space to the smaller one (of course there is a need to watch out for out-of-gamut issues when doing this); followed by the 2nd step which a Perceptual mapping to the destination. What this should do is to reduce the desaturating effect of the Perceptual mapping from the original (large) workspace.
There is no advantage to using a 2-step approach for Relative or Absolute Colorimetric but there should be for Perceptual and Saturation. Since converting from any workspace to another workspace (say ProPhoto to sRGB) is always Relative Colorimetric, there is no benefit from doing a 2-step from ProPhoto to sRGB. The destination profile has to be for print (or to output profiles that use LUTs).
If we do not want to use this 2-step approach (but do want to try to get a better Perceptual mapping), the various profiling programs offer some alternative mechanisms:
i1Profiler gives some controls to attempt to improve the Perceptual mapping (for example to weight the profile towards saturation ... presumably at the expense of color accuracy). You can also optimize the profile to your particular image (I don't know what the effect is, except, presumably, to add additional spot colors to reduce the amount of interpolation required).
ArgyllCMS has a more intelligent algorithm, I think. When you build a profile with Argyll you specify the source gamut. So you can specify, for example, that your source gamut is AdobeRGB and then the profile knows that your images will all be within AdobeRGB, so the Perceptual mapping is only from AdobeRGB and not some bigger gamut: this should reduce the desaturating effect of the Perceptual mapping.
With Argyll you can go quite a big step further as you can build the profile for a specific image (or for a range of images). The Perceptual mapping is then fully optimized to that image (or range of images), so it should give the best Perceptual mapping. The downside is that you can't use this profile for other images.
Robert
-
Tim, I'd have to implement the algorithm in my present programming environment: Matlab. That'll take a week or so of coding. And, if I did it, I'd want to figure out how to use Bruce Lindbloom's modification of Lab. Still, it's a neat idea, and I'd like to try it if I get some time.
Jim
I didn't realize you had actually implemented the algorithm Jim ... the final one in the patent I guess? Very interesting ... I hope you do get to the time to re-code it! If you do I'll be happy to do some testing :).
Robert
-
I know I should post this in the 'Adobe Raw Q&A section', but I don't want to start a whole new topic, and the question is very much related to this thread. (I have searched the forum and I haven't found a reply, although no doubt it's there, so if anyone knows where the relevant thread is, please let me know!).
Anyway, my question/comment relates to raw Smart Objects in Photoshop, and backward compatibility. If I understand things correctly, if I have an image with a raw SO in Photoshop CC, opened from Lightroom with PV2012 (or from ACR with PV2012), I can edit the same image in Photoshop CS6 as it also has PV2012 support. However, although I can open the image in CS4, say, I can no longer edit the raw SO (well, I can edit it, but it will get changed simply by opening it and closing it) as CS4 doesn't have PV2012 support. What that means to me is that if I ever want to go back to CS6 that the critical thing NOT to do from later versions of Lightroom or Photoshop CC is to use a process version greater than PV2012 (when that gets introduced). Is that correct?
My second question relates to camera support and process version. If I find that I need to use the latest version of ACR because I've just bought myself a new camera, does this mean that I will then have to use the latest process version (say PV2015) in order to have support for my camera? I think the answer is no, that the camera support is not tied in to the process version (since I can process a 1DsIII image in PV2003).
So, as far as raw smart objects in Photoshop are concerned, we should be able to go back to CS6, providing we stick to PV2012; and as long as Adobe continues to sell perpetual versions of Lightroom, we should be relatively confident to be able to stay in PV2012 and be able to go back to CS6. Or is it worse than that?
Robert
-
AFAIK, all a SO is, is another copy of the full sized raw embedded into some Photoshop document. Whatever you can do with the raw as a SO, you can do without that raw being there. You can always update the instructions, moving from PV to PV, it's the metadata that counts. Seeing the raw along with other Photoshop components unique to PS is neat and useful I suspect (I admit not using them, all my raw work is done in LR). But short of that, it's a much bigger document and unless I'm missing something else, whatever flexibility you have to alter from raw, it's the same using either process.
-
OK, so this is effectively a new CMM which incorporates the gamut-mapping strategy, which is surely a better way to go if you want a good Perceptual mapping (algorithm and performance issues aside). How do you see it fitting in with the current ICC model (the only way I can see it myself is that the new CMM would override the Perceptual mapping in existing profiles).
When I left the color management biz, ended my six-year vacation in research (IBM big-R Research, where, as we used to say, where the rubber meets the sky) to return to product development (I finished out my career as VP Engineering at Echelon), the ICC existed, and I was working with them although IBM never joined (some intellectual property issue, as I remember). When I left IBM in 1995, the ICC was only 2 years old. Therefore, my knowledge of everything that's happened since is as a user of the technology, not a developer or researcher. So what I'm about to say is suspect. But I'm going to say it anyway; just take it with a grain of salt. Andrew knows more than I do about the current inner workings of color-managed software, so maybe he'll chime in if I err.
A color rendering engine (ICC terminology: CMM), like the one in Adobe Ps, has as its inputs 1) the source image data, 2) the ICC profile of the source space, 3) the rendering intent, 4) the ICC profile of the output space, 5) other user inputs particular to the rendering engine, such as what to do about black and/or white point mismatches. There are ICC-suggested ways to use these inputs, but the engine is not constrained to follow them. In fact, the ICC says that people developing profiles and software are free to use whatever color mapping algorithms please them for the perceptual and saturation intents. Although the ICC profiles assume that rendering is a point process, and it would be a distortion of their intent for implementers to not adhere to that for the absolute colorimetric and relative colorimetric intents, it doesn't force all mappings to be point processes. For the perceptual and saturation intents, the CMM is allowed to use the input and output profiles in any way it chooses to come up with the mapping from input to output. In fact, the ICC, without explicit definition of the operations, calls CMMs that perform various optimizations outside the scope of the ICC specifications "smart" CMMs. The ICC also explicitly says that the same vendor could offer different perceptual rendering intents that provide different "looks", so having many different ways to do perceptual rendering isn't verboten.
So, all of that is a long-winded way of saying, yes, you're right.
Jim
-
The idea behind the 2-step mapping is that the first step is a Relative Colorimetric one from the large working space to the smaller one (of course there is a need to watch out for out-of-gamut issues when doing this); followed by the 2nd step which a Perceptual mapping to the destination. What this should do is to reduce the desaturating effect of the Perceptual mapping from the original (large) workspace.
Sounds to me like you don't like some perceptual mapping implementation and you're fooling it by coming up with a two-step approach to get what you want. I think this would be hit-or-miss. It might do what you want for some images, and something you don't want for others.
Jim
-
I didn't realize you had actually implemented the algorithm Jim ... the final one in the patent I guess? Very interesting ... I hope you do get to the time to re-code it! If you do I'll be happy to do some testing :).
I implemented many versions in a mixed programming environment with some calculations done in Smalltalk (easy to use, but slow), and the real image crunching done in an IBM-internal image processing language. I don't have any of the code (it belongs to IBM, not me), so I'd have to start over. There's a problem with a Matlab implementation: you need to buy a $5K license from them to distribute an executable. Without that, anybody using the code would have to buy a Matlab user license, including the Image processing toolkit. Not very practical.
I wonder if there's a way to do something similar as a Photoshop action? I'll think on it.
Jim
-
In fact, the ICC, without explicit definition of the operations, calls CMMs that perform various optimizations outside the scope of the ICC specifications "smart" CMMs. The ICC also explicitly says that the same vendor could offer different perceptual rendering intents that provide different "looks", so having many different ways to do perceptual rendering isn't verboten.
Jim
That explains a lot about the behavior of the rendering intents of the Fuji Frontier drylab profile created with ArgyllCMS by Fuji staff I downloaded off Fuji's European site just to see if the RI's made a big difference. 10 years ago when these discussions were still going on I was using DryCreekPhoto profiles for local RA-4 process Noritsu wetlabs lazer exposed silver halide printer that reproduced most DSLR colors adequately but would screw up other colors that were beyond its gamut I had to assume.
None of the rendering intents from those DryCreek profiles made a dent in fixing OOG. Fast forward 10 years later to the newer Fuji Frontier inkjet/drylab printer and the AgryllCMS RI's weren't needed because (I'm assuming) this printer's expanded gamut could handle a lot more colors my DSLR/Raw processing could throw at it.
Another issue I noticed about these print experiments is I had to make far bigger changes to the edits to see a difference over what the RI's would provide. I printed several copies of the same file converted using different rendering intents and couldn't tell any of them apart.
-
my apologies for jumping in too quickly, based on faulty memory... some clarifications
Referencing what I had to do with the orange flower edit demo posted earlier in the thread, what do you mean by "fit" the gamut of drum scanned color into BetaRGB that wouldn't fit in AdobeRGB and what did that involve? How did it manifest to tell you that was the problem? Do you mean you had to edit color detail so it didn't turn into blobs of posterized color as I had to do in the orange flower? Or was all this "not fitting" manifested in the print?
badly stated.. I did not "fit" the gamut, I "fit" colors in the image that, due to film and scanner gamut would not fit in the working space, would be clipped after conversion. I never made these decisions based on eventual output gamut as that changes with device. This was for "master" files. So it's just the usual tools as I'm sure you understand, hue/sat, selective color, replace color, etc.. while still in the input space. OOG warning, using the working space in preview, was rarely as informative as necessary, so it tended to be trial and error. Editing in input spaces is not ideal, but if limited to the few image colors outside the eventual conversion, it works, and what other way is there to avoid clipped color? My understanding is that evaluating input gamut is tricky at best, but the normal tools like colorthink show a Howtek profile from a Hutch target as much larger gamut than most of the usual working spaces, including BetaRGB, even ProPhoto in very minor places. Whether or not this is a problem is image dependant. I'm sure all this translates over into captures as well, although you will find other threads here about the difficulties of the concept of gamut as it applies to capture.
Not D Cam4 or D Cam5 (http://www.josephholmes.com/propages/gamuts/DCam5.jpg). This profile (DCam 5) makes ProPhotoRGB looks small and it is the only profile I have seen that ecompasses all visible colors (not even LAB)
My info was incomplete, based on one 3Dgamut map provided by Holmes, I had forgotten it was based on DCam3, which could not contain the gamut of even a 9800. I can not test the others without purchase if I recall. 2D comparisons are inadequate, 3D is required. A 2D mapping shows BetaRGB as containing the gamut of my 9900/HarmonGlossBaryta profile, while a 3D mapping reveals cyans that BetaRGB can not contain. I'm sure your info about the larger spaces is correct, but 3D mappings would be interesting to see. Additionally, spaces that large put us back to the problem of less than ideal perceptual conversions to output, and I still think the ideal print centric working space remains illusive. PhotoGamut was an interesting idea, but too small right out of the gate. Image referenced smart CMMs, as Jim referenced, was an interesting idea, I don't think anything really came of it.
There are proponents of only colormetric conversions to output space, massaging only those colors that would be out of printer gamut into place pre-printing, there's something to be said for that. Hope I haven't gone to far OT.
-
AFAIK, all a SO is, is another copy of the full sized raw embedded into some Photoshop document. Whatever you can do with the raw as a SO, you can do without that raw being there. You can always update the instructions, moving from PV to PV, it's the metadata that counts. Seeing the raw along with other Photoshop components unique to PS is neat and useful I suspect (I admit not using them, all my raw work is done in LR). But short of that, it's a much bigger document and unless I'm missing something else, whatever flexibility you have to alter from raw, it's the same using either process.
I'm not sure if I quite understand you Rodney.
My concern is simply this: will I be able to go back to Photoshop CS6 to process an image that contains a raw smart object that has been created in some future version of Photoshop CC / ACR?
(The reason for my concern, obviously, is that I don't want to have no way out of the CC pay-as-you-go model. With Lightroom it's not a problem right now because I do have a perpetual license (as I do with Photoshop CS6) and as long as Adobe allows upgrades I'm happy. The day that Lightroom becomes pay-as-you-go only is the day that I will be thinking seriously about getting out.)
I think backward compatibility with Photoshop CS6 is OK in most areas, but smart objects/smart filters in general are potential trouble. For example, if the smart filter is a new filter, clearly it won't function in CS6. Of course I could always rasterize the smart objects, but that would mean going through all of my tiffs and psds before unsubscribing to CC. Similarly, I think that if the smart object uses a process version > PV2012 that it won't function correctly in CS6.
So if this is true, then I would make sure that I do not have smart objects in my files that use post CS6 filters or raw smart objects that use process version > PV2012.
I'm just checking with you guys to see if I've got this right, or if there are other gotchas that I haven't thought of. Or is there a workaround I haven't thought of (for example, some clever way to edit the raw file in the smart object using Lightroom)? Or some information about how Adobe are going to handle this sort of backward-compatibility issue that I'm not aware of (for example by releasing versions of ACR that will run with CS6 to handle post PV2012 process versions)?
Robert
-
OOG warning, using the working space in preview, was rarely as informative as necessary, so it tended to be trial and error.
Tyler,
What did you go by that forced this trial and error editing session? Was it color detail distortion in the preview? or OOG warning from some analytic scanner GUI?
It is about the preview. It has always been about the preview. Did the preview generated in the scanner interface during capture stay the same opening the final scan in Photoshop and assigning the source scanner profile if it wasn't already tagged by the scanner software?
Without it manifesting in the preview on the display there is NO PROOF that OOG is going on or whether it is degrading the image preview. You're in theory land and I'm trying to get you tell us whether you were relying on theory from OOG analytics or the preview.
-
Tyler,
What did you go by that forced this trial and error editing session? Was it color detail distortion in the preview? or OOG warning from some analytic scanner GUI?
It is about the preview. It has always been about the preview. Did the preview generated in the scanner interface during capture stay the same opening the final scan in Photoshop and assigning the source scanner profile if it wasn't already tagged by the scanner software?
Without it manifesting in the preview on the display there is NO PROOF that OOG is going on or whether it is degrading the image preview. You're in theory land and I'm trying to get you tell us whether you were relying on theory from OOG analytics or the preview.
Nope no theory. Sorry I was not clear, simple conversion from input space to working space.. are any color channels clipped? If so.. undo and work those colors. I never let the scanner software convert, for this reason, it only assigned the scanner profile, conversion later in PS, per above
-
Sounds to me like you don't like some perceptual mapping implementation and you're fooling it by coming up with a two-step approach to get what you want. I think this would be hit-or-miss. It might do what you want for some images, and something you don't want for others.
Jim
Hi Jim,
In general I use relative rather than perceptual, unless the clipping is too severe (I prefer the print to be as close to the image as possible). But sometimes that's not possible because the image colors are too far out of gamut. Trying to punch these pesky pixels into port can do more harm than good (and I completely agree with Andrew on this), but with some images the perceptual mapping can result in the more saturated colors getting desaturated (which is presumably one of the reasons for your invention).
If that happens I (currently) have four options:
1. Do a perceptual conversion to the destination profile and carefully and selectively fix the problem from there.
2. Do a 2-step relative/perceptual mapping. The intermediate working space needs to be big enough so that the clipping is not a problem and yet small enough so that the perceptual mapping works well.
3. Make an image-specific profile using Argyll with the image gamut as the source gamut. This may result (should result) in an improvement over the straight perceptual mapping.
4. Use a different profile to see if that works better, or try to optimize the profile to improve the saturation (for example by tweaking the perceptual intent custom sliders in i1 Profiler).
In all cases I'm trying to fit a triangle into a smaller blob, of course, so any solution is going to be a compromise. So it's not a question of fooling anything, and I don't have a particular bias towards any one of these techniques: it's just a question of trying to understand the options available and working as best as I can within the constraints of the system.
Robert
-
Nope no theory. Sorry I was not clear, simple conversion from input space to working space.. are any color channels clipped? If so.. undo and work those colors. I never let the scanner software convert, for this reason, it only assigned the scanner profile, conversion later in PS, per above
How was the preview affected by the clipped data?
My orange flower demo is totally clipped in sRGB and wasn't when I edited the Raw file to look as it should in ProPhotoRGB. All the detail in the preview was retained in sRGB and printed just fine to a printer whose 3D gamut model says it can't reproduce sRGB's 255 red channel.
Yes, it's just theory until you see it affect the preview.
-
My concern is simply this: will I be able to go back to Photoshop CS6 to process an image that contains a raw smart object that has been created in some future version of Photoshop CC / ACR?
The raw Smart Object is just a copy of the raw so yes you can get access to that raw (you have another floating around too). How any or all of this interacts with Photohsop elements you've created that are newer and may not be understood by earlier versions of Photoshop is a different possibility. But the raw in the SO is just that, a raw which is read only.
-
How was the preview affected by the clipped data?
My orange flower demo is totally clipped in sRGB and wasn't when I edited the Raw file to look as it should in ProPhotoRGB. All the detail in the preview was retained in sRGB and printed just fine to a printer whose 3D gamut model says it can't reproduce sRGB's 255 red channel.
Yes, it's just theory until you see it affect the preview.
I guess we value and utilize previewing differently. In the particular case I am describing, very early in the workflow, it's all about the histogram.
-
No my images ;D It's far too small. Even output to CMYK (SWOP V2), sRGB clips colors. Did you see my video on gamut? It's OK for web because of how it's based. It's not ideal for print, there are no sRGB printers. If you are concerned with gamut clipping, sRGB isn't the space you'd ever consider using for anything but posting to the internet. And someday, should wide gamut displays be the norm, we'll point towards Adobe RGB (1998) instead of sRGB.
Hi Andrew,
I've had a look at your excellent video on gamut. You have a real talent for explaining complex things in a way that is very understandable and interesting!
I've had another look at sRGB v print profiles (with good gamuts and black point) and it is clear that there is a risk of clipping of the saturated dark colors (in the case of Canson PhotoHiGloss in the greens/blues), even in an image that appears quite unsaturated. The same is true but to a lesser extent with Adobe RGB. Beta RGB is fine as is ProPhoto, of course.
So I regretfully concede that sRGB is not the best working space for print (not that I ever suggested that it was, at least not globally, for all images irrespective of gamut and saturation). Of course it's fine for black and white prints and for images that really do have very low saturation throughout.
Robert
-
I guess we value and utilize previewing differently. In the particular case I am describing, very early in the workflow, it's all about the histogram.
Then I take it the preview is not affected by clipping in the histogram. Thanks for confirming.
-
The raw Smart Object is just a copy of the raw so yes you can get access to that raw (you have another floating around too). How any or all of this interacts with Photohsop elements you've created that are newer and may not be understood by earlier versions of Photoshop is a different possibility. But the raw in the SO is just that, a raw which is read only.
Actually, Andrew, I don't think you're right. Just try this if you can: create an image with a raw smart object that has been developed to PV2012. Save the image. Open it in Photoshop CS4. Open and close the raw smart object. What do you see? Nothing should have happened, right? Wrong. The raw smart object has the development settings from PV2012 and when you open it in CS4 this gets changed to PV2003 and the development is kaput. The whole purpose of having the raw smart object is obliterated (well, almost). Sure, the raw image is still there - but the development settings it had are gone.
This is more of an issue than you think, IMO.
Robert
-
The SO/ raw wasn't changed, some metadata about it might be. The equivalent of the sidecare, embedded I suspect in the PS document. If you had a raw and some metadata that said you wanted PV 2012, then you took both back to ACR or LR that was older than that PV, it wouldn't show it of course, it would "refert" to PV2010 or PV2003. I don't think that's different in Photoshop expect one would suspect the version of ACR understands the most modern features. But going back, it's the instructions that are not recognized. I don't see how the SO is different but again, I'm an novice in their use.
-
I guess we value and utilize previewing differently. In the particular case I am describing, very early in the workflow, it's all about the histogram.
Do you know the joke about the drunk looking for his keys? If you don't I'll be happy to tell it. If you do, when it comes to controlling image gamut when editing in an RGB color space, the histogram is the lamppost.
The histogram allows you to make sure that you're not exceeding the gamut of the editing color space, but is useless as a measure of how you're doing wrt gamut of any output space that happens to be different. If you're editing in PPRGB, the output space is guaranteed to be different. The only reason it seems to work fairly well is that, as Andrew has already pointed out in this thread, in good editing color spaces R=G=B=x defines the neutral axis. Couple that with the property of RGB color spaces that the chromaticity gamut is small near the white point, and smell near the black point, and you can see that the chromaticity the top and the bottom of fully-populated histograms doesn't have much room to move around.
Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images. Flowers, not so much.
I think we need other tools floating over the image like the histogram window, tools that take samples of the image like the histogram does, but displays those samples in some device-independent color space in cylindrical coordinates with a luminance axis, a chroma radius, and a hue angle. The user could then superimpose her choice of output device gamuts in the same display. As the user edited the image the display would keep up in real time, like the histogram (sort of) does.
Or maybe there's another way to present the information. I'm open to suggestions. As has been pointed out in this thread, gamut alarms are limited in that they don't tell you how far out you are. Maybe there's a way to modify them --false color? -- so they do.
Jim
-
Then I take it the preview is not affected by clipping in the histogram. Thanks for confirming.
Sorry Tim, I honestly don't know what you are getting at. I'd not assume it is or isn't, I'm not "confirming" anything.. I'm not paying much attention to it yet. My primary task in the very beginning is to have ALL the info. What is done with it from there on out can be subjective and previewing becomes increasingly important. But initially, I have to have a file with integrity, no clipped channels, among other things. With regard to scanning, a color managed workflow, which ONLY applies to transparencies, depends on sound practice, good profiles, and adequate working spaces and/or conversion process to it. Now I have, in PS, the most accurate digital representation of the film I can muster, have thrown no info away, and am in a suitable perceptually uniform editing and storing space. From there on out it's artistic or corrective decisions and previewing comes more into play. Obviously little of this is relevant these days, input color management is an evolving animal with regard to capture.
I think we've strayed OT, my initial post was regarding BetaRGB, it's relevance in light of increasing output device performance, and the general point of useful working spaces, why aRGB fell sometimes fell short in that workflow. Is there something you are getting at I'm not understanding?
-
Sorry Tim, I honestly don't know what you are getting at. I'd not assume it is or isn't, I'm not "confirming" anything.. I'm not paying much attention to it yet. My primary task in the very beginning is to have ALL the info. What is done with it from there on out can be subjective and previewing becomes increasingly important. But initially, I have to have a file with integrity, no clipped channels, among other things. With regard to scanning, a color managed workflow, which ONLY applies to transparencies, depends on sound practice, good profiles, and adequate working spaces and/or conversion process to it. Now I have, in PS, the most accurate digital representation of the film I can muster, have thrown no info away, and am in a suitable perceptually uniform editing and storing space. From there on out it's artistic or corrective decisions and previewing comes more into play. Obviously little of this is relevant these days, input color management is an evolving animal with regard to capture.
I think we've strayed OT, my initial post was regarding BetaRGB, it's relevance in light of increasing output device performance, and the general point of useful working spaces, why aRGB fell sometimes fell short in that workflow. Is there something you are getting at I'm not understanding?
The points made by everyone in this thread are all relevant to the subject of working spaces as gamut containers especially whether there is or isn't a connection to how it relates to quality previews. Folks don't pay for histograms, they pay for a quality preview of the image. We're trying to connect functionality to the working space concept.
I understand your requirements to capture all data according to a histogram. I've read in some Adobe forum discussions in the past some stock agencies not accepting images with clipped data even in an 8 bit sRGB jpeg. You're workflow describes best practices established by a histogram at the scan stage. Understandable. But I was trying to pin you down on you're first statement that suggested you were manipulating the source scan data to deliver a better histogram with a disregard to what it did to the preview. That's why I was asking about the quality of the preview. Did the preview distort or change going strictly by histogram analytics?
I've noticed the same concerns editing an audio waveform. Nobody wants clipping because they think it creates distortion in the sound, but there are folks doing this and reporting no change in sound quality, just loudness. In fact the aiff file for Propellerheads' "On Her Majesty's Secret Service" viewed in Audacity is a brick wall of clipped data but I swear I've never heard such fuller, louder dynamics in a piece of pop music than this selection that didn't destroy my speakers with tons of audible artifacts. It's bass heavy down to about 30hz, loud and filled with noise from the sampled original '60's movie theme. Listening on headphones is pretty scratchy sounding but in my car it's kicks ass loud and clean with no audible artifacts especially in the bass which is HEAVILY clipped.
-
"On Her Majesty's Secret Service" viewed in Audacity is a brick wall of clipped data but I swear I've never heard such fuller, louder dynamics in a piece of pop music than this selection that didn't destroy my speakers with tons of audible artifacts. It's bass heavy down to about 30hz, loud and filled with noise from the sampled original '60's movie theme. Listening on headphones is pretty scratchy sounding but in my car it's kicks ass loud and clean with no audible artifacts especially in the bass which is HEAVILY clipped.
If it looks better and sounds better clipped, that's all that counts for me.
-
If it looks better and sounds better clipped, that's all that counts for me.
Yeah, and from further research Flaming Lip's "At War With The Mystics" album has similar dynamics by engineer Dave Fridmann and that album won a 2007 Grammy for Best Engineered Non-Classical album, but the Loudness War bitchers still complained. Rush's 2002 "Vapor Trails" didn't get loving care in the studio amped up to 11 (it sounds really bad, I checked) and was remixed quieter in 2013.
Some engineers are just too heavy handed compressing detail, squeezing the dynamics with the equivalent of Adobe's Highlight Recovery without retaining black point.
-
The SO/ raw wasn't changed, some metadata about it might be. The equivalent of the sidecare, embedded I suspect in the PS document. If you had a raw and some metadata that said you wanted PV 2012, then you took both back to ACR or LR that was older than that PV, it wouldn't show it of course, it would "refert" to PV2010 or PV2003. I don't think that's different in Photoshop expect one would suspect the version of ACR understands the most modern features. But going back, it's the instructions that are not recognized. I don't see how the SO is different but again, I'm an novice in their use.
Hi Andrew,
Absolutely ... the embedded raw image isn't touched at all ... same as in Lightroom. There's no history in ACR and you can't go back into the SO and do an undo of a previous step, but the edits are totally reversible, so clearly the raw data isn't changed. The editing instructions must be stored as they are in a sidecar, but inside the psd or tif.
So there's no concern about losing the raw image (anyway, I always keep the original raw file with its xmp file, so I can always go back to that). That isn't my concern.
If you think of the Photoshop workflow it will make the issue clearer. OK, I open the image as a raw SO in Photoshop. Fine, no problem, I can then add adjustment layers, apply a sharpening filter to the SO, crop, straighten, whatever. Now I decide that the yellow saturation needs a tweak, so I double-click on the SO, do the edit in ACR and exit back into Photoshop. And so on.
Now imagine that this scenario happened not now, but in 3 years time, when Lightroom/ACR has moved on to PV2016, say, so that my SO has all of its adjustments in the PV2016 context (the sliders may be different to PV2012, the effect of the sliders may be different, the demosaicing algorithm may have changed, affecting the look of the image etc.). But now I decide I've had enough of CC, I don't want to continue to pay what has become an unacceptable annual fee for Photoshop, I am only using Photoshop occasionally by then ... whatever, basically I want to go back to the version of Photoshop I own, which is CS6.
I open the image in CC ... fine, no problem. I decide to make a tweak to the raw SO ... I go into it ... and, hey, everything's changed ... the colors have changed, the brightness has changed ... it's just wrong! When I go back into Photoshop the whole image has changed, even though I made no changes myself to the SO. The problem is that ACR has reverted to PV2012, but the raw image was 'edited' in PV2016. To give you an idea of how drastic this is, if you open a SO in PS CS4 that has been created using PV2012, the image is flipped horizontally, so left becomes right and right becomes left!
All is not lost, of course. I can go back to the original raw image and re-develop it; I can go into ACR and correct the image based on PV2012 editing, trying to get it back to what it was in PV2016. So it's not as though I've lost the original, I've just lost the ability to modify the raw SO without having to redo the whole raw phase of the development. It would be sort of equivalent to an image created in CC2016 with multiple layers, filters etc., opening fine in CS6, but flattened so that all the adjustment layers, smart filters etc are lost. Not quite as bad as that, but not far off.
Does that make sense? So then to ensure backward compatibility we should not move to the next raw process version, but stay in PV2012 as that will (should) allow us to go back to PS CS6.
The same thing is true of Lightroom ... if you go back to Lightroom 1 and try to edit a file that has been developed in Lightroom 5 with PV2012 you will have to pretty well redo the development. I think with Lightroom you can to some extent avoid this problem by using DNGs? But the problem doesn't really arise with LR at this point because we can (still) purchase it outright, so you can always freeze your development environment (that's assuming that what you freeze will still run on whatever OS is available in the future ... another whole can of worms!).
Robert
-
Couple that with the property of RGB color spaces that the chromaticity gamut is small near the white point, and smell near the black point, and you can see that the chromaticity the top and the bottom of fully-populated histograms doesn't have much room to move around.
I don't quite understand what you are saying, but I think what you mean is that relative to the body of the image the regions at either end are quite narrow (a bit like the top and bottom of an apple) ... and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less). I suppose one solution to that would be to have a histogram that is not linear, but which stretches the dark and light regions. Or is it more than that, and are you saying that WE don't have much room to play around with at either end? I guess this is where a full editing program like Photoshop comes into its own, as we can selectively focus on just these regions (more easily than in Lightroom).
Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images. Flowers, not so much.
Why is it that we are lucky? We can always adjust the saturation of individual colors, surely, so if we adjust the red but it's quite separated from the blue ... so what? I think I'm definitely missing something here.
I think we need other tools floating over the image like the histogram window, tools that take samples of the image like the histogram does, but displays those samples in some device-independent color space in cylindrical coordinates with a luminance axis, a chroma radius, and a hue angle. The user could then superimpose her choice of output device gamuts in the same display. As the user edited the image the display would keep up in real time, like the histogram (sort of) does.
Or maybe there's another way to present the information. I'm open to suggestions. As has been pointed out in this thread, gamut alarms are limited in that they don't tell you how far out you are. Maybe there's a way to modify them --false color? -- so they do.
I think a good dE-type color map as a window under the histogram (in soft-proofing mode) would be VERY useful. Something like this:
(http://www.irelandupclose.com/customer/LL/preview.jpg)
If the editing could then be masked by the color map (more effect towards higher deltas, or edit selected range of deltas) it would be really fantastic.
Robert
-
I don't quite understand what you are saying, but I think what you mean is that relative to the body of the image the regions at either end are quite narrow (a bit like the top and bottom of an apple)
I guess I assumed too much in my post. Let me unpack the relationship of chromaticity and luminance in RGB spaces that I was trying to get at.
Any (real or imaginary) monitor-based RGB color space (called by most just an RGB color space) can be envisioned as a cube, with orthogonal red, green, and blue axes joined at the origin (R=G=B=0). Those axes form three edges of the cube. The cube has six faces defined by the following equations, assuming full scale is unity.
R=0, R=1, G=0, G=1, B=0, B=1
Those faces define the gamut of any RGB color space in its own color space.
Now imagine tipping the cube so that it rests on the vertex R=G=B=0, and the vertex R=G=B=1 is straight up from there. So the black point is at the bottom, the white point is at the top, and the luminance diagonal or gray axis, defined as R=G=B=x, where x is any number in the range [0,1], is straight up and down.
You can see that dark colors, near the black point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the black point. Light colors, near the white point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the white point.
The small gamuts near the black and white points map over roughly when the cube is transformed into a color space like CIEL*a*b*, yielding small chromaticity gamuts near the white and black points.
Better?
More to come when I get more time.
Jim
-
If you think of the Photoshop workflow it will make the issue clearer. OK, I open the image as a raw SO in Photoshop. Fine, no problem, I can then add adjustment layers, apply a sharpening filter to the SO, crop, straighten, whatever. Now I decide that the yellow saturation needs a tweak, so I double-click on the SO, do the edit in ACR and exit back into Photoshop. And so on.
Now imagine that this scenario happened not now, but in 3 years time, when Lightroom/ACR has moved on to PV2016, say, so that my SO has all of its adjustments in the PV2016 context (the sliders may be different to PV2012, the effect of the sliders may be different, the demosaicing algorithm may have changed, affecting the look of the image etc.). But now I decide I've had enough of CC, I don't want to continue to pay what has become an unacceptable annual fee for Photoshop, I am only using Photoshop occasionally by then ... whatever, basically I want to go back to the version of Photoshop I own, which is CS6.
I don't see this being any different in the results if you use an SO or not. That's my confusion with your issue. If you use a newer processing (PV 2016) that isn't available in the earlier PV 2012, going back reverts the appearance, how can it not? You have to either render the image using PV 2016 and stop the raw processing by your own doing (leaving the subscription and new featuers) OR continue to pay to use the new features.
I'm not clear how this is an SO issue. It's an issue with newer proprietary processing that by your own doing (stopping subscription), you lose. IOW, if we forget SO's, how is this issue any different if we were to discuss just LR 2 and LR 5.5? Wouldn't the same issue exist?
-
I guess I assumed too much in my post. Let me unpack the relationship of chromaticity and luminance in RGB spaces that I was trying to get at.
Any (real or imaginary) monitor-based RGB color space (called by most just an RGB color space) can be envisioned as a cube, with orthogonal red, green, and blue axes joined at the origin (R=G=B=0). Those axes form three edges of the cube. The cube has six faces defined by the following equations, assuming full scale is unity.
R=0, R=1, G=0, G=1, B=0, B=1
Those faces define the gamut of any RGB color space in its own color space.
Now imagine tipping the cube so that it rests on the vertex R=G=B=0, and the vertex R=G=B=1 is straight up from there. So the black point is at the bottom, the white point is at the top, and the luminance diagonal or gray axis, defined as R=G=B=x, where x is any number in the range [0,1], is straight up and down.
You can see that dark colors, near the black point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the black point. Light colors, near the white point, are constrained to a small distance from the grey axis by the fact that the cube comes to a point at the white point.
The small gamuts near the black and white points map over roughly when the cube is transformed into a color space like CIEL*a*b*, yielding small chromaticity gamuts near the white and black points.
Better?
More to come when I get more time.
Jim
Thanks for the explanation Jim, but honestly, don't you think an apple provides a simpler explanation ... with the black at the bottom (it's in the shadows, after all) and the white is at the top (where the light is shining on it), and the fat bit in the middle which has all of these lovely reds and greens and yellows and oranges and purples ... which make you want to take a nice juicy bite :)?
But, anyway, as you say, anything that has three reasonably linear coordinates will have that sort of shape, including Lab and XYZ (but not Lch, say, because its h is an angle, not an linear distance, so now we have a cylinder and not a cube, right?).
Robert
Robert
-
But, anyway, as you say, anything that has three reasonably linear coordinates will have that sort of shape, including Lab and XYZ (but not Lch, say, because its h is an angle, not an linear distance, so now we have a cylinder and not a cube, right?).
Robert, I'm not getting my point across if you think Lab has that cubical shape. The visible part of Lab is approximately conical, with the point at the bottom and the wide base at L* = 100, and the axis straight up and down.
Also, the luminance axis in Lab is x,0,0, not x,x,x, like it is in RGB.
Jim
-
I don't see this being any different in the results if you use an SO or not. That's my confusion with your issue. If you use a newer processing (PV 2016) that isn't available in the earlier PV 2012, going back reverts the appearance, how can it not? You have to either render the image using PV 2016 and stop the raw processing by your own doing (leaving the subscription and new featuers) OR continue to pay to use the new features.
I'm not clear how this is an SO issue. It's an issue with newer proprietary processing that by your own doing (stopping subscription), you lose. IOW, if we forget SO's, how is this issue any different if we were to discuss just LR 2 and LR 5.5? Wouldn't the same issue exist?
It isn't different except for one thing ... and that is that you can own Lightroom (at present) whereas you can no longer own the current version of Photoshop. So if you have ANYTHING in Photoshop that is not backward compatible with CS6, you will clearly not be able to go back to CS6 without some potentially serious problems. If your workflow includes the use of raw smart objects, as mine does, then you might be well advised not to use anything beyond PV2012 if you want to be able, at a future date, to go back to CS6.
If you don't use a raw smart object then the PV2012 issue doesn't arise,obviously. So then you've made the decision earlier on not to maintain the ability to edit your base raw image from Photoshop. if you do use raw SO, as long as you keep moving on with CC, no problem. Try to step back ... that's when you may (probably will) hit a problem.
If you used raw smart objects in any sort of regular manner and were concerned about getting locked in to CC you would see the problem.
Robert
-
IIf you used raw smart objects in any sort of regular manner and were concerned about getting locked in to CC you would see the problem.
That is true for any proprietary Adobe processing in terms of version accessibility. SO's are not unique.
-
Robert, I'm not getting my point across if you think Lab has that cubical shape. The visible part of Lab is approximately conical, with the point at the bottom and the wide base at L* = 100, and the axis straight up and down.
Also, the luminance axis in Lab is x,0,0, not x,x,x, like it is in RGB.
Jim
You're right ... I stand corrected, sort of. The Lab coordinates are 3-dimensional, so there's nothing to prevent them representing a cube. The Lab gamut is another matter as that is constrained by the illuminant, and the standard observer, and it maps the visible spectrum within these constraints.
I haven't missed your point ... you made it clearly :).
Robert
-
R=0, R=1, G=0, G=1, B=0, B=1
Those faces define the gamut of any RGB color space in its own color space.
Hi, it defines the encoding space.
Iain
-
That is true for any proprietary Adobe processing in terms of version accessibility. SO's are not unique.
Andrew ... I'm not arguing that point. I agree!!
The reason I brought this up is that I, personally, don't want to get stuck with raw smart objects, or any other smart object or feature for that matter, that I can no longer process in CS6. My question was simply this: do you guys and gals agree that if I stick to PV2012 that I will be able to go back and edit the raw smart objects created in Lightroom xxx, ACR yyy, in Photoshop CC 20zz at a later stage, in Photoshop CS6.
It's not a theoretical, this is the same as that sort of discussion/question. It's 'how do I maintain raw smart object backwards compatibility with CS6?'.
It's clearly not a concern of yours since you don't use them, but in my workflow, which forms part of the discussion in this thread, I do clearly explain that it IS part of MY workflow.
At any rate, many thanks for your patience ... I think I've answered my own question as best as it can be answered at this point in time.
Robert
-
Hi, it defines the encoding space.
Iain
Very good, exaclty.
-
My question was simply this: do you guys and gals agree that if I stick to PV2012 that I will be able to go back and edit the raw smart objects created in Lightroom xxx, ACR yyy, in Photoshop CC 20zz at a later stage, in Photoshop CS6.
If you stick with CS6/ACR functionality I believe the answer is yes.
And it IS a concern for me, has been since Photoshop 1.09. Just not with SO's.
-
If you stick with CS6/ACR functionality I believe the answer is yes.
And it IS a concern for me, has been since Photoshop 1.09. Just not with SO's.
OK, cool. Thanks Rodney. I know I can be a bit trying on people's patience :).
Robert
-
Maybe I shouldn't be using so many words to get my point across about the histogram. Maybe an example would help.
These two images have the same histogram.
(http://www.kasson.com/ll/histo%20srgb%20rgb.PNG)
(http://www.kasson.com/ll/histo%20srgb%20grey.PNG)
Jim
-
If the editing could then be masked by the color map (more effect towards higher deltas, or edit selected range of deltas) it would be really fantastic.
We need overlay opacity so we can see what's under it with full control. We also need to swap colors so for example, if Red represents something and you're working on a red rose, you can change that overlay color.
-
We need overlay opacity so we can see what's under it with full control. We also need to swap colors so for example, if Red represents something and you're working on a red rose, you can change that overlay color.
I was thinking not of an overlay, but of a color-map as an additional panel below the histogram. The problem with having the color-map over the image is that it makes it difficult to see the effect of the adjustments on the image (locally and also the effect of the local change on the color balance in the image). But I suppose the overlay could be toggled on and off ... and certainly being able to adjust the opacity would be very useful.
It should be possible to do this as a 3rd-party panel in Photoshop, I think. It would have to be done by Adobe for Lightroom, I think. Are you talking theoretically, like 'it would be nice if', or are you thinking of an implementation for Photoshop or talking to Adobe about a possible new feature?
Robert
-
Maybe I shouldn't be using so many words to get my point across about the histogram. Maybe an example would help.
These two images have the same histogram.
Jim
Hi Jim ... you're still leaving me behind, I'm afraid. Are you referring to your previous post where you say: "Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images."? So that gray, for example, will give the same histogram peak as its RGB components separated out, as you show.
It would be useful to explain what a color histogram actually is (which I assume is one of the things you are attempting to do?). My understanding is that its essentially a graphical representation of the tonal range of the image. As such, its main use is to give us an idea about things like shadow and highlight clipping, whether the image is under-exposed or over-exposed ... that sort of thing. It isn't intended to show whether or not parts of the image are out of gamut (how could it? the image will never be OOG in its own color space), and so we shouldn't use it for that purpose (I can't imagine that anyone would).
So I'm not sure what your point is :).
Robert
-
It should be possible to do this as a 3rd-party panel in Photoshop, I think. It would have to be done by Adobe for Lightroom, I think.
Someday I'd like to see it in ACR and LR. I'm told it's possible, the question is, does Adobe feel it's worth the engineering time and money? Do many of their customers?
-
In a different vein,
In practice how does Lindbloom's Beta RGB compare to the Joseph Holmes authored EktaSpace 5 and the D-Cam profiles? http://www.josephholmes.com/profiles.html
-
Hi Jim ... you're still leaving me behind, I'm afraid. Are you referring to your previous post where you say: "Or does it? There's nothing to say that the points in the image that give you the top part of the red histogram channel are the same points that give you the top part of the blue histogram channel. We're just lucky that it happens to work out that way for most images."? So that gray, for example, will give the same histogram peak as its RGB components separated out, as you show.
Yes, indeed.
It would be useful to explain what a color histogram actually is (which I assume is one of the things you are attempting to do?). My understanding is that its essentially a graphical representation of the tonal range of the image. As such, its main use is to give us an idea about things like shadow and highlight clipping, whether the image is under-exposed or over-exposed ... that sort of thing. It isn't intended to show whether or not parts of the image are out of gamut (how could it? the image will never be OOG in its own color space), and so we shouldn't use it for that purpose (I can't imagine that anyone would).
So I'm not sure what your point is :).
Robert
Robert, maybe we're in "violent agreement" on this issue. Sounds like we agree that the histogram is a lousy tool to use to examine the gamut of an image, which was my main point.
Now, on to the details...
You said earlier: "Why is it that we are lucky? We can always adjust the saturation of individual colors, surely, so if we adjust the red but it's quite separated from the blue ... so what? I think I'm definitely missing something here."
Being lucky, in this case, meant that the information at, say, the top of each plane of the histogram came from the same group of pixels. It usually, but most certainly not always, does. If it does, when all the planes are moved to the right, it means a part of the image that has almost no chroma will appear with a luminance near paper white, in conventional wisdom, A Good Thing. If it doesn't, moving the top of the histogram planes to the right can result iin out-of gamut colors, especially is monstrously large color spaces.
On a related point, you say, "We can always adjust the saturation of individual colors..." With the histogram, we can't see how saturated any color is.
You also said earlier: "...and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less)"
First, in Ps, the horizontal axis of the histogram is in general non-linear. That axis is in the non-linearity of the working RGB color space. Unless you work in Ps in a color space with a gamma of one (or less!), the horizontal axis of the histogram will give more weight to darker colors than a linear scale would. This is appropriate almost all the time becasue of the nonlinearities inherent in the human visual system. Aside: As a corollary of this, the 18% reflectance point will occur at a different place in working color spaces with different gammas. This is important if you edit sometimes in, say, Adobe RGB with its 2.2 gamma, and PPRGB, with its gamma of 1.8. In Ps, the vertical axis of the histogram is linear (all the time? I'm not sure. Andrew?).
Second, as I think we now agree, the histogram doesn't represent saturation at all.
Are we good now?
Thanks,
Jim
-
Someday I'd like to see it in ACR and LR. I'm told it's possible, the question is, does Adobe feel it's worth the engineering time and money? Do many of their customers?
Personally I think that it's shocking that Photoshop doesn't already have it. PS is a high-end, expensive program and I find it amazing that it lacks so many basic features that have to be provided by 3rd-party plug-ins (or even work-arounds like making ACR a 'filter' ... because it has many editing features that are better than Photoshop's).
As for Lightroom ... well already many photographers aren't using Photoshop, so if Adobe keeps adding features they may end up shooting themselves in the foot. On the other hand Lightroom has some serious competition ...
It would be useful if LuLa conducted a survey of its members on this subject. I wouldn't think too many members would give a rating than better than 1 in 10 to the current gamut warning features in either program. After all, PS's Gamut Warning doesn't even work at the dark-end; and the Color Range out of gamut selection doesn't even tie in with the proofing out-of-gamut, so it can't be used to create an OOG mask for ink-jet printers!
Robert
-
On a related point, you say, "We can always adjust the saturation of individual colors..." With the histogram, we can't see how saturated any color is.
You also said earlier: "...and this is reflected in the histogram since this is a linear representation of the saturation of the image at every luminance point (more or less)"
Second, as I think we now agree, the histogram doesn't represent saturation at all.
Are we good now?
Hi Jim ... yes we're good. I just used VERY sloppy language! What I meant of course is that the histogram is a representation of the proportion of pixels that are at a particular luminance level in the image. So if the image is pure black, the histogram will show all pixels at one point to the far left; if the image is gray, there will a one line near the center (the position depends on the working-space gamma, as you point out); if the image is mostly dark, there will be a bump at the left end, mostly light will result in a bump at the right end etc.
Robert
-
Being lucky, in this case, meant that the information at, say, the top of each plane of the histogram came from the same group of pixels. It usually, but most certainly not always, does. If it does, when all the planes are moved to the right, it means a part of the image that has almost no chroma will appear with a luminance near paper white, in conventional wisdom, A Good Thing. If it doesn't, moving the top of the histogram planes to the right can result iin out-of gamut colors, especially is monstrously large color spaces.
Hmm. Jim, I'm not sure I quite get this. Let me see if I can put it in plain English. We have two separately illuminated objects in the image; the rest of the image is pure black. One of the objects is a red tomato with a green spot in the middle. The other object is a green apple. (our reds and greens happen to be pure R and pure G). Because of the shape of the fruit the illumination is not uniform. The light we use favors reds, so that the red tomato is brighter than the green apple and the green blob on the tomato is in the same brightness range as the green apple (but darker than the darkest spot on the red of the tomato). So our histogram should now show a nice curve for the green of the apple, with another nice curve to its right for the red of the apple. What we don't see is that part of the green curve is made up of the green from the green blob on the tomato.
If we clip the red bell curve by pushing up the image brightness, what we would expect to happen would be that the tomato would go white but the green spot in the tomato and the green apple would stay green (a brighter green). So the white tomato is 'OK' ... at least logically :). However, the green of the blob and the green of the apple may well get pushed out of gamut. If the gamut of the working space is smaller than the gamut of the destination then the apple and green blob would stay in gamut; if we are using ProPhoto it will almost definitely go out of gamut.
If we repeat this with a different illuminant, so that the red and green bell curves overlap, then both the apple and tomato, including its green blob, will all go white happily together. However, on their way to white, either the reds or the greens could well go out of gamut, right?
So, in plain language, is this what you are saying? If so, then it's a compelling case to take care when adjusting the image brightness! And also a compelling case not to use the histogram to try to figure out if parts of the image are within gamut or not.
Robert
-
Andrew or Jim,
Have a look at this image+histogram and tell me if the histogram is right or wrong:
(http://www.irelandupclose.com/customer/LL/funny-histogram.jpg)
The image is just a yellow gradient, going to white ... so the red and green histograms seem fine. The blue histogram should surely be flat in the left half of the image, shouldn't it?
The histogram looks much the same in Lightroom (although the yellow part is pushed further to the right ... presumably because of the sRGB gamma LR uses for the histogram?).
Robert
-
Everything you thought you wanted to know about Histograms
Another exhaustive 40 minute video examining:
What are histograms. In Photoshop, ACR, Lightroom.
Histograms: clipping color and tones, color spaces and color gamut.
Histogram and Photoshop’s Level’s command.
Histograms don’t tell us our images are good (examples).
Misconceptions about histograms. How they lie.
Histograms and Expose To The Right (ETTR).
Are histograms useful and if so, how?
Low rez (YouTube): http://www.youtube.com/watch?v=EjPsP4HhHhE
High rez: http://digitaldog.net/files/Histogram_Video.mov
-
The blue histogram should surely be flat in the left half of the image, shouldn't it?
There is no part of the histogram that represents the left half of the image. A histogram is simply a bar chart counting the total number of pixels at each value. There is a left half of the histogram, but this in no way corresponds to the left half of the image.
It may be helpful in this case to look at the gradients in the individual channels. There you'll see the red and green channels have a gradient that goes from about 150 to 255 and the blue channel has a gradient going from black to white. This corresponds to the histogram.
One strangeness is that the histograms are not flat in any channel when you make gradients with the gradient tool. Photoshop by default uses a gaussian distribution with the gradient tool and this is reflected in the inverted bell curve of the histogram. If you want flatter histograms you can set the gradient smoothness to 0% in the tool setup.
-
If you want flatter histograms you can set the gradient smoothness to 0% in the tool setup.
Where's that?
-
Where's that?
In the gradient editor box. (I'm not sure what the official name is). With the gradient tool selected, click on the little gradient selector in the tool bar. (screen shot attached).
-
In the gradient editor box. (I'm not sure what the official name is). With the gradient tool selected, click on the little gradient selector in the tool bar. (screen shot attached).
Got it, thanks, good tip.
-
Hmm. Jim, I'm not sure I quite get this. Let me see if I can put it in plain English. We have two separately illuminated objects in the image; the rest of the image is pure black. One of the objects is a red tomato with a green spot in the middle. The other object is a green apple. (our reds and greens happen to be pure R and pure G). Because of the shape of the fruit the illumination is not uniform. The light we use favors reds, so that the red tomato is brighter than the green apple and the green blob on the tomato is in the same brightness range as the green apple (but darker than the darkest spot on the red of the tomato). So our histogram should now show a nice curve for the green of the apple, with another nice curve to its right for the red of the apple. What we don't see is that part of the green curve is made up of the green from the green blob on the tomato.
If we clip the red bell curve by pushing up the image brightness, what we would expect to happen would be that the tomato would go white but the green spot in the tomato and the green apple would stay green (a brighter green). So the white tomato is 'OK' ... at least logically :). However, the green of the blob and the green of the apple may well get pushed out of gamut. If the gamut of the working space is smaller than the gamut of the destination then the apple and green blob would stay in gamut; if we are using ProPhoto it will almost definitely go out of gamut.
If we repeat this with a different illuminant, so that the red and green bell curves overlap, then both the apple and tomato, including its green blob, will all go white happily together. However, on their way to white, either the reds or the greens could well go out of gamut, right?
So, in plain language, is this what you are saying? If so, then it's a compelling case to take care when adjusting the image brightness! And also a compelling case not to use the histogram to try to figure out if parts of the image are within gamut or not.
Robert, what you say sounds about right, but without a concrete example image, I can't exactly figure out what you're saying. But consider the example images that I posted above, the one with 3 squares with sRGB values, 119,0,0; 0,119,0, and 0,0,119, and the other one with one square with sRGB values 119,119,119.
Moving the right-hand arrow on the Ps Levels tool (the one that changes the white point) to the left on the one-square image so that the histgram right peak gets well above 200 will result in the white rectangle when printed, approaching paper white.
Moving the right-hand arrow on the Ps Levels tool to the left the same amount on the three-square image will result in none of the colored rectangles, when printed, being within the gamut of any reflective mode printer known to man.
And the histograms of the two modified image will still be the same.
Coming at it another way, if the definition of saturation within an RGB color space is the percentage distance from the white point to the maximum available chroma at a given luminance and hue angle, the three squares in that image are all 100% saturated. The grey square is 0% saturated. Yet the histograms are the same.
By the way, the above definition of saturation is different than the one that's used when the reference gamut is that of the human visual system., although the change is but one word: the percentage distance from the white point to the maximum visible chroma at a given luminance and hue angle.
I think I'm going to bow out of this discussion now. We appear to be on the same page. You're in good hands with Andrew (although I have to admit that I've never watched any of his videos -- I can't stand to watch instructional videos).
Jim
-
Everything you thought you wanted to know about Histograms
Another exhaustive 40 minute video examining:
What are histograms. In Photoshop, ACR, Lightroom.
Histograms: clipping color and tones, color spaces and color gamut.
Histogram and Photoshop’s Level’s command.
Histograms don’t tell us our images are good (examples).
Misconceptions about histograms. How they lie.
Histograms and Expose To The Right (ETTR).
Are histograms useful and if so, how?
Low rez (YouTube): http://www.youtube.com/watch?v=EjPsP4HhHhE
High rez: http://digitaldog.net/files/Histogram_Video.mov
Thank you for your video Andrew ... very illuminating, as usual! It certainly shows that I did not understand the color histograms!!
I have to say that the color histograms are highly non-intuitive and I really wonder how many photographers understand them! To have a red to white gradient showing a blue and green histogram at the left with a count of zero ... is about as crazy as it gets IMO. Although showing no red as cyan gets pretty damn close! I don't see the value of that sort of histogram at all because it's much more likely to confuse than to inform. And to have a luminosity histogram (which at least makes sense) as the main histogram, and a crazy RGB histogram on the levels adjustment ... well, what can I say?
Fortunately for me I've only ever used the luminosity histogram ... and now that you've explained the others to me I firmly intend to stick to it!
Robert
-
There is no part of the histogram that represents the left half of the image.
My sloppy language: I meant the left half of the histogram in the image.
Robert
-
I think most photographers use the RGB histogram simply to check for clipping and not for much else. It's possible to have a luminance histogram that sits comfortably in the middle of the chart while in reality you are clipping a single channel. For example a image filed with sRGB(255, 0, 0) will give you a luminance histogram that shows a bar at 76. If you pushed up your exposure based on this you would horribly clip your red channel. In that sense it's somewhat useful for scenes filled with saturated colors although it would be more so if cameras could give you histograms that reflected the raw image.
Video editing software traditionally has a few tools that are arguable more useful like waveforms and vectorscopes that I think would be quite handy in photoshop especially if you are trying to edit colors to a particular target. I've seen some plugins for these, but have never tried them.
-
I think most photographers use the RGB histogram simply to check for clipping and not for much else. It's possible to have a luminance histogram that sits comfortably in the middle of the chart while in reality you are clipping a single channel. For example a image filed with sRGB(255, 0, 0) will give you a luminance histogram that shows a bar at 76. If you pushed up your exposure based on this you would horribly clip your red channel. In that sense it's somewhat useful for scenes filled with saturated colors although it would be more so if cameras could give you histograms that reflected the raw image.
Video editing software traditionally has a few tools that are arguable more useful like waveforms and vectorscopes that I think would be quite handy in photoshop especially if you are trying to edit colors to a particular target. I've seen some plugins for these, but have never tried them.
Yes, I suppose that's just the limitation of a histogram, in that it requires interpretation and doesn't always give an intuitively correct picture of what's in the image. I can see that a green 100 to gray 100 gradient, for example, has a problem: after all green will be at 100 across the whole image, so a full-size spike at 100 for green makes sense. At that slice of the image, R=B=0, so all of the red and blue pixels are at zero, so it makes logical sense to show a full size spike at 0 for both red and blue (after all, how else do we represent black on a histogram?). At slice R=B=1, green is still 100, so no difference there, but now 1% of the pixels are R=B=1 and 99% of the pixels are R=B=0, so again, a full size spike for both red and blue at that position.
The confusing thing is that the histogram is representing both 0 and 1 in the same way. It would have helped to have some visual representation of that, at least on the channels that are shown separately, for example with pixels with a value of 0 being black and with a value of 1 having the channel color. So that a Green 100 to Gray 100 gradient would look like this:
(http://www.irelandupclose.com/customer/LL/hist-mod.jpg)
But, as you say, using the luminance histogram on its own won't show potential channel clipping, so we do need the separate channel histograms. It would have been very useful to be able to select a Lab histogram.
Gradient histograms are particularly confusing though ... real image histograms are more understandable. But there is quite a lot to be learnt about histograms playing around with gradients, and also combinations of red, green and blue. At least it helps to see where the one's interpretation might be wrong.
Robert
-
That you are sqeezing the whole gamut of ProPhoto into the printer space with perceptual rendering is false.
Well, of course it depends on how the gamut mapping is setup.
Current CMMs are dumb in that they do not look at the colors that are actually in the image but merely squeeze the image by some arbitrary value, which usually leaves OOG colors after the perceptual rendering.
I'm not sure which CMM"s you are thinking about, but your statement doesn't apply to ArgyllCMS, which uses actual gamut mapping as opposed to some sort of arbitrary compression. If you create perceptual or saturation intent tables you have to specify a source gamut. If you use the default it will be that of the source color space (which is a bad idea if that is a wide gamut space like ProPhoto), or you can override that and use the gamut of the images you intent to gamut map.
-
And now that we're not arguing that point, here's a link to an algorithm for gamut mapping that my admittedly biased and interested self believes would be an improvement over the point-process gamut mapping algorithms used today.
Some work has been done on spatial gamut mapping, as a survey of the literature will show, and even I presented something on it at the Fogra Colour Management Symposium in 2010. But most people are well below that rung on the gamut mapping hierarchy of refinement:
1. No gamut mapping - clip
2. Arbitrary compression (possibly what CMM's that don't allow a specific source gamut have to do)
3. Specific colorspace to colorspace mapping
4. Specific image to colorspace mapping.
5. Spatial gamut mapping.
Most people are probably at 2. Those using ArgyllCMS tiffgamut + collink + cctiff are at 4. It is worth exploring the rungs above 2 before leaping to the conclusion that 5 is worth the effort at the moment.
-
This profile (DCam 5) makes ProPhotoRGB looks small and it is the only profile I have seen that ecompasses all visible colors (not even LAB)
By definition, L*a*b* encompass all visible colors. Perhaps you actually mean that L*a*b* with a* and b* restricted to the range -128 to +128 can't represent all visible colors ?
-
I was going to return to the subject of using ProPhoto as the working space in Photoshop and the effect that this can have on a Perceptual mapping to a much smaller destination space, but I see that Graeme Gill has taken up the baton, so I'll happily leave it in his most capable hands!
So, instead I wanted to talk a little about the workflow - raw to destination - and the dangers of introducing clipping and out-of-gamut colors.
If we are working entirely within Lightroom, then there isn't much of a problem because before output we will, presumably, have the good sense to soft-proof and adjust the exposure so that it doesn't clip colors in the destination space (going back to Jim's point about the RGB gamuts going to a point at white and black). ProPhoto, having a wider gamut than the destination will be able to accommodate colors which will be out of gamut in the destination space, simply because of the exposure.
However, if our workflow includes Photoshop then I think we need to be more careful. We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine. If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first). If we drop the image brightness before doing the conversion then the colors will remain in gamut. However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment. Not quite so bad in 16-bit, but very bad in 8-bit.
The same can happen at the dark end.
So, this would indicate to me that if we intend our destination to be in a smaller space than ProPhoto (which we almost inevitably do), then we should open the image from Lightroom to Photoshop in a working space that is not too much bigger than the destination (which currently means opening into ProPhoto and then converting to the smaller working space unless the smaller space is sRGB or Adobe RGB), and we should make sure that the image exposure is adjusted to that space before opening it into Photoshop.
This is also a good reason to use a raw Smart Object in Photoshop. Open into Photoshop and convert to Beta RGB (no need to be careful in Lightroom). Go into the Smart Object and soft-proof to the print destination and adjust the exposure, contrast etc (and saturation of individual colors if necessary) to bring the image (more or less) into gamut for the destination. Then convert to the destination and print. (I'm leaving out editing steps in Photoshop ... and of course these could result in destination OOG colors: these can be fixed by going back into the Smart Object, or from within Photoshop itself, or by letting the CMM do its job).
Robert
-
By definition, L*a*b* encompass all visible colors. Perhaps you actually mean that L*a*b* with a* and b* restricted to the range -128 to +128 can't represent all visible colors ?
Yes, you are absolutely right. It is not L*a*b per se but the way it is implemented with integer numbers restricted to the -128 to 128 (or 127) range
-
We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine. If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first). If we drop the image brightness before doing the conversion then the colors will remain in gamut. However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment. Not quite so bad in 16-bit, but very bad in 8-bit.
No, do not use brightness to solve OOG colors issues.
ETTR has a meaning only for a scene referred image, once you are ready to go to photoshop it should not play any role.
Do not rely on the histogram alone. The attached files (extending the point made by Jim Kasson) show the case of two different images whose RGB histogram span from 0 to 255 in all channels. The first is three gradients that go from neutral gray (127,127,127) to the extreme of every channel (255,0,0);(0,255,0) and (0,0,255).
The second image is just a gradient from black to white and again the histogram span from 0 to 255 in all channels. The missing piece of information in histograms is that it does not show if those values occur simultaneously as in the black to white gradient or at different locations.
The third image shows a gamut warning converting the first image from ProphotoRGB to sRGB (it is in softproof mode, so it shill shows the histogram in Prophoto RGB). Do you think that adjusting image brightness will be of any value? Not at all, using exposure or brightness to solve a blown out channels is the wrong approach. It only works if the issue is luminosity and not saturation (look at the luminosity histogram, there is nothing to adjust with brightness)
The last image shows how the histogram looks if we converted to sRGB without doing any other adjustments. Huge spikes in each channels (all channels blown out) and yet the luminosity well below the extremes.
If your issues are with OOG colors, then you have to work with saturation, vibrance, mask, etc. but not with the brightness or exposure
The same can happen at the dark end.
So, this would indicate to me that if we intend our destination to be in a smaller space than ProPhoto (which we almost inevitably do), then we should open the image from Lightroom to Photoshop in a working space that is not too much bigger than the destination (which currently means opening into ProPhoto and then converting to the smaller working space unless the smaller space is sRGB or Adobe RGB), and we should make sure that the image exposure is adjusted to that space before opening it into Photoshop.
The fact that a color space is smaller in volume than another does not mean that all the colors in the smaller space are contained in the bigger space. Color spaces do not behave like a matryoshka where the bigger contains the smaller. This is especially true with output (printer/paper) profiles. Do you know that AdobeRGB has colors outside of ProPhoto RGB? If you perform an absolute colorimetric conversion between them this actually happens, if you perform a relative colorimetric conversion then AdobeRGB is fully contained in Prophoto. What plays a role here is the white point (D50 vs D65)
This is also a good reason to use a raw Smart Object in Photoshop. Open into Photoshop and convert to Beta RGB (no need to be careful in Lightroom). Go into the Smart Object and soft-proof to the print destination and adjust the exposure, contrast etc (and saturation of individual colors if necessary) to bring the image (more or less) into gamut for the destination. Then convert to the destination and print. (I'm leaving out editing steps in Photoshop ... and of course these could result in destination OOG colors: these can be fixed by going back into the Smart Object, or from within Photoshop itself, or by letting the CMM do its job).
Robert
Using a smart object is a good recommendation, convert to Beta RGB might work for some images, not for others.
-
No, do not use brightness to solve OOG colors issues.
ETTR has a meaning only for a scene referred image, once you are ready to go to photoshop it should not play any role.
Do not rely on the histogram alone.
If your issues are with OOG colors, then you have to work with saturation, vibrance, mask, etc. but not with the brightness or exposure
Hi Francisco,
I didn't say that adjusting brightness etc., would fix all out of gamut problems ... only those caused at the light and dark ends due to the fact that ProPhoto extends further into these areas than most other color spaces. Of course the clipping could also be fixed by desaturating or changing the hue.
You can see this here:
(http://www.irelandupclose.com/customer/LL/hiloclip.jpg)
So clipping due to too much tightness at the highlights is likely to cause OOG in the bright yellows, whereas at the dark end if will be dark blues and dark green. Of course the clipping may not be too bad ... and the CMM might do a perfectly acceptable job ... but then again it might not.
Mentioning ETTR was a bit of a red herring since exactly the same problem can be caused just with the Lightroom tonal sliders. And we can quite safely use ETTR, but we may need to back off the white and black levels a bit if the destination space is narrower (or missing) at either end.
Needless to say, ProPhoto is well capable of holding colors that are outside the gamut of most destination spaces, and adjusting the luminosity of the image will have little or no effect with these colors.
[/quote]
Do you know that AdobeRGB has colors outside of ProPhoto RGB? If you perform an absolute colorimetric conversion between them this actually happens, if you perform a relative colorimetric conversion then AdobeRGB is fully contained in Prophoto. What plays a role here is the white point (D50 vs D65)
No, I must say that it is news to me that AdobeRGB has colors outside of ProPhoto. Are you sure you aren't mistaken?
All conversions from one working space to another are relative colorimetric, so I don't see how an absolute colorimetric conversion could change the gamut (it does change the white point, but that won't affect the gamut ... but as this will cause a shift in the colors I suppose it's possible that some of these might end up outside the ProPhoto space.
Using a smart object is a good recommendation, convert to Beta RGB might work for some images, not for others.
Yes, well of course it's all image-dependent, but in general Beta RGB is large enough to contain most destination spaces (I know that some printer profiles stretch it a bit, but I'm not sure that the extra little bit of printer gamut would be noticeable, if we ever used it). If things change and printers or other output devices end up with larger gamuts then of course we would need a larger working space.
Robert
-
No, I must say that it is news to me that AdobeRGB has colors outside of ProPhoto. Are you sure you aren't mistaken?
All conversions from one working space to another are relative colorimetric, so I don't see how an absolute colorimetric conversion could change the gamut (it does change the white point, but that won't affect the gamut ... but as this will cause a shift in the colors I suppose it's possible that some of these might end up outside the ProPhoto space.
Hi Robert,
This is something of little or no practical value. Usually you have to perform chromatic adaptation to go from a color space to another with a different white point. However, if you don't and plot both AdobeRGB and ProPhotoRGB with their original white points, there is a small area in the blues of AdobeRGB that is outside of the ProphotoRGB space. It is more a curiosity than something of real value (it would cause shifts in color an non neutral tones)
-
However, if you don't and plot both AdobeRGB and ProPhotoRGB with their original white points, there is a small area in the blues of AdobeRGB that is outside of the ProphotoRGB space.
The same applies to sRGB - some of it is out of gamut in absolute terms compared to ProPhoto. This is only of significance for some methods of soft proofing, since it's more normal to calibrate a display to suit the white point of what's being proofed.
-
The same applies to sRGB - some of it is out of gamut in absolute terms compared to ProPhoto. This is only of significance for some methods of soft proofing, since it's more normal to calibrate a display to suit the white point of what's being proofed.
So this could cause a problem with Photoshop soft-proofing where the wtpt tag value is changed? Is there some way of finding out if there is clipping in the AtoB direction?
Robert
-
Hi
Performing the chromatic adaptation before converting spaces is a criteria shared by many and it is actually a criteria implemented in the color management engine. For instance, if you use the Adobe ACE color engine in Photoshop (recommended), you will not see any issues converting from sRGB or AdobeRGB to ProphotoRGB using Absolute colorimetric rendering intent, so it must be performing chromatic adaptation.
However if you choose Microsoft ICM as the engine, then it is apparent that the chromatic adaptation is not performed as shown in the attached files.
The image is a test created by Bruce Lindbloom with all possible RGB values and no embedded profile. So I loaded it into PS, assigned sRGB and tried softproofing to ProphotoRGB with gamut warning on.
The first image shows an OOG area when using Absolute colorimetric RI, while the other image does not show any issue using relatice colorimetric RI (Yes, this is going from sRGB to ProPhotoRGB)
-
Performing the chromatic adaptation before converting spaces is a criteria shared by many and it is actually a criteria implemented in the color management engine. For instance, if you use the Adobe ACE color engine in Photoshop (recommended), you will not see any issues converting from sRGB or AdobeRGB to ProphotoRGB using Absolute colorimetric rendering intent, so it must be performing chromatic adaptation.
It will depend on the intent chosen, as well as the details of the display ICC profiles. For instance, ICCV4 changed the display profile spec. to disable the normal absolute colorimetric rendering mode. Some V2 ICC profiles are also formulated in a similar fashion. A CMM now has to go out of it's way and use the 'chad' tag to restore absolute rendering when using V4 profiles.
-
The first image shows an OOG area when using Absolute colorimetric RI, while the other image does not show any issue using relatice colorimetric RI.
Thanks Frank,
That answers my question regarding the potential AtoB2 clipping. Convert to the destination and then soft-proof back to the working-space using the Absolute RI. (Bearing in mind the possible CA and icc v2/v4 issues etc :))
Thanks!
Robert
-
I've been doing some Perceptual mapping tests, using different profiles and techniques, which may be of interest.
The three methods I've used are:
- Normal conversion from the ProPhoto image to the print destination
- 'Smart Conversion' with ArgyllCMS: this creates an image gamut, a link profile from the image to the destination and it then converts the image. This is a new technique for me and I am not using it optimally.
- The 2-step conversion I've proposed (Relative to BetaRGB followed by Perceptual to destination)
Here are the results:
1. Normal conversion from the ProPhoto image to the print destination
(http://www.irelandupclose.com/customer/LL/T40359-PS.jpg)
The stripes are caused by a mask. The darker stripes are the original image and the lighter ones are after the Perceptual conversion.
2. 'Smart Conversion' using ArgylCMS (the image is shown as for 1. with the same mask)
(http://www.irelandupclose.com/customer/LL/T40359-A.jpg)
3. 2-Step conversion (again, the image is shown as for 1. with the same mask)
(http://www.irelandupclose.com/customer/LL/T40359-2S.jpg)
The profile used was a Permajet Oyster profile made using an i1Pro2.
As you can see, 2 and 3 give good results whereas there is substantial lightening with 1. What is not very apparent with the small sRGB image is that with 1 there is also a loss of contrast.
The 1-Step Photoshop conversion works quite well with some profiles, but not with others. So far, the 2-step approach has been very good. I don't have enough experience with the Argyll 'Smart Conversion' to be sure, but in the 3 tests I've done so far it looks very good, with some problems in a fourth test with an Epson Enhanced Matte profile. The Enhanced Matte test was with a poor profile, and the paper has a small gamut and bad DMax - it could be that some tuning of the Argyll parameters is needed to get an optimal conversion (the problem was in a dark shadow area).
I do have a number of preliminary conclusions, but for now my main one is that it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.
Robert
-
I do have a number of preliminary conclusions, but for now my main one is that it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.
Interesting test, thanks. Couple thoughts. First, if you soft proof using just the Photoshop method AND you have the original prior to conversion on-screen at the same time, presumably you would see that the image gets a bit lighter. The question would be, could you build a very quick and simple adjustment layer to 'correct' for this based on viewing the 'before' image? This would be simpler and faster in Lightroom using a Proof Copy. And you'd have your output specific tweak in that VC.
2nd, what do you see between the two tests you did on a print?
-
Interesting test, thanks. Couple thoughts. First, if you soft proof using just the Photoshop method AND you have the original prior to conversion on-screen at the same time, presumably you would see that the image gets a bit lighter. The question would be, could you build a very quick and simple adjustment layer to 'correct' for this based on viewing the 'before' image? This would be simpler and faster in Lightroom using a Proof Copy. And you'd have your output specific tweak in that VC.
2nd, what do you see between the two tests you did on a print?
Yes, sure, of course it would be possible to adjust the soft-proofed image before the conversion to 'align' it towards the original (perhaps with a curve to darken and add more contrast, and a clarity-type adjustment for local contrast).
I've only checked on my monitor ... it really would be necessary to print for any final conclusions (time-consuming unfortunately!).
Robert
-
it is worth trying different techniques if the straightforward Photoshop Perceptual conversion changes the image unacceptably.
Robert
Couldn't agree more with that statement! thanks for sharing the test.
I also think that if you are converting to an output (print) color space, the conclusions have to be made looking at the prints, not at the monitor. Could it be that the increased brightness is due to compensation for the paper white?
Regards
-
Couldn't agree more with that statement! thanks for sharing the test.
Could it be that the increased brightness is due to compensation for the paper white?
No - the images are converted, not soft-proofed. BPC was on in all cases.
Robert
-
No - the images are converted, not soft-proofed. BPC was on in all cases.
I believe Francisco still raises a valid point even with converted images: converted for the paper in mind.
-
I believe Francisco still raises a valid point even with converted images: converted for the paper in mind.
Yes, definitely as far as needing to print for the final evaluation.
As for a possible explanation for the extra lightness in the 1-step ProPhoto to destination conversion ... on reflection, it is possible that the i1Profiler profile attempts to compensate for the paper color by brightening the image in a perceptual conversion (it doesn't do it in a relative conversion). I've checked an i1Profiler profile for an Ilford Gloss paper and it doesn't do it for this paper ... but this needs further investigation. As you say, Francisco could be onto something.
I'm away for 10 days, but I'll see if I can get to the bottom of what's happening on my return (or perhaps someone else could check it out).
Robert
-
However, if our workflow includes Photoshop then I think we need to be more careful. We could have a nicely ETTR image in Lightroom, beautifully exposed so that the histogram sits snugly between 0 and 255 (or nearly) and everything is fine. If we then bring it into Photoshop and convert it to, say, Beta RGB, we will most likely be clipping colors at the highlight end (easy to see by doing a soft-proof first). If we drop the image brightness before doing the conversion then the colors will remain in gamut. However doing that damages the image ... and to get the colors back in gamut needs a severe brightness adjustment. Not quite so bad in 16-bit, but very bad in 8-bit.
Hi Robert, just to add to the thread Photoshop is not a 16-bit tool but it's 15-bit. So forget about 65536 encoding levels, it's half of that.
Genuine 16-bit TIFF file:
(http://www.guillermoluijk.com/curious/hist16bits/linearhis.gif)
Just open and save in Photoshop:
(http://www.guillermoluijk.com/curious/hist16bits/linearhisps.gif)
TADAAAA!!!
Even with that I never experienced posterization problems when using ProPhoto RGB on 16-bit files in Photoshop. It's always the 8-bit conversión to build the output JPEG that could display posterization (typ. areas with uniform colours and good SNR such as skies).
Regards