Luminous Landscape Forum
Raw & Post Processing, Printing => Digital Image Processing => Topic started by: ChuckZ on October 22, 2009, 06:21:21 pm
-
My typical workflow is to first download my memory card into Lightroom2, set white balance, exposure, etc then export to PhotoshopCS4 for further work. In Lightroom, the histogram will show no clipping of the highlights, but once it is in Photoshop, the color histogram often shows clipping, typically the red channel. Why is that and is there some way to change settings so that the histogram is the same in each program? Thank you very much for any thoughts on this situation.
Chuck
-
LR displays a ProPhoto RGB based histogram (i.e. a very wide colour gamut), no matter the output colour profile chosen. When exported to Photoshop, the conversion takes place and this may clip some information to 0 or saturation that will obly be visible once in Photoshop.
All this seems quite stupid, specially since ACR has always disaplayed histograms according to the chosen output colour profile, preventing disgusting surprises.
BR
-
LR displays a ProPhoto RGB based histogram (i.e. a very wide colour gamut), no matter the output colour profile chosen. When exported to Photoshop, the conversion takes place and this may clip some information to 0 or saturation that will obly be visible once in Photoshop.
All this seems quite stupid, specially since ACR has always disaplayed histograms according to the chosen output colour profile, preventing disgusting surprises.
BR
Thanks. Surely enough when I change the Export Color Space to ProPhoto, the histogram looks about the same in both programs. Most of my images go on the web, so the only solution I can think of is to make my adjustments in Lightroom so that there is enough space between the highlights and the end of the histogram chart to take into account the change in color space. Are there any other methods to compensate for the color space change?
-
forgot to say that the color space I am exporting to in Photoshop is sRGB
-
forgot to say that the color space I am exporting to in Photoshop is sRGB
That's the first thing I thought of when I read this problem and this is obviously the issue. sRGB is a MUCH narrower colour space than ProPhoto used in LR, so OBVIOUSLY if you export an image which just fits a ProPhoto space in LR to Photoshop with sRGB space there MUST BE clipping. Change your Photoshop working space to ProPhoto and the problem will evaporate.
-
LR doesn't display the histogram of the output color space???
-
LR displays the histogram of its native working space, which is akin to ProPhoto RGB. (See Martin Evening's Lightroom 2 book, page 255).
-
LR doesn't display the histogram of the output color space???
LR doesn't know the export color space until you actually export or do the "edit in photoshop" or "edit in other program" options, and the defaults for those can be different. I hope the soft proofing everybody is talking about wilso cover exports or edits, and not just printing.
-
LR displays the histogram of its native working space, which is akin to ProPhoto RGB. (See Martin Evening's Lightroom 2 book, page 255).
Thanks for the hint. I won't even have look at LR itself as long as they are not able to incorporate full-grown color management. I wasn't aware that the implementation of the "export" profiles is that rudimentary... In Camera RAW (Photoshop) the historgram is reflecting the 4 output profiles. And in Capture One, of course, the histogram reflects the output profile (any kind) as well.
-
No - in Camera Raw the histogram adjusts to the chosen working space. That is not the same thing as "output profiles", which would normally refer to monitor profiles or a printer profiles. Nonetheless I agree it is helpful to work with a histogram adjusted to the boundaries of the chosen colour working space. As I always work in ProPhoto straight through to print this isn't an issue which has exercised me. I re-adjust duplicate files converted to JPEG for email or web as needed.
-
LR displays the histogram of its native working space, which is akin to ProPhoto RGB. (See Martin Evening's Lightroom 2 book, page 255).
LRs Histogram represents “Melissa RGB” which is ProPhoto primaries with a 2.2 TRC gamma. That’s not the underlying color processing space (that be ProPhoto primaries with a linear TRC gamma). So you’re basically looking at a histogram that’s not based on anything you’ll ever see or use outside of LR. Its too bad LR doesn’t behave like ACR where the Histogram is based on the actual output encoding color space you pick in the workflow options. Problem is, users export to all kinds of output spaces in LR so the “rational” here is, we’ll just show you a histogram that’s not based on anything real <g>. My suggestion would be to allow a user to option click on the histogram and inform it what space you’re working with albeit, you might export to some other space. I’d personally far prefer the histogram (and the RGB percentages which are now also Melissa RGB) to be in ProPhoto RGB with the 1.8 TRC gamma I’ll almost always export to. And if I export images for email in sRGB, no big deal.
We will all have to wait and see what soft proofing in 3.0 looks like and if it updates the Histogram based on what you select (and if you’ll be able to select an RGB working space). In the meantime, there’s just a disconnect between the LR histogram and RGB percentage values and ACR or anything you’ll actually see outside of LR.
-
LR displays the histogram of its native working space, which is akin to ProPhoto RGB. (See Martin Evening's Lightroom 2 book, page 255).
Or if you don't have Martin's book, you can look at this explanation of the Melissa (http://www.ppmag.com/reviews/200701_rodneycm.pdf) color space that Lightroom uses. It has the chromaticities of ProphotoRGB but the tone curve of sRGB. I happen to agree with Guilermo that the use of the Melissa color space is misguided. If sRGB is your final destination, serious color clipping can occur and you might not be aware of it. With ACR, clipping in sRGB will show on he histogram and you can then use a wider color space.
-
Or if you don't have Martin's book, you can look at this explanation of the Melissa (http://www.ppmag.com/reviews/200701_rodneycm.pdf) color space that Lightroom uses. It has the chromaticities of ProphotoRGB but the tone curve of sRGB. I happen to agree with Guilermo that the use of the Melissa color space is misguided. If sRGB is your final destination, serious color clipping can occur and you might not be aware of it. With ACR, clipping in sRGB will show on he histogram and you can then use a wider color space.
Well, I don't agree with either you or Guillermo about this, but Andrew has it right - it would be good to see the effect on the histogram of alternative export spaces in LR. The reason why I don't agree with you, and I THINK what underlay the design philosophy of LR, is that one should work in a wide colour space, and 16-bit depth, in order to preserve the maximum amount of image data so that the image could be subsequently repurposed with great flexibility for whatever use thereafter. You can shake down a rich image very successfully - much harder the other way around.
-
The reason why I don't agree with you, and I THINK what underlay the design philosophy of LR, is that one should work in a wide colour space, and 16-bit depth, in order to preserve the maximum amount of image data so that the image could be subsequently repurposed with great flexibility for whatever use thereafter. You can shake down a rich image very successfully - much harder the other way around.
But this is compatible with the philosophy of always displaying the real histogram. So I don't agree with you in that you don't agree with us
-
Well, I don't agree with either you or Guillermo about this, but Andrew has it right - it would be good to see the effect on the histogram of alternative export spaces in LR. The reason why I don't agree with you, and I THINK what underlay the design philosophy of LR, is that one should work in a wide colour space, and 16-bit depth, in order to preserve the maximum amount of image data so that the image could be subsequently repurposed with great flexibility for whatever use thereafter. You can shake down a rich image very successfully - much harder the other way around.
As an additional option, it might be interesting if Adobe treated us as advanced users by showing the linear encoded Histogram (which would look odd to many newer users to accustomed to non gamma corrected histos).
-
Well, I don't agree with either you or Guillermo about this, but Andrew has it right - it would be good to see the effect on the histogram of alternative export spaces in LR. The reason why I don't agree with you, and I THINK what underlay the design philosophy of LR, is that one should work in a wide colour space, and 16-bit depth, in order to preserve the maximum amount of image data so that the image could be subsequently repurposed with great flexibility for whatever use thereafter. You can shake down a rich image very successfully - much harder the other way around.
Lightroom Podcast 8 (http://blogs.adobe.com/jnack/2006/07/lightroom_podcast_8.html) includes a discussion between Mark Hamburg (the chief architect of Lightroom) and Thomas Knoll (the chief architect of Photoshop and ACR) about how the histograms and color info readouts should be handled. Actually, Thomas recommended using the approach that he used in ACR where the user can select the color space, but Mark chose to use the current Lightroom approach for simplicity. So, Guillermo and I are in good company with our opinions.
In another post, Mr. Knoll pointed out that working in a ProPhotoRGB like space can lead to problems with colors that can not be printed nor shown on the monitor and requires a bit of knowledge about color management, rendering intents, etc. With ACR one can use your approach merely by always using 16 bit ProPhotoRGB. However, if you know that the final product will be 8 bit sRGB, it makes sense to render into this space and adjust the colors so that they fit or allow them to clip. The problem with Melissa is that it is neither fish nor fowl.
-
No - in Camera Raw the histogram adjusts to the chosen working space. That is not the same thing as "output profiles", which would normally refer to monitor profiles or a printer profiles. Nonetheless I agree it is helpful to work with a histogram adjusted to the boundaries of the chosen colour working space. As I always work in ProPhoto straight through to print this isn't an issue which has exercised me. I re-adjust duplicate files converted to JPEG for email or web as needed.
Adjusting ProPhoto files for sRGB can be a bit of a problem if there are a lot of out of gamut colors. This can easily be done by experts such as yourself, but may pose a problem for those for whom the Lightroom dumbed down method was chosen. It would be nice if Lightroom used some type of intelligent perceptual rendering intent for converting to sRGB, perhaps akin to PhotoGamutRGB (http://photogamut.org/E_Index.html). For those new to color management, I should point out that there is no perceptual rendering with matrix based spaces such as ProPhotoRGB and sRGB even though Photoshop appears to allow it.
-
Adjusting ProPhoto files for sRGB can be a bit of a problem if there are a lot of out of gamut colors. This can easily be done by experts such as yourself, but may pose a problem for those for whom the Lightroom dumbed down method was chosen. It would be nice if Lightroom used some type of intelligent perceptual rendering intent for converting to sRGB, perhaps akin to PhotoGamutRGB (http://photogamut.org/E_Index.html). For those new to color management, I should point out that there is no perceptual rendering with matrix based spaces such as ProPhotoRGB and sRGB even though Photoshop appears to allow it.
Its no more or less a problem than moving from any color space. Yes, you clip colors. That’s the net result of using a tiny little sRGB gamut space. Or moving from ProPhoto to an output profile. Something gets lost in the translation. There’s nothing intelligent nor non intelligent auto conversion that will help here (that’s why we soft proof before we output to our printers). Now having ICC V4 support in all RGB working space would be useful as at least we might try differing perceptual intents going from say ProPhoto RGB to sRGB. But anyone who’s toggled from a RelCol to Perceptual soft proof to the same output device but using differing profile packages (where the perceptual mapping is different and based on the profile makers idea of better) still doesn’t guarantee ideal results. Ultimately you have to edit the source while viewing a soft proof.
Considering that the primary reason anyone would move from ProPhoto to sRGB is to post images on the web, its questionable how much work in this rendering is worthwhile. Output to a 20x30 ink jet you’ll sell or hang on your wall, sure. Output to a 1200 pixel web gallery, where many viewing it don’t even have calibrated displays? Not sure this isn’t anything but a solution in search of a problem. Convert using the current tools and move on.
-
It would be nice if Lightroom used some type of intelligent perceptual rendering intent for converting to sRGB, perhaps akin to PhotoGamutRGB (http://photogamut.org/E_Index.html). For those new to color management, I should point out that there is no perceptual rendering with matrix based spaces such as ProPhotoRGB and sRGB even though Photoshop appears to allow it.
PhotogamutRGB is extremely helpful. Though a bit dated regarding newer printers with better differentiation in dark tonal values.
Too, there is a tablebased sRGB profile: http://color.org/srgbprofiles.xalter (http://color.org/srgbprofiles.xalter)
The so called "gamut warning" profile also helps a lot as long as you can set it as working space in the RAW converter: http://color.org/prmg_gamutwarning.xalter (http://color.org/prmg_gamutwarning.xalter)
The predecessor of the latter profile - based on Gamma 2.2 and with a 5000K whitepoint - can be found here: http://www.colormanagement.de/?page_id=27 (http://www.colormanagement.de/?page_id=27)
-
There’s nothing intelligent nor non intelligent auto conversion that will help here (that’s why we soft proof before we output to our printers). Now having ICC V4 support in all RGB working space would be useful as at least we might try differing perceptual intents going from say ProPhoto RGB to sRGB. But anyone who’s toggled from a RelCol to Perceptual soft proof to the same output device but using differing profile packages (where the perceptual mapping is different and based on the profile makers idea of better) still doesn’t guarantee ideal results. Ultimately you have to edit the source while viewing a soft proof.
By intelligent perceptual rendering, I meant a rendering which takes the gamut of the colors that are actually in the image into account before arbitrarily desaturating colors when there are no out of gamut colors in the smaller space, as explained by Mike Chaney (http://www.steves-digicams.com/knowledge-center/understanding-rendering-intents.html) in the referenced review. This type of rendering must by done by the CMM, which needs to look at the image and see if there are out of gamut colors in the original image. Does ICC Ver4 do this?
Softproofing for a wide gamut inkjet can be problematic even with the best monitors which struggle to display the Adobe RGB gamut. If you desaturate the colors until they fit into such a relatively small monitor gamut, you would not be making the best use of your wide gamut printer. Adobe RGB differs from sRGB mainly in the greens, but what if you are printing red?
Considering that the primary reason anyone would move from ProPhoto to sRGB is to post images on the web, its questionable how much work in this rendering is worthwhile. Output to a 20x30 ink jet you’ll sell or hang on your wall, sure. Output to a 1200 pixel web gallery, where many viewing it don’t even have calibrated displays? Not sure this isn’t anything but a solution in search of a problem. Convert using the current tools and move on.
Quite a few mass merchant photo processors expect the files to be in sRGB even though that is not the native space of their photo printers because most P&S cameras output sRGB. In such a case, saturated colors having some gradation can be clipped to a nondescript blob in the printed image.
-
Does ICC Ver4 do this?
By and large, yes that’s the idea, at least when fully implemented using something called PRMG.
One issue is, with the current architecture, by the time the destination profile comes into play, all it knows is some Lab data has been handed to it. It has no idea if the source color space was sRGB or ProPhoto RGB. It uses a preset “guess” and moves on.
Softproofing for a wide gamut inkjet can be problematic even with the best monitors which struggle to display the Adobe RGB gamut. If you desaturate the colors until they fit into such a relatively small monitor gamut, you would not be making the best use of your wide gamut printer. Adobe RGB differs from sRGB mainly in the greens, but what if you are printing red?
And what if the image fully fits into sRGB but was encoded into Adobe RGB (1998)? Lots of images can and do (and many don’t).
Quite a few mass merchant photo processors expect the files to be in sRGB even though that is not the native space of their photo printers because most P&S cameras output sRGB. In such a case, saturated colors having some gradation can be clipped to a nondescript blob in the printed image.
That’s just a really brain dead workflow. There’s really no excuse for it. So on one hand, we worry about gamut clipping going from ProPhoto RGB to sRGB and how to hand tune the conversion, the opposite is taking an output device that has no relationship to sRGB and pretending that everything you feed it should be in sRGB. Talk about extremes! I do my best to ignore such labs that act this way because its half baked (at best) color management.
-
By intelligent perceptual rendering, I meant a rendering which takes the gamut of the colors that are actually in the image into account before arbitrarily desaturating colors when there are no out of gamut colors in the smaller space, as explained by Mike Chaney (http://www.steves-digicams.com/knowledge-center/understanding-rendering-intents.html) in the referenced review.
BTW, I can’t agree with everything here (which I glanced at quickly), for example:
Perceptual Intent: Use this method for most of your work especially if you intend to just set it and leave it alone. Perceptual intent will produce prints with accurate hue and while overall saturation levels may be a bit less, you are unlikely no notice this by just examining the print by itself. In addition, this method reduces artifacts like banding in blue skies.
Couple things to keep in mind. One is, there’s no standard way to produce a perceptual rendering intent. Its like a picture look between a Canon and a Nikon or how Fuji feels Velvia should render a scene versus Kodak using Ektachrome. Its really very subjective. One profile maker might do a completely different job than another when ink hits paper.
Second, images are far too complex to lump discussions of best rendering intents. Profiles don’t know squat about images. They see everything as solid color patches which when we view in context, and appear to us as an image. One profile with one rendering intent will treat a black dog on coal identically to a white cat on snow and every other images imaginable the same way. The reason we soft proof and toggle between intents is because the technology we have today simply can’t pick the correct or ideal rendering intent. Its very subjective. This is like most other “auto” anything we have, be it in software or in processing equipment. They can do a reasonable job most of the time, but few would admit they do an ideal job all the time. Its why we make our own prints, either in the darkroom or lightroom, because we have to make subjective decisions about our images.
The best rendering intent to use is the one that produces the appearance you desire. So when you consider that all perceptual rendering intents are different, and how complex images are, and that modern ICC color management is based on something as simple as how solid color patches match, and not on any color appearance models, saying one should use a particular rendering intent all the time sends the wrong message. It depends, YMMV. And to say that a Perceptual rendering intent will in any way produce a more accurate print (without defining accuracy and ignoring what the RelCol intent is supposed to do) is not something I’d agree with. Accurate and preferable often don’t equate! As for banding, I can assure you that if I build a profile using a tiny set of patches, lower number of nodes or just poor processing of the profile, the perceptual mapping will not produce less banding than using a RelCol intent with a superior built profile.
I understand the article is aimed at the entry level. But making hard and fast rules like the above isn’t very useful because such readers take them as gospel. YMMV is much a safer and truer statement.
-
But this is compatible with the philosophy of always displaying the real histogram. So I don't agree with you in that you don't agree with us
OK, but what is the "real" histogram? It may be what Andrew says - linear encoded. A histogram purposed to an sRGB JPEG may be "real" one day and a pain in the derriere the day after. I guess all I'm suggesting is that there is a workflow design philosophy behind the LR concept - now you may not agree with it for reasons you mention, but all I'm saying is that it makes sense, technically. I do agree, however, that it would be convenient to many users if it varied with choice if colour space, like in ACR. But then, why not go whole hog and vary it with a real output profile, whereupon VOILA we would have SOFTPROOFING (just about!....here it comes.......no not quite.............oops, there it goes.........)
-
Lightroom Podcast 8 (http://blogs.adobe.com/jnack/2006/07/lightroom_podcast_8.html) includes a discussion between Mark Hamburg (the chief architect of Lightroom) and Thomas Knoll (the chief architect of Photoshop and ACR) about how the histograms and color info readouts should be handled. Actually, Thomas recommended using the approach that he used in ACR where the user can select the color space, but Mark chose to use the current Lightroom approach for simplicity. So, Guillermo and I are in good company with our opinions.
In another post, Mr. Knoll pointed out that working in a ProPhotoRGB like space can lead to problems with colors that can not be printed nor shown on the monitor and requires a bit of knowledge about color management, rendering intents, etc. With ACR one can use your approach merely by always using 16 bit ProPhotoRGB. However, if you know that the final product will be 8 bit sRGB, it makes sense to render into this space and adjust the colors so that they fit or allow them to clip. The problem with Melissa is that it is neither fish nor fowl.
Oh, yes, I'm very familiar with the company you are in and I know both arguments. The problem with your penultimate sentence, however, at least for me, is that I DON'T KNOW what "the final product" is. Today I may be intending to post it to a web gallery, but next month I or someone else may want an 18*24 inch print of it. So then what? You can always use soft-proofing and RI to resolve the issue Thomas mentions, but it's a different matter doing it in reverse. Conventional advice has been to process and preserve images in wide colour space and high bit depth, then re-purpose copies as needed. To me that advice is still eminently sensible and is the workflow embedded in LR.
-
Ultimately you have to edit the source while viewing a soft proof.
Considering that the primary reason anyone would move from ProPhoto to sRGB is to post images on the web, its questionable how much work in this rendering is worthwhile. Output to a 20x30 ink jet you’ll sell or hang on your wall, sure. Output to a 1200 pixel web gallery, where many viewing it don’t even have calibrated displays? Not sure this isn’t anything but a solution in search of a problem. Convert using the current tools and move on.
Absolutely - from a practical, operational perspective this is where the rubber hits the road.
-
Softproofing for a wide gamut inkjet can be problematic even with the best monitors which struggle to display the Adobe RGB gamut. If you desaturate the colors until they fit into such a relatively small monitor gamut, you would not be making the best use of your wide gamut printer. Adobe RGB differs from sRGB mainly in the greens, but what if you are printing red?
Yes, this is a real issue. There was a time (not long ago at all) when we wouldn't be talking about these wide-gamut printers we now have for give or take a 1000 bucks - it's nothing short of miraculous, and displays are somewhat behind/costlier in this regard. BUT I would still argue this is not a reason to dumb down the files to the lowest common denominator of the technology. The files will live through many generations of technical change and you may want them to be up to the task - say - five or ten years from now when perhaps both the displays and the printers will be relatively inexpensive and have relatively more gamut then what we are discussing today.
-
Oh, yes, I'm very familiar with the company you are in and I know both arguments. The problem with your penultimate sentence, however, at least for me, is that I DON'T KNOW what "the final product" is. Today I may be intending to post it to a web gallery, but next month I or someone else may want an 18*24 inch print of it. So then what? You can always use soft-proofing and RI to resolve the issue Thomas mentions, but it's a different matter doing it in reverse. Conventional advice has been to process and preserve images in wide colour space and high bit depth, then re-purpose copies as needed. To me that advice is still eminently sensible and is the workflow embedded in LR.
If you are going to settle on one color space and bit depth for general use, then 16 bit ProPhotoRGB is a good choice. Once colors are clipped in a small space, they are gone forever. However, if the gamut of the scene fits into Adobe RGB, there is no advantage in using ProPhotoRGB. In fact, the latter would increase quantization errors, but this would not be significant with a bit depth of 16. Personally, I use 16 bit ProPhoto for most of my work, since I don't want to waste time determining the optimal space for each individual image.
However, I think Andrew sums up the situation most succinctly: "LRs Histogram represents “Melissa RGB” which is ProPhoto primaries with a 2.2 TRC gamma. That’s not the underlying color processing space (that be ProPhoto primaries with a linear TRC gamma). So you’re basically looking at a histogram that’s not based on anything you’ll ever see or use outside of LR. Its too bad LR doesn’t behave like ACR where the Histogram is based on the actual output encoding color space you pick in the workflow options."
-
Bill, I agree with most of this - I just wouldn't make too much of the Melissa RGB issue from an operational perspective.
-
That's the first thing I thought of when I read this problem and this is obviously the issue. sRGB is a MUCH narrower colour space than ProPhoto used in LR, so OBVIOUSLY if you export an image which just fits a ProPhoto space in LR to Photoshop with sRGB space there MUST BE clipping. Change your Photoshop working space to ProPhoto and the problem will evaporate.
I figured that I need to export to Photoshop in sRGB for those images I want to post in my online photo album. What I am doing now is leaving some room on the right side of the Lightroom histogram chart and if if I still see clipping in the Photoshop histogram, I go back to Lightroom and adjust the exposure/recovery sliders to move the highlights further to the left. If there is a more efficient way of doing things, please let me know.
p.s. Much of the discussion generated by this post is a bit beyond my knowledge, but I am learning alot. I just started preparing some images for printing, so it is helpful information.
-
However, if the gamut of the scene fits into Adobe RGB, there is no advantage in using ProPhotoRGB. In fact, the latter would increase quantization errors, but this would not be significant with a bit depth of 16.
I’m not necessarily so sure. I’m open to being shown my theories and those who agree are wrong. I’ve seen a number of cases where images encoded into both Adobe RGB (1998) and ProPhoto RGB from Raw, then post edited in Photoshop provide a visual example of quantization errors in the smaller but not larger color space. And in fact, at my recent Photoshop World session, I said to the audience that “unless you are pasting data original encoded into a small color space into a larger color space, there’s no advantage to converting into a larger color space” using the old analogy of a pint of water being poured into a gallon container doesn’t provide any more water. One of my students, a retired engineer didn’t agree and pointed out that having a larger encoding space in 16-bit (which is necessary, there’s no debate there), very well might provide benefits in editing when first converted to a larger color space.
If you go to my public iDisk, look for a folder called ProPhotovsAdobeRGB files, you’ll find a DNG called Flower_06October18_001.DNG.zip. Take that into ACR and use the current default rendering settings and encode in sRGB, Adobe RGB (1998) and ProPhoto RGB all in 16-bit. You have three documents that appear the same but in differing encoding color spaces.
Now make a very small Hue/Sat adjustment layer, say +7 saturation on one. Drag and drop onto the other two so all three get the same treatment. Zoom into the image at 100% and examine the effect of this slight edit on areas of the green parts of the flower. There’s pretty obvious appearing banding (quantization errors) in both the sRGB and Adobe RGB (1998) document with the ProPhoto doc smooth as silk. Now one could say “produce that plus sat in the Raw converter, not Photoshop” and I’d agree. But the case remains, post editing in 16-bit in all three encoding color spaces are not equal, there’s an advantage to the ProPhoto RGB edit.
My public iDisk:
thedigitaldog
Name (lower case) public
Password (lower case) public
Public folder Password is “public” (note the first letter is NOT capitalized).
To go there via a web browser, use this URL:
http://idisk.mac.com/thedigitaldog-Public (http://idisk.mac.com/thedigitaldog-Public)
(http://digitaldog.net/files/ProvsSvsARGB.jpg)
-
OK, but what is the "real" histogram? It may be what Andrew says - linear encoded. A histogram purposed to an sRGB JPEG may be "real" one day and a pain in the derriere the day after. I guess all I'm suggesting is that there is a workflow design philosophy behind the LR concept - now you may not agree with it for reasons you mention, but all I'm saying is that it makes sense, technically. I do agree, however, that it would be convenient to many users if it varied with choice if colour space, like in ACR.
The real histogram in this case is the one you will obtain in the next step, once you export to Photoshop, because that will be the histogram you will have to work with. I am not sure why Andrew is interested in the linearly encoded histogram, since in terms of information clipping the gamma curve is irrelevant and moreover a linear histogram is much more difficult to interpret for us poor human beings.
In my opinion the only design philosophy behind LR is this: simplification. It's a RAW developer never intended for technically advanced users but for professional photographers who need productivity and don't care at all about some clipped pixels.
Regards
-
I figured that I need to export to Photoshop in sRGB for those images I want to post in my online photo album. What I am doing now is leaving some room on the right side of the Lightroom histogram chart and if if I still see clipping in the Photoshop histogram, I go back to Lightroom and adjust the exposure/recovery sliders to move the highlights further to the left. If there is a more efficient way of doing things, please let me know.
p.s. Much of the discussion generated by this post is a bit beyond my knowledge, but I am learning alot. I just started preparing some images for printing, so it is helpful information.
No - you do not need to export to Photoshop in sRGB for your on-line photo album. You can export in 16 bit ProPhoto to maintain all the image data in one master file in a Photoshop-readable format for rendered images such as PSD or TIFF in 16-bit ProPhoto. (A rendered image is one exported from the raw converter, whether LR or ACR) and becomes a 3 channel non-raw image.) It is a good idea to do this because at some other time you may wish to make good quality large prints of some of these images and this kind of master image file will allow you to do this with a much higher probability of achieving better quality than you would get starting from an sRGB JPEG. It also gives you more control over the changes that will occur when you shrink the image from its large space high bit depth version to a web-friendly version.
To make it web-usable, you would first make any adjustments to its contrast, brightness and colours under Softproof (View>Softproof>Custom) with the sRGB color space selected as the prrofing condition. This allos you to predict the effect of the colour space change on the final result and adjust accordingly before the fact. Once this is done, flatten the image if you've made any adjustment layers. Then resize the image with "Resample" checked, using BiCubic Sharper, to say 700 pixels largest on either dimension and say 96 PPI (some people use 72 PPI). Then select Edit>Convert to Profile> and convert it to sRGB with Black Point compensation selected. Then go to Image>Mode and change it to an 8-bit file. Then do a "Save As" and select JPEG as the format. A dialog will come up asking what Quality you want. I generally use 10 or 11. The higher the number the larger the file but the less the JPEG compression (you lose less colour information). You now have a web-friendly, custom-adjusted JPEG separate from your master file (because you did SAVE AS, not Save - unless you screwed-up and missed this!).
It's a bit of effort (much of which you can automate with a Photoshop Action) but pays off in terms of both JPEG and master file quality.
-
I’m not necessarily so sure. I’m open to being shown my theories and those who agree are wrong. I’ve seen a number of cases where images encoded into both Adobe RGB (1998) and ProPhoto RGB from Raw, then post edited in Photoshop provide a visual example of quantization errors in the smaller but not larger color space. And in fact, at my recent Photoshop World session, I said to the audience that “unless you are pasting data original encoded into a small color space into a larger color space, there’s no advantage to converting into a larger color space” using the old analogy of a pint of water being poured into a gallon container doesn’t provide any more water. One of my students, a retired engineer didn’t agree and pointed out that having a larger encoding space in 16-bit (which is necessary, there’s no debate there), very well might provide benefits in editing when first converted to a larger color space.
I downloaded your DNG and confirmed your findings.
As far as theory regarding the size of color spaces, I was using Bruce Lindbloom's explanation in his characterization of his BetaRGB:
"One important characteristic would be that the working space is suffiently large that it can properly encode (or contain) all colors that are important to an application. This implies "larger is better."
Another attribute, which conflicts with the above, is that the working space should be as small as possible, so that quantization errors may be minimized. This implies "smaller is better."
I can't explain what is going on here. Besides size of the spaces in this experiment, there are also differences in gamma and white point, but I don't know how these differences would affect the results. Again quoting from Bruce Lindbloom:
"Since Adobe Photoshop and the ICC profile specifications both use D50 as a reference white, this was the logical choice. If instead, a non-D50 white was chosen, then both the creation of, and the use of the working space would require adaptation, which opens the door just a crack for mistakes to be made. Specifying the working space directly in D50 avoids this possibility for error."
I would be interested in what Eric Chan or some other experts think.
-
Now make a very small Hue/Sat adjustment layer, say +7 saturation on one. Drag and drop onto the other two so all three get the same treatment. Zoom into the image at 100% and examine the effect of this slight edit on areas of the green parts of the flower. There’s pretty obvious appearing banding (quantization errors) in both the sRGB and Adobe RGB (1998) document with the ProPhoto doc smooth as silk. Now one could say “produce that plus sat in the Raw converter, not Photoshop” and I’d agree. But the case remains, post editing in 16-bit in all three encoding color spaces are not equal, there’s an advantage to the ProPhoto RGB edit.
Andrew, if the conclusion here is to be: "a wider space protects you better against quantization errors", I think we are being wrong. The problem with your flower is simply it is saturated enough to easily produce clipping (clipping to 0 in the B channel in this case). But this is not a problem of quantization errors because of a lack of levels (which is the reason why Bruce Lindblom says "the narrower the better"), it's simply because of the gamut clipping in post processing.
This is the histogram and clipped areas in the B channel after a neutral RAW conversion with sRGB output of your flower:
(http://img16.imageshack.us/img16/3413/flowersrgbhis.gif)
(http://img269.imageshack.us/img269/8016/flowersrgbzonb.gif)
The flower was clipped right from the beginning, and everything that happens next when we add a saturation layer is due to the way Photoshop handles clipping in its saturation layer, which is very agressive. So my conclusion wouldn't be "there’s an advantage to the ProPhoto RGB edit", but "there's is an advantage in not clipping your images!" no matter what you need to do to prevent that clipping, or being a bit more critical towards Adobe routines "Photoshop saturation layers are crap". In your flower, sRGB was simply not wide enough to handle the required colour gamut so any comparision involving sRGB is not fair here.
Regards.
-
Link to topic "Lightroom 3 and Histogram, please give us the choice. (http://luminous-landscape.com/forum/index.php?showtopic=38701)
Hope we will be heard !
Thierry
-
Andrew, if the conclusion here is to be: "a wider space protects you better against quantization errors", I think we are being wrong. The problem with your flower is simply it is saturated enough to easily produce clipping (clipping to 0 in the B channel in this case). But this is not a problem of quantization errors because of a lack of levels (which is the reason why Bruce Lindblom says "the narrower the better"), it's simply because of the gamut clipping in post processing.
Guillermo,
Now that you point out the problem, it becomes obvious. I'm a bit embarrassed to not have noted the cause myself and I would think that Andrew is a bit red faced also. Looking at the histogram in ACR when rendering into sRGB, there is already some clipping in the red channel:
[attachment=17459:FlowerAC...istogram.png]
Rendering into ProPhotoRGB, increasing saturation by 8%, and then softproofing with sRGB as the output space, the pixelated areas that Andrew noted are out of sRGB gamut and were driven to saturation clipping by the edit. If you edited in ACR while rendering into sRGB, the clipping would have been obvious. However, if you had used Lightroom and exported to sRGB, the problem would probably have gone unnoticed, which was our original point.
[attachment=17460:Flower_SoftProof.png]
-
Well no, I’m not quote too red in the face because the illustration was to show that taking the same Raw, using the same rendering settings to produce a desired color appearance produces issues (calling it quantization errors is the error on my part) when you don’t use that larger encoding color space and then post edit the image in Photoshop. I don’t disagree with the statement about the layer adjustment being very aggressive. The illustration attempts to point out the potential pitfalls of using a smaller encoding color space from Raw from such an image and then doing further editing in Photoshop. I admitted that its kind of silly to make these moves and then add an adjustment layer for a saturation tweak after the fact. But the bottom line is, people will do this kind of work and one of the three encoding color spaces doesn’t suffer from that. I would think it also illustrates the folly of suggesting that Adobe RGB (1998) is a large enough encoding space when working with Raw originals.
-
I don’t disagree with the statement about the layer adjustment being very aggressive.
I am still using PS CS2 so I couldn't try this: is it possible to set a vibrance layer in PS CS4? vibrance is a somewhat more intelligent way to adjust saturation in PS taken from LR. And how does it work with yout flower?
-
So try this. In ACR lower the saturation to -13 such there's no red pixels indicating clipping in sRGB, then do the test again, it still doesn't bode well for sRGB or Adobe RGB vs. ProPhoto (use the same plus 7 Sat adjustment). And mind you, -13 to get sRGB not to clip, working by the Histogram, doesn't leave a rendering I'd like of this image.
(http://digitaldog.net/files/sVsAdobevsPro1.jpg)
Didn't label the three, can you tell which is sRGB, Adobe RGB and ProPhoto RGB?
-
is it possible to set a vibrance layer in PS CS4? vibrance is a somewhat more intelligent way to adjust saturation in PS taken from LR. And how does it work with yout flower?
Vibrance is much better, no question although the values and the visual effect don't match Saturation. Still looks smoother in the ProPhoto but not anywhere as pronounced (this is with the -13 sat rendering out of ACR for no sRGB clipping).
-
The illustration attempts to point out the potential pitfalls of using a smaller encoding color space from Raw from such an image and then doing further editing in Photoshop. I would think it also illustrates the folly of suggesting that Adobe RGB (1998) is a large enough encoding space when working with Raw originals.
This exercise does illustrate the points you mentioned, but still there is no advantage in using a color space wider than necessary to contain the gamut of the final image. However, it does demonstrate that ordinary digital captures may have colors well outside of the gamut of Adobe RGB (which was first made known to me by Bruce Fraser in his Camera Raw book). By this time I would think that most of us agree that 16 bit ProPhotoRGB (among the spaces available in Camera Raw) is the preferred working space for digital camera captures. There is no need to argue about that.
The Colorthink plot below demonstrates the gamut of your flower picture along with the gamuts of Adobe RGB and a modern ink jet printer (the Epson 9900 with Epson Exhibition Fiber paper). The image was rendered without adjustments into ProPhotoRGB to include all of the colors captured by the camera. Many of the yellows are outside of the gamut of Adobe RGB but within the gamut of the printer, and these would be lost if one had rendered into Adobe RGB. Still there are yellows outside of the gamut of the printer, and these colors might be capable of being printed by the next generation of printers.
Still, there are occasions when one might want to render into Adobe RGB. For example, the client might demand Adobe RGB or you know that the images do not have important colors outside of the Adobe RGB gamut or you will not be printing on a wide gamut device. In such cases Adobe RGB is a good choice and allows 8 bits per channel and and 8 bit JPEGs. You might want to keep your options open with ProPhotoRGB, but then if you used Adobe RGB, you could still go back to the raw file if you needed an expanded gamut. If you had used parametric editing in ACR, all that would be necessary is to change the output space. If you had laboriously done a great deal of editing in Photoshop, it would have been foolish to have used a narrow gamut space.
[attachment=17473:FliowerColorThink.png]
-
This exercise does illustrate the points you mentioned, but still there is no advantage in using a color space wider than necessary to contain the gamut of the final image. However, it does demonstrate that ordinary digital captures may have colors well outside of the gamut of Adobe RGB (which was first made known to me by Bruce Fraser in his Camera Raw book). By this time I would think that most of us agree that 16 bit ProPhotoRGB (among the spaces available in Camera Raw) is the preferred working space for digital camera captures. There is no need to argue about that.
Who me, argue? <G> Actually there are some pundits who’s names will remain unlisted who would not share this philosophy.
-
Actually there are some pundits who’s names will remain unlisted who would not share this philosophy.
Some pundits? If you have in mind the well-known, well-published category - I can only think of one - but ya, let's not go there.
-
Some pundits? If you have in mind the well-known, well-published category - I can only think of one - but ya, let's not go there.
There’s more than one for sure! I know who you’re thinking about. The other guy leads us to believe he invented the digital camera sensor or maybe aspirin. There’s a few lesser known out there. But as you say, lets not go there.