Ad
Ad
Ad
Pages: « 1 [2] 3 »   Bottom of Page
Print
Author Topic: Why change in Histogram from Lightroon to Photoshop?  (Read 10045 times)
digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #20 on: October 23, 2009, 04:14:00 PM »
ReplyReply

Quote from: bjanes
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.

Quote
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).

Quote
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.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #21 on: October 23, 2009, 04:28:58 PM »
ReplyReply

Quote from: bjanes
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 in the referenced review.

BTW, I can’t agree with everything here (which I glanced at quickly), for example:
Quote
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.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #22 on: October 23, 2009, 04:30:41 PM »
ReplyReply

Quote from: GLuijk
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.........)  
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #23 on: October 23, 2009, 04:39:14 PM »
ReplyReply

Quote from: bjanes
Lightroom Podcast 8 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.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #24 on: October 23, 2009, 04:46:52 PM »
ReplyReply

Quote from: digitaldog
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.


Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #25 on: October 23, 2009, 05:02:20 PM »
ReplyReply

Quote from: bjanes
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.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
bjanes
Sr. Member
****
Offline Offline

Posts: 2825



« Reply #26 on: October 23, 2009, 09:24:39 PM »
ReplyReply

Quote from: MarkDS
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."
Logged
Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #27 on: October 23, 2009, 09:35:47 PM »
ReplyReply

Bill, I agree with most of this -  I just wouldn't make too much of the Melissa RGB issue from an operational perspective.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
ChuckZ
Jr. Member
**
Offline Offline

Posts: 59


WWW
« Reply #28 on: October 24, 2009, 09:03:00 AM »
ReplyReply

Quote from: MarkDS
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.
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #29 on: October 24, 2009, 10:57:05 AM »
ReplyReply

Quote from: bjanes
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

Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1291



WWW
« Reply #30 on: October 24, 2009, 11:21:13 AM »
ReplyReply

Quote from: MarkDS
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


Logged

Mark D Segal
Contributor
Sr. Member
*
Offline Offline

Posts: 6977


WWW
« Reply #31 on: October 24, 2009, 11:44:30 AM »
ReplyReply

Quote from: ChuckZ
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.
Logged

Mark D Segal (formerly MarkDS)
Author: "Scanning Workflows with SilverFast 8....." http://www.luminous-landscape.com/reviews/film/scanning_workflows_with_silverfast_8.shtml
bjanes
Sr. Member
****
Offline Offline

Posts: 2825



« Reply #32 on: October 24, 2009, 12:19:02 PM »
ReplyReply

Quote from: digitaldog
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.
Logged
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1291



WWW
« Reply #33 on: October 24, 2009, 01:18:43 PM »
ReplyReply

Quote from: digitaldog
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:





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.
« Last Edit: October 24, 2009, 01:26:11 PM by GLuijk » Logged

thierrylegros396
Sr. Member
****
Offline Offline

Posts: 672


« Reply #34 on: October 24, 2009, 01:34:19 PM »
ReplyReply

Link to topic "Lightroom 3 and Histogram, please give us the choice.

Hope we will be heard !

Thierry
Logged
bjanes
Sr. Member
****
Offline Offline

Posts: 2825



« Reply #35 on: October 24, 2009, 05:01:55 PM »
ReplyReply

Quote from: GLuijk
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]
Logged
digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #36 on: October 24, 2009, 06:35:31 PM »
ReplyReply

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.
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Guillermo Luijk
Sr. Member
****
Offline Offline

Posts: 1291



WWW
« Reply #37 on: October 24, 2009, 06:56:19 PM »
ReplyReply

Quote from: digitaldog
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?
Logged

digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #38 on: October 24, 2009, 07:44:01 PM »
ReplyReply

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.


Didn't label the three, can you tell which is sRGB, Adobe RGB and ProPhoto RGB?
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
digitaldog
Sr. Member
****
Offline Offline

Posts: 9191



WWW
« Reply #39 on: October 24, 2009, 07:49:55 PM »
ReplyReply

Quote from: GLuijk
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).
Logged

Andrew Rodney
Author “Color Management for Photographers”
http://digitaldog.net/
Pages: « 1 [2] 3 »   Top of Page
Print
Jump to:  

Ad
Ad
Ad