Luminous Landscape Forum

Raw & Post Processing, Printing => Digital Image Processing => Topic started by: Mark D Segal on July 24, 2007, 06:23:07 PM

Title: Your Curves
Post by: Mark D Segal on July 24, 2007, 06:23:07 PM
I have created this thread for any feedback and discussion of my essay "Do Your Curves Throw You a Curve?", published on Luminous-Landscape today. It would be ideal if all contributors to this discussion posted in this thread, for continuity and ease of reference.
Title: Your Curves
Post by: OnyimBob on July 24, 2007, 07:22:58 PM
I'd love to read your article but, as has happened once or twice lately, there's nothing to read. The home page "what's new" indicates that it's there --- but it ain't!
I'll keep loking,
Cheers,
Bob.
Title: Your Curves
Post by: Schewe on July 24, 2007, 07:25:25 PM
Scroll down...
Title: Your Curves
Post by: Mark D Segal on July 24, 2007, 07:38:52 PM
There's now a link from "What's New" Your Curves (http://luminous-landscape.com/whatsnew/) of July 25th - this takes you to the Intro from which you can download the article.
Title: Your Curves
Post by: digitaldog on July 24, 2007, 08:15:18 PM
Its a PDF which in this case, is really useful to print out (in color if possible) and read. While I think most articles on this site can be read on line, this one is very through and too long to be on line,  and really needs to be printed and studied carefully.
Title: Your Curves
Post by: FredT on July 24, 2007, 11:22:25 PM
Very nice, Mark.  Thank you.  I'll have to do as Andrew suggests and print it out for a more thorough study.
Title: Your Curves
Post by: Eric Myrvaagnes on July 24, 2007, 11:58:20 PM
Excellent essay, Mark.

Having gotten used to Capture One, RSP, and lately DxO, I've never really given CR a decent try (I didn't like whatever version I first tried, way back whenever.) But your well-written essay makes the new CR look very appealing and not as baffling as I expected.

Thanks for all your good work on this.
Title: Your Curves
Post by: Ray on July 25, 2007, 02:02:22 AM
Mark,
This is an attempt at a very thorough treatment of aspects of curves and I've downloaded the pdf as have others. But my feeling is, the bottom line is, you must experiment. Using curves is an extremely heuristic process. The slightest movement of any point on a color specific curve can produce a significant change.

One feature I would very much like in PS is an ability to zoom on the image whilst the curves dialog box is open. That way, one could get a clear idea of how localised changes affect the over all image.
Title: Your Curves
Post by: digitaldog on July 25, 2007, 09:07:37 AM
Quote
One feature I would very much like in PS is an ability to zoom on the image whilst the curves dialog box is open. That way, one could get a clear idea of how localised changes affect the over all image.
[a href=\"index.php?act=findpost&pid=129817\"][{POST_SNAPBACK}][/a]

You can do this (have been able for many versions). You can zoom/pan using the standard key commands while all dialog boxes are open. With Levels, curves etc open, just use the Command/Control and Option/Alt keys to invoke the zoom in or out cursor and click away.
Title: Your Curves
Post by: Ray on July 25, 2007, 09:44:02 AM
Quote
You can do this (have been able for many versions). You can zoom/pan using the standard key commands while all dialog boxes are open. With Levels, curves etc open, just use the Command/Control and Option/Alt keys to invoke the zoom in or out cursor and click away.
[a href=\"index.php?act=findpost&pid=129840\"][{POST_SNAPBACK}][/a]


Eh! Can you be more specific. I have an image open at a specific degree of enlargement. I open a curves dialog box and my curser changes from the zoom tool to the eyedropper. I'm on a windows platform. Ctrl or alt, ctrl and alt, do nothing to change this whilst the curves box is open.
Title: Your Curves
Post by: digitaldog on July 25, 2007, 09:56:32 AM
Quote
Eh! Can you be more specific. I have an image open at a specific degree of enlargement. I open a curves dialog box and my curser changes from the zoom tool to the eyedropper. I'm on a windows platform. Ctrl or alt, ctrl and alt, do nothing to change this whilst the curves box is open.
[a href=\"index.php?act=findpost&pid=129843\"][{POST_SNAPBACK}][/a]

You need the cursor to be a zoom or pan tool using the key commands:

Space bar + Command/Control is zoom in
Space bar + Option/Alt is zoom out
Space bar alone is pan

You have to use the above two key combo's and click on the image. Use just space bar to pan about.

In CS3, there's even more control over palettes and dialogs thanks to the UI design.
Title: Your Curves
Post by: Ray on July 25, 2007, 10:13:40 AM
Ah! The space bar. I've got a lot to learn   . Thanks for that.
Title: Your Curves
Post by: Eric Myrvaagnes on July 25, 2007, 10:22:06 AM
Quote
Eh! Can you be more specific. I have an image open at a specific degree of enlargement. I open a curves dialog box and my curser changes from the zoom tool to the eyedropper. I'm on a windows platform. Ctrl or alt, ctrl and alt, do nothing to change this whilst the curves box is open.
[a href=\"index.php?act=findpost&pid=129843\"][{POST_SNAPBACK}][/a]
Ray,

Try holding CTRL while pressing either + or - on the numeric keypad (to zoom in or out, respectively.) Works fine for me (CS2 on Win XP Pro.)
Title: Your Curves
Post by: Eric Myrvaagnes on July 25, 2007, 10:27:34 AM
When I try CTRL plus SPACE and then click, the Levels dialog box disappears before the zoom happens, but with CTRL plus "+" (on numeric keypad), the zoom happens immediately and Levels stays open.

Same with Curves. CTRL together with numeric + and - seems much nicer to me. To pan just use the horizontal and vertical scroll bars.
Title: Your Curves
Post by: Ray on July 25, 2007, 11:19:57 AM
Quote
When I try CTRL plus SPACE and then click, the Levels dialog box disappears before the zoom happens, but with CTRL plus "+" (on numeric keypad), the zoom happens immediately and Levels stays open.

Same with Curves. CTRL together with numeric + and - seems much nicer to me. To pan just use the horizontal and vertical scroll bars.
[a href=\"index.php?act=findpost&pid=129851\"][{POST_SNAPBACK}][/a]

Eric,
Yes, you're right. The curves dialog box does have a tendency to disappear when using the space bar. Ctrl with + or - works just fine.
Title: Your Curves
Post by: mitra on July 25, 2007, 02:44:56 PM
I'm fascinated by this discussion, but still in the Dark Ages (CS2). Is there an article I can read on parametric curves and how one determines, given image's characteristics, where to move them along the X axis?
Title: Your Curves
Post by: Mark D Segal on July 25, 2007, 03:29:38 PM
Quote
I'm fascinated by this discussion, but still in the Dark Ages (CS2). Is there an article I can read on parametric curves and how one determines, given image's characteristics, where to move them along the X axis?
[a href=\"index.php?act=findpost&pid=129875\"][{POST_SNAPBACK}][/a]

There is excellent resource material on Lightroom (for example Michael and Jeff's DVD download on this website, plus recent books by Martin Evening and Scott Kelby on Lightroom. Also, Ben Willmore's CS 3 Up to Speed Chapter 2. I point you to Lightroom because the Develop Module is essentially the same as what you find in Camera Raw 4.x.

But frankly, the very best thing to is experiment. Make copies of a few raw files, put them in another folder, don't worry about what happens to them as you play - all you have to lose is some duplicate pixels if the worst happens (but needn't).

Go to the parametric curve and before adjusting anything on the X axis under the box, make an S Curve by decreasing the Shadow slider a lot, decrease the Darks slider some but less, increase the Lights slider and decrease the Highlights slider. Now you have clearly demarcated brighter and darker zones in the image - by design. Make sure you've created a steep enough S so the contrast between these zones is very obvious.

Now start moving each zone slider under the Curves box back and forth, and you will see relative to where each slider demarcates on the histogram how the tonality of the two adjacent zones changes while you adjust.

The next thing to do is to go to the Point Curve tab, select the Eyedropper tool, press Control (Command on a Mac I think) and as you left-click the mouse, mouse-over what appear to be the darker and lighter parts of the image and watch on the tone curve where the distinctions between light and dark lie. Remember the placements, or do a rough diagram with a pencil and paper and mark Xs on the curve about where you see the breaks between highlight/lights, lights/darks and darks/shadows. Now go back to the Parametric curve, and adjust your sliders so that if you were to drop verticals upward from the sliders, they would intersect the Curve about where you placed thoses Xs. It's a bit awkward (but it works) why I suggested in my conclusions that this capability we have in the Point Curve to demarcate the zones from analyzing the image should also be conveyed to the Parametric Curve where it is actually useful.

But you need not stick with that demarcation. It depends on what effects you wish to get. You essentially have a matrix of seven controls in that parametric dialog which gives you huge flexibility to combine any set of placements that best meets your taste and your requirements. After some experimenting, you'll get the hang of it, and it becomes somewhat second-nature.

Enjoy!
Title: Your Curves
Post by: laughfta on July 25, 2007, 04:10:24 PM
I inadvertently posted to a new topic, though my questions belong here. Meanwhile, Mark answered one of them so I will cross that off my list.  Thanks, Mark  

From Mark's essay:

QUOTE
CR  Curves have a hue lock. They map the minimum and maximum RGB values (in linear ProPhoto RGB) through the tone curve, and the middle value is interpolated to exactly preserve hue. The PS-RGBc does not have a hue lock. But setting the PS-RGBc to Luminosity Blend Mode preserves the colour of the underlying layer. Using the Lab L*Curve for this purpose has only fair colour consistency as L* is changed holding a* andb* constant.


1. Does the CR curve, then, exactly preserve hue even with the mild saturation changes?
2. If so, must one continue to work in ProPhotoRGB when in PS to realize this advantage? Can Adobe RGB also preserve exact hue?
3. I think I understand that (in LAB) a* and b* do not remain constant as to hue as the L* is changed; they drift slightly. But in the PS-RGB curve is the hue exactly preserved in the Luminosity Blend Mode? Would this be this considered "locking" the hue, at this point?


And thanks for the great article!
Title: Your Curves
Post by: Mark D Segal on July 25, 2007, 05:14:12 PM
Quote
IFrom Mark's essay:

QUOTE
CR  Curves have a hue lock. They map the minimum and maximum RGB values (in linear ProPhoto RGB) through the tone curve, and the middle value is interpolated to exactly preserve hue. The PS-RGBc does not have a hue lock. But setting the PS-RGBc to Luminosity Blend Mode preserves the colour of the underlying layer. Using the Lab L*Curve for this purpose has only fair colour consistency as L* is changed holding a* andb* constant.
1. Does the CR curve, then, exactly preserve hue even with the mild saturation changes?
2. If so, must one continue to work in ProPhotoRGB when in PS to realize this advantage? Can Adobe RGB also preserve exact hue?
3. I think I understand that (in LAB) a* and b* do not remain constant as to hue as the L* is changed; they drift slightly. But in the PS-RGB curve is the hue exactly preserved in the Luminosity Blend Mode? Would this be this considered "locking" the hue, at this point?
And thanks for the great article!
[a href=\"index.php?act=findpost&pid=129888\"][{POST_SNAPBACK}][/a]

Hi Gloria, thanks - glad you're enjoying the article. Let me try answering these in order:

(1) My understanding of this based on the information I reported in the Principles section of the article, and based on the test I did (page 17) seems very much to be YES.

(2) ProPhoto and Adobe RGB(98) are both RGB colour working spaces, the former being much wider than the latter. It stands to reason that if by converting your working space from the former to the latter you clip a channel or two in ARGB(98) that were not previously clipped in Pro Photo, the affected pixels should have a hue shift because the colour composition has changed. But to see this in a print, the affected hues would have to have been in printer gamut.

(3) Based on all I've read about it and the experiments I've done, using an RGB composite curve in Luminosity Blend Mode is supposed to preserve the hues of the underlying layer. I don't know whether it does so EXACTLY for every conceivable pixel value.
Title: Your Curves
Post by: mitra on July 25, 2007, 06:23:24 PM
Quote
There is excellent resource material on Lightroom (for example Michael and Jeff's DVD download on this website, plus recent books by Martin Evening and Scott Kelby on Lightroom. Also, Ben Willmore's CS 3 Up to Speed Chapter 2. I point you to Lightroom because the Develop Module is essentially the same as what you find in Camera Raw 4.x.

But frankly, the very best thing to is experiment. Make copies of a few raw files, put them in another folder, don't worry about what happens to them as you play - all you have to lose is some duplicate pixels if the worst happens (but needn't).

Go to the parametric curve and before adjusting anything on the X axis under the box, make an S Curve by decreasing the Shadow slider a lot, decrease the Darks slider some but less, increase the Lights slider and decrease the Highlights slider. Now you have clearly demarcated brighter and darker zones in the image - by design. Make sure you've created a steep enough S so the contrast between these zones is very obvious.

Now start moving each zone slider under the Curves box back and forth, and you will see relative to where each slider demarcates on the histogram how the tonality of the two adjacent zones changes while you adjust.

The next thing to do is to go to the Point Curve tab, select the Eyedropper tool, press Control (Command on a Mac I think) and as you left-click the mouse, mouse-over what appear to be the darker and lighter parts of the image and watch on the tone curve where the distinctions between light and dark lie. Remember the placements, or do a rough diagram with a pencil and paper and mark Xs on the curve about where you see the breaks between highlight/lights, lights/darks and darks/shadows. Now go back to the Parametric curve, and adjust your sliders so that if you were to drop verticals upward from the sliders, they would intersect the Curve about where you placed thoses Xs. It's a bit awkward (but it works) why I suggested in my conclusions that this capability we have in the Point Curve to demarcate the zones from analyzing the image should also be conveyed to the Parametric Curve where it is actually useful.

But you need not stick with that demarcation. It depends on what effects you wish to get. You essentially have a matrix of seven controls in that parametric dialog which gives you huge flexibility to combine any set of placements that best meets your taste and your requirements. After some experimenting, you'll get the hang of it, and it becomes somewhat second-nature.

Enjoy!
[a href=\"index.php?act=findpost&pid=129882\"][{POST_SNAPBACK}][/a]

Thanks for your extensive reply.  I agree with the experimentation route but as of now only have CS2.  I'm creating a CS3 folder with tutes and other information and will save your comments there.
Title: Your Curves
Post by: laughfta on July 25, 2007, 10:43:51 PM
Quote
If so, must one continue to work in ProPhotoRGB when in PS to realize this advantage? Can Adobe RGB also preserve exact hue?


Quote
2) ProPhoto and Adobe RGB(98) are both RGB colour working spaces, the former being much wider than the latter. It stands to reason that if by converting your working space from the former to the latter you clip a channel or two in ARGB(98) that were not previously clipped in Pro Photo, the affected pixels should have a hue shift because the colour composition has changed. But to see this in a print, the affected hues would have to have been in printer gamut.


Thanks, Mark. I think I need my answers before I can clearly phrase my question:  
I am wondering if the improvements (in the ability of the curve to preserve hue) in ACR/LR are dependent on the much larger ProPhoto RGB color space? It seems as if a larger color space would mean more leeway in absorbing some of the stresses like contrast and and saturation adjustments without noticeable hue changes?
Title: Your Curves
Post by: Mark D Segal on July 25, 2007, 11:00:28 PM
Quote
Thanks, Mark. I think I need my answers before I can clearly phrase my question: 
I am wondering if the improvements (in the ability of the curve to preserve hue) in ACR/LR are dependent on the much larger ProPhoto RGB color space? It seems as if a larger color space would mean more leeway in absorbing some of the stresses like contrast and and saturation adjustments without noticeable hue changes?
[a href=\"index.php?act=findpost&pid=129927\"][{POST_SNAPBACK}][/a]

No, as far as I know preserving hue does not depend on the size of the colour space unless you move from a wider to a narrower space causing clipping of channels in the latter.

But speaking of leeway for absorbing stresses, unless you work with 16-bit files when you use a wide space such as ProPhoto, contrast and hue adjustments can trigger banding or posterization effects. This happens say with 8-bit files because you start with only 256 levels spread over a relatively huge colour space and then lose some with these adjustments, so smooth tonal transitions can give way to discrete "bumps". It is much safer to fill that huge space with 16 bit files where there is a theoretical 65536 levels, though Photoshop actually works in 15 bit reducing the levels to 32768, however the original raw files generally have a maximum 12 bit depth to start with, meaning the originating data has 4096 levels of real image data - still a huge improvement over 256 for preventing trouble in wide colour spaces.
Title: Your Curves
Post by: adias on July 26, 2007, 01:15:26 AM
Mark:

I enjoyed your article and find it right on target. The reaction to using these tools comes often, in my view, from steeped habits that are hard to break.

When using Fill Light to open up shadows you mentioned also using Shadows to compensate and balance the image. I also find that the combination of Fill Light with the Curves Shadows' slider works very well. In a particular image I used Fill Light +24 and Shadows -20.
Title: Your Curves
Post by: digitaldog on July 26, 2007, 08:34:02 AM
Quote
Thanks, Mark. I think I need my answers before I can clearly phrase my question: 
I am wondering if the improvements (in the ability of the curve to preserve hue) in ACR/LR are dependent on the much larger ProPhoto RGB color space? It seems as if a larger color space would mean more leeway in absorbing some of the stresses like contrast and and saturation adjustments without noticeable hue changes?
[a href=\"index.php?act=findpost&pid=129927\"][{POST_SNAPBACK}][/a]

All the work is done under the hood in linear encoded ProPhoto RGB (primaries). If you ask for a smaller encoding color space, a conversion has to take place like all such color space conversions. How much of the image's gamut is in or out of the gamut of the encoding color space? How many out of gamut colors have to be mapped (using a RelCol itnent) from space to space? If you have colors outside of Adobe RGB (1998) and ask to encode in that space (or sRGB), there's going to be clipping. Fact of life. If that's a concern, encode in ProPhoto RGB.

Gamut mapping and resulting clipping happens just about every time we convert from color space to color space.
Title: Your Curves
Post by: Chris_T on July 26, 2007, 09:49:47 AM
I have yet to venture into ACR or Lightroom, but I use curves extensively in PS and consider it my tool of choice. My following comments are therfore based on PS curves only. As you have pointed out, curves do have some "side effects", namely:

- When a portion of a curve is steepened, other portions of the curve are flattened. The contrast of the steepened tonal range is increased, but at the expense of the contrast of the flattened tonal range being reduced.

- Writing curves to adjust tones can result in saturation/hue shifts, and vice versa.

To overcome these, many will combine curves with masks, blending modes, and/or channel mixing. People like Margulis and Varis also suggest separting tonal correction from color correction. In my experience, how to deal with these side effects depends tremendously on the kind of image being corrected. With some images, these side effects are inconsequential and simple curves by themselves will work. With other images, I find myself trying out different methods to compensate for them.  I often wonder why Adobe don't make it simpler by providing separate curves tools, such as one for tone, one for hue and one for saturation. I also wonder why such side effects are not treated more thoroughly (or at all) in the 500+ page PS books.

Your article is an heroic attempt, but I think that it can be improved by stating the PS curves' side effects as baselines first, before comparing them against ACR's or Lightroom's curves.  As mentioned earlier, the kind of images being used for comparison makes a huge difference. With an agreed upon set of baselines or images for this purpose, comparisons and discussions can be made with more context and objectivity. BTW, this is a generic problem when subjective comparisons are made online, and you are by no means being singled out. But since you must have put lots of efforts into this article, I thought it's worth my $.002.

Here are a few links for all you curves enthusiasts out there:

For the novice (and not so novice):
http://ronbigelow.com/articles/curves-1/curves-1.htm (http://ronbigelow.com/articles/curves-1/curves-1.htm)

A great (and rare) description of curves' tonal contrast tradeoff:
http://ronbigelow.com/articles/shadow/shad...-highlight2.htm (http://ronbigelow.com/articles/shadow/shadow&highlight2/shadow-highlight2.htm)

A traditionalist's (brave and bound to be controversial) view on curves:
http://www.arraich.com/ps8_CurvesCommentary1.htm (http://www.arraich.com/ps8_CurvesCommentary1.htm)

At the other end of the spectrum, this guy believes in curves, and nothing but curves:
http://www.curvemeister.com/ (http://www.curvemeister.com/)
Title: Your Curves
Post by: Mark D Segal on July 26, 2007, 02:29:30 PM
Quote
I often wonder why Adobe don't make it simpler by providing separate curves tools, such as one for tone, one for hue and one for saturation. I also wonder why such side effects are not treated more thoroughly (or at all) in the 500+ page PS books.

As mentioned earlier, the kind of images being used for comparison makes a huge difference. With an agreed upon set of baselines or images for this purpose, comparisons and discussions can be made with more context and objectivity. BTW, this is a generic problem when subjective comparisons are made online, and you are by no means being singled out. But since you must have put lots of efforts into this article, I thought it's worth my $.002.

[a href=\"index.php?act=findpost&pid=129984\"][{POST_SNAPBACK}][/a]

Hi Chris,

If you wish to separate luminosity from colour using curves you can create two curves adjustment layers, one in Luminosity mode and one in Color mode, then vary their opacities to taste. Or you can do what I demonstrated in the article working with a combination of Curves and HSB adjustment layers. Adobe could always add more tools, but with Photoshop having gone through 10 versions by now and given the tools it already has for achieving this objective, perhaps simplifying this separation is either not high on their list of priorities, or customer demand has not made it so, or both.

And that of course is not unrelated to what you say about the 500+page books not exploring this issue very much; you are right - with the exceptions of Dan Margulis and Michael Kieran, most of the authors devote most of their space for Curves on showing how to adjust contrast with the composite curve and colour balance with the individual channel curves. It seems as if the saturation boost from Curves just hasn't had much traction as a big-ticket issue.

You are right about the hazards of selecting images for making demonstrations. I mentioned that twice-over and I explained the criteria for the images I used. I don't know with whom I was supposed to obtain an authoritative agreement on "baseline" images, or whether such a thing would even be an operationally fesible approach.

That said, there are some kinds of images which we know in advance would fare poorly without complex correction procedures that go beyond what we can do within a raw converter or relatively straightforward curves moves in Photoshop. I mentioned some of the more obvious ones just to make the point that no one piece of software or one approach is the be-all and end-all for every conceivable situation. The article is long enough just covering its basic intent. I could probably generate another ten pages or so demonstrating both how to select very breakable images and then proceed to break them - but who really needs that?
Title: Your Curves
Post by: digitaldog on July 26, 2007, 02:45:48 PM
Quote
Adobe could always add more tools, but with Photoshop having gone through 10 versions by now and given the tools it already has for achieving this objective, perhaps simplifying this separation is either not high on their list of priorities, or customer demand has not made it so, or both.

with the exceptions of Dan Margulis and Michael Kieran, most of the authors devote most of their space for Curves on showing how to adjust contrast with the composite curve and colour balance with the individual channel curves. It seems as if the saturation boost from Curves just hasn't had much traction as a big-ticket issue.

Exactly! With the exception of Dan, and to a far, less aggressive stance Kieran, I suspect millions of images have been adjusted using curves since 1990 in Photoshop, maybe hundreds of thousands in CR since it shipped and we've hardly heard anyone complain. Like Jeff said in the other Curves posts, if you want Adobe engineers to provide a new feature, you have to illustrate why such a feature is absolutely necessary. Some images may very well suffer from arbitrary yanking of curves but by and large, only one person has made this a political cause when very few end users have seen any such issues. To suggest that building a tool a certain way based on what people expect to see in most images is damaging to all images and thus makes the tool unsuitable for professional use is a huge stretch to say the least. But I'd agree that it might be useful to have additional controls. I'd really like to see a separate saturation curve like we had in LinoColor years ago. Perhaps the curves dialog in Photoshop/CR/LR could have a fourth (in RGB mode) curve that only affects saturation. You could use it alone as was the case in LinoColor or you could lock it into place for certain images when pulling the so called 'master curve". Or you could just leave it alone, allowing the curves to operate as they have for 17 years.
Title: Your Curves
Post by: Guillermo Luijk on July 26, 2007, 06:00:08 PM
This is a very interesting topic, and I usually find in Photograph forums some people showing others how to adjust contrast in their pictures using the Curves tool (or the Levels tool), usually without caring at all about the fusion mode used to preserve tone. Glad to see some people really care about this.

I have done the following experiment with a photograph to find out how well PS keeps tones depending on the colour profile in which the picture is. I am not sure if what I did provides any conclusion, but I will explain.

One of my programs (Tone Hacker (http://www.guillermoluijk.com/software/tonehacker/index.htm)) plots a Hue histogram (it's rare to find them, although I consider them really useful that's why I put it there) based on the RGB->HSV conversion formulas found here: RGB to HSV formulas (http://en.wikipedia.org/wiki/HSV_color_space).

- I have opened a photograph in Photoshop in sRGB, saved it (JPG) and calculated its Hue histogram
- Then I have added a strong contrast 'S' shaped curve in Normal fusion mode and saved again (JPG) and calculated its Hue histogram
- Then I have switched the curve from Normal to Luminance fusion mode and saved again (JPG) and calculated its Hue histogram

- And I have repetead the 3 steps for the image converted first to AdobeRGB, obtaining the histograms and...
- Repeated again the process converting from the original sRGB to ProPhoto obtaining the histograms too.

Finally I show you here the original image and the curve applied:

(http://img249.imageshack.us/img249/5469/picbl6.jpg)  .  (http://img249.imageshack.us/img249/4034/curvasaq3.jpg)

And here I compare (the upper is the Hue histogram resulting when having applied the curve, and the lower histogram is always the original in each colour profile, just upside down for easy difference detection):

[span style=\'font-size:14pt;line-height:100%\']sRGB[/span]

Normal fusion mode (left) vs Luminance fusion mode (right)
(http://img249.imageshack.us/img249/4928/srgbnormalpt1.gif)  .  (http://img249.imageshack.us/img249/8449/srgblumbl7.gif)


[span style=\'font-size:14pt;line-height:100%\']AdobeRGB[/span]

Normal fusion mode (left) vs Luminance fusion mode (right)
(http://img249.imageshack.us/img249/1140/adobergbnormalwy8.gif)  .  (http://img249.imageshack.us/img249/7650/adobergblumfm7.gif)


[span style=\'font-size:14pt;line-height:100%\']ProPhoto[/span]

Normal fusion mode (left) vs Luminance fusion mode (right)
(http://img249.imageshack.us/img249/6509/prophotonormalwr7.gif)  .  (http://img249.imageshack.us/img249/8681/prophotolumdy4.gif)



The curve is very severe. It's easy to see that when the Normal fusion mode in the curve clearly modifies the Hue in the whole scene, however the Luminance fusion mode preserves the Hue and does it independently of which colour profile is being used.

Of course the effect of the curve in each colour profile is different, as histograms are, but the important conclusion is that HUE IS ALWAYS PRESERVED IF LUMINANCE FUSION MODE IS USED.

Am I right or I am talking bullshit?

Regards.

PS: I have to write one day the saturation histogram routine and repeat the tests.
Title: Your Curves
Post by: Mark D Segal on July 26, 2007, 08:09:50 PM
Hi Guillermo,

Glad you found the article stimulating enough to spend time testing images with your software. Your finding that hue is preserved in Luminosity Blend Mode is expected. It should also be expected that when you progress from a very wide space such as Pro Photo to a narrow one such as sRGB, colours will be clipped, and the affected pixels will therefore change hue.

But there is another variable in your workflow - conversion to JPG, which is a lossy compression format that throws away much data. It would be interesting to see what happens to hues if you had saved the files as PSD or TIFF rather than JPG, just in order to eliminate any possible influence of the JPG process on the results.

For those of us who like to see comparative results in actual images rather than (somewhat unfamiliar) histogram formulations, it would also be of interest to see the images in their "before" and "after" state, with a sampling of Hue measurements somwhat like what I attempted in the essay.

I'd be interested in your opinion about whether the measurement of hue coming from your program is any more accurate than we would get taking hue readings using the HSB read-outs in Photoshop's info palette - because as I mentioned in the article, concerns do exist about the accuracy of hue measurements in the HSB or HSV model.
Title: Your Curves
Post by: laughfta on July 27, 2007, 12:44:53 AM
Hi Guillermo,

This is  fascinating piece of work. Thanks for bringing it.  It sure is satisfying to see an exact match in data where the luminosity blend mode was used!  And really interesting to see what takes place in the Normal blend mode, as well.

Quote
S: I have to write one day the saturation histogram routine and repeat the tests.


I sure hope you post it when you do!
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 07:00:47 AM
OK I will do so, but please tell me how to take indidivual HSB samples in Photoshop, I am not a PS expert and try to use it as less as possible (did you know PS makes 15-bit edition? half of the levels in the 0..65535 range are automatically set to 0 as soon as you load a 16-bit TIFF in Photoshop).

In the last times I have become a fan of linear images and linear edition, where curves have a very straight forward interpretation.

One of the things than can easily and perfectly be done in linear using curves is exposure correction. Surely ACR performs exposure correction in linear mode.
With a line curve in Normal blending mode, exposure adjustment can be done like this:

(http://www.guillermoluijk.com/tutorial/dcraw/curvas_exp.gif)

This is consistent both with exposure theory (amount of light impacting the sensor is proportional to captured level), so as with the Hue formulas described here (http://en.wikipedia.org/wiki/HSV_color_space), where both the upper and lower parts of Hue~(G-B )/(MAX-MIN)... are scaled with the same factor keeping thus the Hue.
In fact it has to be that way as a Hue model depending on exposure would be nonsense.

Another thing that can be applied in linear mode with line-curves is White Balance, since WB is nothing but a linear scaling of three RGB channels.

(http://www.guillermoluijk.com/tutorial/dcraw/curvas_wb.gif)

These two curves for instance provide a tungsten WB (Rojo=Red, Azul=Blue, Green remains unchanged) suitable for shots under indoor lighting.
Unfortunately Bayer demosaicing algorithms are optimised to be applied on already balanced RAW data, and performing WB after Bayer interpolation leads to artifacts in the borders of differently coloured areas. So this is rather a nice didactical concept than a useful practical technique.

If you would like to practice with linear RAW developing and editing, I recommend you a fantastic freeware program called DCRAW.
Title: Your Curves
Post by: laughfta on July 27, 2007, 08:05:02 AM
Another interesting post, Guillermo!

Quote
OK I will do so, but please tell me how to take indidivual HSB samples in Photoshop


If you open the palette options, which can be reached through the arrow in the upper right corner of the info palette, you can change the mode to HSB. The eyedropper tool will show you the HSB info in the image.

The Color Sampler tool, found in the dropdown next to the eyedropper tool, will set points on your images if you alt click on the image.
Title: Your Curves
Post by: Chris_T on July 27, 2007, 09:33:01 AM
Quote
If you wish to separate luminosity from colour using curves you can create two curves adjustment layers, one in Luminosity mode and one in Color mode, then vary their opacities to taste. Or you can do what I demonstrated in the article working with a combination of Curves and HSB adjustment layers. Adobe could always add more tools, but with Photoshop having gone through 10 versions by now and given the tools it already has for achieving this objective, perhaps simplifying this separation is either not high on their list of priorities, or customer demand has not made it so, or both.

I'm doing exactly what you suggested. Create and close an unmodified curves adjustment layer, change the layer's blending mode, activate and modify the layer. Even with an action, I think this can be "simpler". In addition to curves, it would be nice to have tools that are specific for luminosity and color corrections separately.

Quote
And that of course is not unrelated to what you say about the 500+page books not exploring this issue very much; you are right - with the exceptions of Dan Margulis and Michael Kieran, most of the authors devote most of their space for Curves on showing how to adjust contrast with the composite curve and colour balance with the individual channel curves. It seems as if the saturation boost from Curves just hasn't had much traction as a big-ticket issue.

Most readers, including myself, were thrilled by the initial application of an S curve. Many look no further and think of these authors as godsends. But some, like myself, either by closer scrutiny of their work or by reading, will learn to notice the side effects. When it comes to subjective evalutaion, nothing beats having someone pointing out a problem or difference, and then comparing two edits side by side. Once I'm aware of a problem that was unnoticed before, it can stand out like a sore thumb. If more users are made aware of the same, a traction will build up. I value writers who are able and willing to disclose and educate, much like I value MDs who alert me of a prescription's side effects.

Quote
You are right about the hazards of selecting images for making demonstrations. I mentioned that twice-over and I explained the criteria for the images I used. I don't know with whom I was supposed to obtain an authoritative agreement on "baseline" images, or whether such a thing would even be an operationally fesible approach.

That said, there are some kinds of images which we know in advance would fare poorly without complex correction procedures that go beyond what we can do within a raw converter or relatively straightforward curves moves in Photoshop. I mentioned some of the more obvious ones just to make the point that no one piece of software or one approach is the be-all and end-all for every conceivable situation. The article is long enough just covering its basic intent. I could probably generate another ten pages or so demonstrating both how to select very breakable images and then proceed to break them - but who really needs that?
[a href=\"index.php?act=findpost&pid=130021\"][{POST_SNAPBACK}][/a]

My suggestion for you to include a set of images for your article is perhaps unrealistic. But I do believe for digital imaging tools evaluations and comparisons, a set of images can be really helpful. Without them, the reviews and threads on tools such as noise reduction and sharpening are without context, meaningless, misleading, and can easily lead to the next world war. I remain hopeful that someone somewhere will take the dive. It will make perfect sense for the vendor of the next tool (e.g. noise reduction or sharpening) to do so to demonstrate how his product is superior.

Digital imaging is still at its infancy, and unfortunately being dominated by a single editing product. Millions of images having been edited by a certain tool in a certain way is only a reflection of the current state of acceptance. It does not mean it is cast in stone. There was a time when the world was thought to be flat.

Off my soap box.
Title: Your Curves
Post by: digitaldog on July 27, 2007, 09:55:49 AM
Quote
When it comes to subjective evalutaion, nothing beats having someone pointing out a problem or difference, and then comparing two edits side by side. Once I'm aware of a problem that was unnoticed before, it can stand out like a sore thumb. If more users are made aware of the same, a traction will build up. I value writers who are able and willing to disclose and educate, much like I value MDs who alert me of a prescription's side effects.

Dan Margulis, as recently as yesterday continues to say his ideas about the curves in and out of Photoshop are valid, that Mark's images fail to disprove his points. Problem is, Dan refuses to supply images (raws) to prove HIS point, unlike Mark. Dan states certain images exhibit issues (damage) due to the design of CR/LR.Images with saturated reds and so forth.  In one post he called it 'sloppy math". Yet when one of us submits such images to illustrate the rendering controls are available to produce good results, such images are dismissed by Dan. So, the only alternative to get to the bottom of this is having him submit images he says are damaged by the rendering options in CR/LR.

He's not been shy in the past in providing JPEGs of supposed damage done by this or that editing move. JPEGs in this discussion are useless for obvious reasons. Despite numerous requests from many different posters, neither the spreadsheet that proves his point using 'exact math' nor a single Raw file has been submitted for what I would call fair peer review. What's he afraid of? Wouldn't showing us raws, providing the exact rendering moves in LR or CR be educational and provide proof of concept? As I said in the original post about this subject, it isn't necessary for those who may disagree with Dan to disprove his point, its up to him to prove it. That's good science. For months, many have tried to get such proof. IF it doesn't exist it makes much of what he writes highly suspicious. Show me the Raw.
Title: Your Curves
Post by: laughfta on July 27, 2007, 10:22:36 AM
I am wondering about the  difference in the histograms that Guillermo provided illustrating the difference between "normal" and "luminence" blending mode in ProPhoto RGB. These were done in PS.  
If they were produced in ACR/LR, would the hues show a shift in response to a curve adjustment?
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 11:19:11 AM
Quote
(did you know PS makes 15-bit edition? half of the levels in the 0..65535 range are automatically set to 0 as soon as you load a 16-bit TIFF in Photoshop).

In the last times I have become a fan of linear images and linear edition, where curves have a very straight forward interpretation.

One of the things than can easily and perfectly be done in linear using curves is exposure correction. Surely ACR performs exposure correction in linear mode.
With a line curve in Normal blending mode, exposure adjustment can be done like this:

[a href=\"index.php?act=findpost&pid=130098\"][{POST_SNAPBACK}][/a]

Hi Guillermo,

Actually the bit depth and number of resulting levels is even a bit more complicated than what you describe - as you most likely know. Our best Canon DSLRs, for example, capture in 12-bit depth. That gives us 2^12 or 4096 layers of "real" information. Then somehow - and I'm not sure how the "somehow" happens - this gets translated by Camera Raw into 15-bit depth, giving us 32,768 levels, but in Photoshop this is called 16 bit depth which in theory is 65536 levels - and again I'm not sure exactly how those additional 32768 levels get "filled". Whatever, 4096 levels of originating data is surely much better than the 256 to which we would be limited with 8 bit files.

I agree with you about the use of linear curves. I use them very often - I find they provide a very controlled and gentle way to edit contrast in an image - but of course they are not always sufficient - when you don't want to flatten the image too much, and you don't want to sacrifice highlight or shadow detail but you still need more contrast, that is where the various styles of S-curves, etc. become most helpful.
Title: Your Curves
Post by: digitaldog on July 27, 2007, 11:38:06 AM
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 11:41:26 AM
Quote
I'm doing exactly what you suggested. Create and close an unmodified curves adjustment layer, change the layer's blending mode, activate and modify the layer. Even with an action, I think this can be "simpler". In addition to curves, it would be nice to have tools that are specific for luminosity and color corrections separately.


My suggestion for you to include a set of images for your article is perhaps unrealistic. But I do believe for digital imaging tools evaluations and comparisons, a set of images can be really helpful.


[a href=\"index.php?act=findpost&pid=130122\"][{POST_SNAPBACK}][/a]

Chris, what you are suggesting about a specific tool for separately editing Luminosity and Color in Curves may be said to exist already in Lab space, but we have been very reliably informed that adjusting L while holding a* and b* constant still produces "chroma effects". So perhaps something else that does this with surgical precision and doesn't need several layers could be helpful to some people. As Jeff Schewe once informed us somewhere on this website, the only way to get that from Adobe would be to put in a feature request, and you need to make the case for the feature - they won't listen to an argument confined to sentiments like "it would be nice to have......", because all kinds of things would be nice to have, but the requestor needs to make a case to them about the value-added it would convey to the program relative to what it does now. This may be a challenge, but hey - one doesn't know until one trys.

Now about the images - I infer from your comment that you are thinking of some kind of standard or normative set of test images that the whole industry would adopt as a common platform for testing everything and anything - again not a bad idea in principle (something like the input to an ISO standard I suppose), but I'm glad you realize that would have been "a bit much" for Your's Truly to take-on. You know how these things happen: committees of interested parties or existing associations get appointed to develop the material.  Years of in-committee discussion and debate plus alpha and and beta testing with a host of outside experts would take place - then IF EVER a consensus were to emerge, that organization would produce the set of images for the whole world to use - voluntarily of course.  But not a bad idea in principle. As usual, the devil would be in the details.......................
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 11:52:41 AM
Quote
I am wondering about the  difference in the histograms that Guillermo provided illustrating the difference between "normal" and "luminence" blending mode in ProPhoto RGB. These were done in PS. 
If they were produced in ACR/LR, would the hues show a shift in response to a curve adjustment?
[a href=\"index.php?act=findpost&pid=130127\"][{POST_SNAPBACK}][/a]

Hi Gloria, I have taken the RAW file, and developed it using ACR and ProPhoto profile as destination, using TIFF as output file format:

1. Developed with no curve applied at all (original)
2. Developed applying curve in ACR
3. Developed applying curve in PS (Normal blending mode)
4. Developed applying curve in PS (Luminance blending mode)

And I have compared the Hue histogram in 1 (original) with 2, 3 and 4.

The curve in 2 (ACR) and the one in 3,4 (PS) are very similar, and applied over equal histograms (the background histogram shown by ACR curve editor perfectly matches that one shown by PS prior to curve application).
With this I mean that any difference in the result can be assumed to be derived from differences in the internal math processing to apply the curve.

Hue comparision original (down in all three pics) vs...
ACR curve (left) / PS Normal curve (middle) / PS Luminance curve (right)
(http://img503.imageshack.us/img503/2262/compod1.gif)  .  (http://img503.imageshack.us/img503/8183/comp3bj1.gif)  .  (http://img503.imageshack.us/img503/346/comp2nd6.gif)


This is the original image appearance with no curve or any other control applied (absolutely all ACR values set to 0, WB as in shot):

Original
(http://img503.imageshack.us/img503/1295/originalxn5.jpg)


And these are the 3 curve edited versions (ACR curve, PS Normal, PS Luminance):

ACR curve
(http://img503.imageshack.us/img503/7662/acrprophotocurveow7.jpg)

PS Normal
(http://img503.imageshack.us/img503/6311/psprophotocurvenormalkj0.jpg)

PS Luminance
(http://img503.imageshack.us/img503/5214/psprophotocurveng4.jpg)

And these are the 2 curves used:
(http://img503.imageshack.us/img503/52/curvesoh4.jpg)

I want to point that even if it seems so, the Prophoto ACR curve version is not blown. This would have surely affected to Hue.
The displayed pictures were in the last moment converted to sRGB so that you can see them as I saw them in PS ProPhoto.


Apparent conclusion: "ACR curves don't preserve Hue, and in addition to this don't work exactly as a PS Normal blending mode RGB curve. Only PS Luminance blending mode seems to preserve Hue, producing however an apparent saturation loss (or at least a feeling that this happens)." (the saturation issue is well commented in MarkDS' document).
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 12:00:32 PM
Quote
Actually the bit depth and number of resulting levels is even a bit more complicated than what you describe - as you most likely know. Our best Canon DSLRs, for example, capture in 12-bit depth. That gives us 2^12 or 4096 layers of "real" information. Then somehow - and I'm not sure how the "somehow" happens - this gets translated by Camera Raw into 15-bit depth, giving us 32,768 levels, but in Photoshop this is called 16 bit depth which in theory is 65536 levels - and again I'm not sure exactly how those additional 32768 levels get "filled". Whatever, 4096 levels of originating data is surely much better than the 256 to which we would be limited with 8 bit files.[a href=\"index.php?act=findpost&pid=130135\"][{POST_SNAPBACK}][/a]

well, I don't think ACR is actually 15 bit, I think is the PS engine who converts from true 16-bit developed RAW to 15. Not really a conversion, just a bit drop.
That is why I like to use DCRAW, as I get true 16-bit developed RAW files in their complete 0..65535 range.
The 12 bit RAW file is converted to 16 bit into any RAW developer prior to any other process stage. Then true 16-bit white balance is applied, and true 16-bit Bayer demosaicing is done. That is why a developed RAW in linear state is completely full of levels in the lower end of its histogram (no holes at all).
It's in the next step, when the colour profile conversion and gamma compensation are applied, that the lower part if the histogram gets full of holes as an Emmental cheese.

With "linear curves" I didn't mean only that they are straight lines, but also making reference to the type of image they are applied to: a LINEAR IMAGE; i.e. with no gamma compensation applied yet.
This is something that DCRAW provides and has some advantages that gamma corrected images as those coming from ACR lack, for instance the showed exposure control.
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 12:08:40 PM
Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

But what do they use that bit for? why do I have to work with half the precision, and without being told?!?.

This is what a real 16-bit TIFF histogram (zoom 1:1, maximum detail level) looks like once loaded and saved again using Photoshop. Perhaps the motto "TIFF is a losless format" should be complemented with "...unless PS gets in your way!"

Original
(http://www.guillermoluijk.com/tutorial/histogrammar/linearhis.gif)

After just Open and Save in PS
(http://www.guillermoluijk.com/tutorial/histogrammar/linearhisps.gif)
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 12:17:23 PM
Quote
"ACR curves don't preserve Hue, [a href=\"index.php?act=findpost&pid=130140\"][{POST_SNAPBACK}][/a]

Guillermo, where are the measurements that show this? This finding differs from what I usually find, and I believe it also differs from what I understand the math was developed to produce.
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 12:26:39 PM
Quote
Guillermo, where are the measurements that show this? This finding differs from what I usually find, and I believe it also differs from what I understand the math was developed to produce.
[a href=\"index.php?act=findpost&pid=130145\"][{POST_SNAPBACK}][/a]
OK I will try to pick some samples... please wait.

uffff man, what a pain. did I tell you I hate PS? but I think I managed, and I know why you got the results that ACR preserves tone. Look at these two samples, from top to bottom: ACR curve, PS Luminance blending curve and original image:

[span style=\'font-size:14pt;line-height:100%\']Dress[/span]

(http://img524.imageshack.us/img524/259/test1dv7.jpg)

where ACR doesn't seem to preserve de Hue but PS-Lum does.


[span style=\'font-size:14pt;line-height:100%\']Lips[/span]

(http://img524.imageshack.us/img524/3584/test2yo0.jpg)

still PS-Lum curves preserve the Hue well and ACR gets very close indeed.


It's funny to see saturation increases in both cases, ACR and PS Lum curves. In this last case the appearance is a saturation loss, but this does not seem true at all as in both tests saturation increased with the PS curve. And more with the ACR one.

This is a very agressive curve, and I think both ACR and PS-Lum curves preserve quite well the Hue, but looking at the histogram discrepancies, it seems that ACR does not perform as well in some tones/areas. And the lip is a good example.

What do you think?
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 01:04:07 PM
Quote
The 12 bit RAW file is converted to 16 bit into any RAW developer prior to any other process stage. Then true 16-bit white balance is applied, and true 16-bit Bayer demosaicing is done. That is why a developed RAW in linear state is completely full of levels in the lower end of its histogram (no holes at all).
It's in the next step, when the colour profile conversion and gamma compensation are applied, that the lower part if the histogram gets full of holes as an Emmental cheese.

[a href=\"index.php?act=findpost&pid=130142\"][{POST_SNAPBACK}][/a]

Guillermo: When I see an expression like "is converted to" I get uncomfortable. Sure - something is happening, but that doesn't tell me exactly what. And that leads one to wonder what exactly is meant by "true 16-bit White Balance" and "true 16-bit Bayer demosaicing". What is "true" if alot of data is being interpolated or filled with zeros - I don't know exactly what?

What you are saying here also raises questions in my mind about the order in which things happen from the time I acquire the image into the raw converter, process it, and output it to Photoshop (i.e. "render" it). Perhaps you can clarify for me. I was under the impression that the demosaicing happens the moment I acquire the image into Camera Raw - otherwise I wouldn't see a recognizable colour image. Is that right? Now is that happening in 16 bit or in 15 bit mode, and does it really matter much - practically? Now, once the image is in Camera Raw demosaiced, is it in 16-bit or in 15 bit at that moment? -  Because the next thing I'll do is White Balance; again does it matter much whether this happens as 15 or 16 bit mode? What can happen though, as I showed, is that white-balancing can affect the placement of individual channels along the histogram - even leading to clipping.

When the image gets rendered to Photoshop, I believe this is where the conversion to the colour space profile occurs, but I don't see any Emmenthal cheese in the histograms either in ACR or in PS - is this because they don't show the levels in enough detail to recognize it - which your program does? If these holes exist, do they make a visible difference in a print?

The gamma compensation (or correction) happens when? Isn't it already represented in the Camera Raw Interface so I see whatever gamma the converter gives me right there? The brightness and tonal range of the image by the time I finish with it in Camera Raw looks pretty much identical to what I see when I render it in Photoshop, so I am curious again about the sequencing of what is happening under the hood, and what practical effects that sequence may be having.
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 01:11:19 PM
Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

Andrew,

I'm having real trouble understanding this post. Grateful if you could check the phrasing and clarify it - perhaps also giving some context of what you are replying to. It is a most interesting area to be real clear about. Especially this. I work in "16-bit", but the histogram and the read-out of the curves as U.I. features still behave as if it were 8 bit - i.e. 255 levels are displayed for 16 bit files too, which you see as you read the input-output values in the Curves dialogue and watch the histogram.
Title: Your Curves
Post by: laughfta on July 27, 2007, 01:14:43 PM
That was fast  

This seems like good science to me. I sure someone will quickly point out any flaws, if they find them.

I think this information (as it presently stands)  should help people obtain strong images from ACR or PS. And will make it much easier to evaluate past and future advice about what the effect is of manipulating the master curve in both.

This is a portion of what Jeff Schewe ( on Dan's ACT forum) quoted Thomas Knoll as saying about the ACR curve:

It maps the min and max of the RGB values (in linear ProPhoto RGB) through
the tone curve, and the middle value is interpolated to exactly preserve
hue. This results in saturation effects that closely match saturation
effects you get from real film tone curves (which many years of looking at
film photos has taught our eyes to like), while preventing the adverse hue
shifts you would otherwise get from the concave and convex parts of the
curve."

I don't see a conflict here—a judgment call is ultimately called for when evaluating adverse hue shifts, which is how it should be.
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 01:15:04 PM
Quote
Guillermo: When I see an expression like "is converted to" I get uncomfortable. Sure - something is happening, but that doesn't tell me exactly what. And that leads one to wonder what exactly is meant by "true 16-bit White Balance" and "true 16-bit Bayer demosaicing". What is "true" if alot of data is being interpolated or filled with zeros - I don't know exactly what?

What you are saying here also raises questions in my mind about the order in which things happen from the time I acquire the image into the raw converter, process it, and output it to Photoshop (i.e. "render" it). Perhaps you can clarify for me. I was under the impression that the demosaicing happens the moment I acquire the image into Camera Raw - otherwise I wouldn't see a recognizable colour image. Is that right? Now is that happening in 16 bit or in 15 bit mode, and does it really matter much - practically? Now, once the image is in Camera Raw demosaiced, is it in 16-bit or in 15 bit at that moment? -  Because the next thing I'll do is White Balance; again does it matter much whether this happens as 15 or 16 bit mode? What can happen though, as I showed, is that white-balancing can affect the placement of individual channels along the histogram - even leading to clipping.

When the image gets rendered to Photoshop, I believe this is where the conversion to the colour space profile occurs, but I don't see any Emmenthal cheese in the histograms either in ACR or in PS - is this because they don't show the levels in enough detail to recognize it - which your program does? If these holes exist, do they make a visible difference in a print?

The gamma compensation (or correction) happens when? Isn't it already represented in the Camera Raw Interface so I see whatever gamma the converter gives me right there? The brightness and tonal range of the image by the time I finish with it in Camera Raw looks pretty much identical to what I see when I render it in Photoshop, so I am curious again about the sequencing of what is happening under the hood, and what practical effects that sequence may be having.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130152\")

Hey, find above the tests. They are done in PS, ProPhoto 16 bit. No conversions at all.

With true 16-bit, I mean in the complete 0..65535 range, that's all. I don't refer to the genuinity of level values.
ACR shows you a little portion of imaged demosaiced. In fact it develops a little piece of the RAW file in a fast way so user changes can be check in real time.

WB is prior to demosacing. In fact you can do it afterwards (for instance with DCRAW you can appy no WB and apply it later in PS), but it is not recommended and RAW developers always apply it first. Yes, WB can clip. In fact is a linear channel scaling. If your RAW contains a level, let's say: 4000 (12 bit), which in 16 bit becomes 64000, and you apply a WB so a multiplier of let's say 1.5 is applied: 64000*1.5=96000>65535, and hence it gets clipped to 65535.

Yes, I wrote a program to plot 16 bits histograms, find it here: [a href=\"http://www.guillermoluijk.com/software/histogrammar/index.htm]Histogrammar[/url]
It has a tutorial: Tutorial (http://www.guillermoluijk.com/tutorial/histogrammar/index.htm) but in Spanish. The holes in the Offtopic (sorry about that) 15-bit PS discussion are from a real PS 16-bit image. Those holes are only 1 level as I used a linear image with no gamma expansion applied.

The gamma compensation is probably applied in real time, as a part of the colour profile conversion (each colour profile has a standard gamma to be applied). So what I think (just guessing) ACR does is a complete RAW development, of only the portion you are currently zooming. Probably with faster and less precise algorithms than those which will be used afterwards once you press "Open".

The stages of RAW development are:
1. Black ofsset substraction
2. Conversion from 12 to 16 bits
3. WB
4. Bayer interpolation
5. Highlight recovery for those needed areas and if activated
6. Colour profile conversion, with gamma.
Title: Your Curves
Post by: digitaldog on July 27, 2007, 01:17:00 PM
Quote
Andrew,

I'm having real trouble understanding this post. Grateful if you could check the phrasing and clarify it - perhaps also giving some context of what you are replying to

Is an exact quote referring to the 15-bit versus 16-bit's used in Photoshop.
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 01:19:30 PM
Quote
That was fast  

It maps the min and max of the RGB values (in linear ProPhoto RGB) through
the tone curve, and the middle value is interpolated to exactly preserve
hue. This results in saturation effects that closely match saturation
effects you get from real film tone curves (which many years of looking at
film photos has taught our eyes to like), while preventing the adverse hue
shifts you would otherwise get from the concave and convex parts of the
curve."

I don't see a conflict here—a judgment call is ultimately called for when evaluating adverse hue shifts, which is how it should be.
[a href=\"index.php?act=findpost&pid=130157\"][{POST_SNAPBACK}][/a]

No - the judgment call is for evaluating saturation shifts, not hue shifts - they don't happen at this stage. That's what the above quote says.
Title: Your Curves
Post by: laughfta on July 27, 2007, 01:49:47 PM
Quote
No - the judgment call is for evaluating saturation shifts, not hue shifts - they don't happen at this stage. That's what the above quote says.
[a href=\"index.php?act=findpost&pid=130160\"][{POST_SNAPBACK}][/a]

Quote
while preventing the adverse hue shifts...


The way I understood/understand this is that  not all hue shifts are prevented, it is that adverse hue shifts are. And that is a judgment call. And clearly, in light of Guillermo's work, there are some hue shifts, in some areas more than others.

wrong?
Title: Your Curves
Post by: Mark D Segal on July 27, 2007, 01:53:55 PM
Quote
The way I understood/understand this is that  not all hue shifts are prevented, it is that adverse hue shifts are. And that is a judgment call. And clearly, in light of Guillermo's work, there are some hue shifts, in some areas more than others.

wrong?
[a href=\"index.php?act=findpost&pid=130164\"][{POST_SNAPBACK}][/a]

Wrong - I dunno - different understanding - for sure!  
Title: Your Curves
Post by: laughfta on July 27, 2007, 02:15:31 PM
Quote
Wrong - I dunno - different understanding - for sure! 
[a href=\"index.php?act=findpost&pid=130166\"][{POST_SNAPBACK}][/a]

Well, I'm sure it will be clarified at some point—thanks to you for posting your essay.
Title: Your Curves
Post by: RichWagner on July 27, 2007, 02:54:40 PM
Quote
With true 16-bit, I mean in the complete 0..65535 range, that's all. I don't refer to the genuinity of level values.
ACR shows you a little portion of imaged demosaiced. In fact it develops a little piece of the RAW file in a fast way so user changes can be check in real time.

...

In fact is a linear channel scaling. If your RAW contains a level, let's say: 4000 (12 bit), which in 16 bit becomes 64000,
...

and you apply a WB so a multiplier of let's say 1.5 is applied: 64000*1.5=96000>65535, and hence it gets clipped to 65535.[a href=\"index.php?act=findpost&pid=130158\"][{POST_SNAPBACK}][/a]

Nope, this is not correct.  4000 in 12-bit is still 4000 in 16-bit. The higher order bits are simply set to zeros. You can confirm this with any calculator that has a "programmer's mode" including the calculator with Mac OS X.  Multiply your 4000 x 1.5 and you get 6000, which uses a whopping 13 bits.  No clipping there.

Adobe Photoshop represents 16-bit image data as a 16-bit unsigned integer, in a form that has the binary point between bits 14 and 15, and therefore can only represent 32,769 unique levels (binary 0000000000000000 through 1000000000000000). This gives a quasi 15-bit range of 0 to 32768. It provides an unambiguous mid-point of 16384 and allows some multiply operations to be performed by bit shifting, which is computationally fast, which in the "old days" was very important for speed. It will decrease the number of levels of *true* 16-bit data by half, but this is of questionable significance.

12-bit data is 12-bit data, even if you drop it into a 15-bit or 16-bit container.

--Rich Wagner
Title: Your Curves
Post by: RichWagner on July 27, 2007, 04:32:09 PM
Quote
From a top Photoshop engineer:

The high-bit representation in Photoshop has always been "15   1" bits
(32767 (which is the total number of values that can be represented by 15
bits of precision)   1).  This requires 16 bits of data to represent is
called "16 bit".  It is not an arbitrary decision on how to display this
data, it is displaying an exact representation of the exact data Photoshop
is using, just as 0-255 is displayed for 8 bit files.
[a href=\"index.php?act=findpost&pid=130137\"][{POST_SNAPBACK}][/a]

In the "good ole' days" of CS2, you could actually set the info palette to show the 16-bit data. Now, in CS3, it appears that all high-bit data is shown in 8-bit precision in the info panel, and you can't toggle it as you could previously.

--Rich
Title: Your Curves
Post by: Guillermo Luijk on July 27, 2007, 04:32:34 PM
Quote
Nope, this is not correct.  4000 in 12-bit is still 4000 in 16-bit. The higher order bits are simply set to zeros. You can confirm this with any calculator that has a "programmer's mode" including the calculator with Mac OS X.  Multiply your 4000 x 1.5 and you get 6000, which uses a whopping 13 bits.  No clipping there.

Adobe Photoshop represents 16-bit image data as a 16-bit unsigned integer, in a form that has the binary point between bits 14 and 15, and therefore can only represent 32,769 unique levels (binary 0000000000000000 through 1000000000000000). This gives a quasi 15-bit range of 0 to 32768. It provides an unambiguous mid-point of 16384 and allows some multiply operations to be performed by bit shifting, which is computationally fast, which in the "old days" was very important for speed. It will decrease the number of levels of *true* 16-bit data by half, but this is of questionable significance.

12-bit data is 12-bit data, even if you drop it into a 15-bit or 16-bit container.

--Rich Wagner
[a href=\"index.php?act=findpost&pid=130178\"][{POST_SNAPBACK}][/a]

Rich, when converting n bit data into N bit data with N>n, two things may happen:
1. As you say, high order bits are set to zero
2. High order bits are occupied by the high order bits of the original range.

The second is the case of digital photography, where 12-bit information codified into the RAW file, is transformed first into 16 bit by setting those 12-bit as the higher 12 bits of a 16-bit dword, so the lower 4 bits are the ones set to zero (which equals to multiply by 16).
So 4095 becomes 4095*16=65520, or in binary 111111111111 becomes 1111111111110000
Actually RAW developers as DCRAW or anyone perform calculations in floating point to avoid error propagation, and the result is rounded in the end.


I didn't understand your point about Photoshop 1 bit drop, I have produced with DCRAW 16-bits images that become 15 bits in the meaning that one of every two levels is rounded to the nearest 15-bit equivalent. But I don't know the real reason for this precision lose.


This is a true RAW histogram obtained with DCRAW's -D option. That means no black offset is substracted as can be seen, no scaling and no demosaicing is done:

(http://img116.imageshack.us/img116/5449/bridgehisan0.gif)


But once the image is developed, a 16-bit file is obtained with levels filled ranging 0 to 65535 (I constantly read TIFF 16-bit images and calculate their 16-bit histograms):

(http://www.guillermoluijk.com/tutorial/histogrammar/hisclasico.gif)

(http://www.guillermoluijk.com/tutorial/histogrammar/hiszoom.gif)

(http://www.guillermoluijk.com/tutorial/histogrammar/hiszoom2.gif)
Title: Your Curves
Post by: Schewe on July 27, 2007, 05:09:21 PM
Quote
In the "good ole' days" of CS2, you could actually set the info palette to show the 16-bit data. Now, in CS3, it appears that all high-bit data is shown in 8-bit precision in the info panel, and you can't toggle it as you could previously.
[a href=\"index.php?act=findpost&pid=130189\"][{POST_SNAPBACK}][/a]

Uh, in the Info palette, see the little flyout menu by the Sampler icon? Check that flyout where you can set the readout to 8/16/32 bit with lots of other options...it's not wise to jump to conclusions...
Title: Your Curves
Post by: RichWagner on July 27, 2007, 07:43:32 PM
Quote
Uh, in the Info palette, see the little flyout menu by the Sampler icon? Check that flyout where you can set the readout to 8/16/32 bit with lots of other options...it's not wise to jump to conclusions...
[a href=\"index.php?act=findpost&pid=130196\"][{POST_SNAPBACK}][/a]

Uh, no?  Not at first, and I spent 15 minutes looking.  It's not in the Info palette options - where one would elpect to find it, and clicking on "8-bit" doesn't do it, and using "shift, option or command" like it says doesn't do it, and...  Oh, now that you told me it's there, I see that there's a 3-pixel triangle next to the eyedropper that indicates a flyout menu!  Got it!

Thanks, Jeff.

--Rich
Title: Your Curves
Post by: RichWagner on July 27, 2007, 10:07:35 PM
Quote
Rich, when converting n bit data into N bit data with N>n, two things may happen:
1. As you say, high order bits are set to zero
2. High order bits are occupied by the high order bits of the original range.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130190\")
I disagree with your Number 2... see below:
Quote
The second is the case of digital photography, where 12-bit information codified into the RAW file, is transformed first into 16 bit by setting those 12-bit as the higher 12 bits of a 16-bit dword, so the lower 4 bits are the ones set to zero (which equals to multiply by 16).
So 4095 becomes 4095*16=65520, or in binary 111111111111 becomes 1111111111110000
This is related to Endianness of the RAW file, not multiplication.  If it were due to multiplication, your raw data would range from zero (0 x 16) to 65520, and any positive offset or multiplication of the raw data would quickly overflow. (See, e.g., [a href=\"http://en.wikipedia.org/wiki/Big_endian)]http://en.wikipedia.org/wiki/Big_endian)[/url] Note that Photoshop cannot display the number you obtained above - it is out of the range that I provided earlier.

From the DNG spec:
BitsPerSample
Supported values are from 8 to 32 bits/sample. The depth must be the same for each sample if
SamplesPerPixel is not equal to 1.
If BitsPerSample is not equal to 8 or 16 or 32, then the bits must be packed into bytes using the
TIFF default FillOrder of 1 (big-endian), even if the TIFF file itself uses little-endian byte
order.

OriginalRawFileData
Description
If the DNG file was converted from a non-DNG raw file, then this tag contains the compressed
contents of that original raw file. The contents of this tag always use the big-endian byte order.
Quote
I didn't understand your point about Photoshop 1 bit drop, I have produced with DCRAW 16-bits images that become 15 bits in the meaning that one of every two levels is rounded to the nearest 15-bit equivalent. But I don't know the real reason for this precision lose.
It's because of exactly what's been stated. Photoshop uses an unsigned 16-bit integer with 15-bit precision. See, for example, Bruce Lindbloom's note: http://www.brucelindbloom.com/index.html?R...enceImages.html (http://www.brucelindbloom.com/index.html?ReferenceImages.html) or Rags Gardner's description: http://www.rags-int-inc.com/PhotoTechStuff.../AdobeMath.html (http://www.rags-int-inc.com/PhotoTechStuff/ColorCalculator/AdobeMath.html) if you don't believe me, or Andrew.
Quote
This is a true RAW histogram obtained with DCRAW's -D option. That means no black offset is substracted as can be seen, no scaling and no demosaicing is done:
Yup. Note that the data range is from zero to about 4095 - it sure doesn't go to 65k as you predicted it would.  The black offset shows that there is baseline noise - you never get zero output from the ADCs. BTW, the DNG BlackLevel and WhiteLevel tags tell you which of this data you can use - and frequently (like with my D2X), the range does not extend to 4095 - it's more like 3880. This is due mostly to sensor non-linearity.
Quote
But once the image is developed, a 16-bit file is obtained with levels filled ranging 0 to 65535 (I constantly read TIFF 16-bit images and calculate their 16-bit histograms):
Sure, DCRAW is giving full 16-bit output. You can stretch it out and scale the 12-bit as far as you want, but that's a different issue. Note that you get jagged histograms if all you do is scale (and if you look closely enough). There are a bunch of zero-valued levels in between the true data points, unlike if the data was 16-bit to begin with, like some scanners and digital backs provide (e.g., Kodak DSC Pro SLR cameras).  Iridient's Raw Developer also gives true 16-bit output.

The "rounding" that you describe occuring in Photoshop will also happen with the 16-bit reference files provided by Bruce Lindbloom if you open/save them with Photoshop. You end up with 15-bit data. That's nothing new.

Note also that Photoshop CS3 still has some math errors, but they're not related to what you describe: see Adobe Forums: http://tinyurl.com/24otay (http://tinyurl.com/24otay)

Cheers,

--Rich
Title: Your Curves
Post by: Chris_T on July 28, 2007, 08:27:46 AM
Quote
Now about the images - I infer from your comment that you are thinking of some kind of standard or normative set of test images that the whole industry would adopt as a common platform for testing everything and anything - again not a bad idea in principle (something like the input to an ISO standard I suppose), but I'm glad you realize that would have been "a bit much" for Your's Truly to take-on. You know how these things happen: committees of interested parties or existing associations get appointed to develop the material.  Years of in-committee discussion and debate plus alpha and and beta testing with a host of outside experts would take place - then IF EVER a consensus were to emerge, that organization would produce the set of images for the whole world to use - voluntarily of course.  But not a bad idea in principle. As usual, the devil would be in the details.......................
[a href=\"index.php?act=findpost&pid=130138\"][{POST_SNAPBACK}][/a]

A somewhat relevant analogy is how PCs' performance are measured with benchmarks. There are different benchmarks for measuring integers, FP, graphics, etc. Likewise, different sets of images can be used for evaluating noise reduction, sharpening, stitching tools, etc.

Long before the PC benchmarks were "standardized" by committees, vendors had been using their proprietary ones. Afterall, they need them to evaluate their own designs and make tradeoffs during the development cycle. Some vendors would then demo their products with these. More sophisticated customers would apply them to competative products, leading those vendors to create their own benchmarks. Eventually, they all come to their senses and grudgingly agree to some "standardized" benchmarks. Not perfect, but certainly a huge improvement over free for all. Design or evaluate by benchmarks are not sufficient, but certainly necessary.

Digital imaging tools can and should follow a similar path. It will take one vendor to begin with a set of images to demo his product. (If the vendor has done any testing at all, he would already have this set of images available.) Users and competitors can then challenge and revise the set. Over time, an "accepted" set of images will evolve, with or without the blessing of a committee.

To do this, a vendor does not need to be a genius, but he must have faith in his product, and the courage to demo it properly.
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 09:20:23 AM
Quote
Yup. Note that the data range is from zero to about 4095 - it sure doesn't go to 65k as you predicted it would.

No Rich, the 0 to 4095 plot is pure RAW data, non processed in any way obtained through DCRAW's special option -D, as I told you. But once developed the 12 bit range is adapted to the expanded 16 bit range, and there all developing stages take place (you can look at how this is performed in DCRAW's source code, look for the scale_colors() function, which BTW deals with floating point numbers not integers).
That is why I also showed you a 16-bit histogram ranging 0..65535, which is the one you get once the development process is done.

Find here some histogram plots from a DCRAW's developed image, in zoom 1:1 detail (i.e. every pixel column corresponds to one level in the 0..65535 range). The numbers up left and up right show you the displayed 16-bit range. These histgrams are almost completely full (no gamma has been applied yet, gamma correction generates holes in the low end of the histogram and in fact is the only true reason why holes appear in the 16-bit histogram):
- The peaks correspond to the original captured levels in the 0..4095 range, and you can see they have been scaled from their original range to take advantage of the expanded 16 bit range. The different scaling for each channel is due to the WB.
- And the remaining levels between peaks (and also in the peaks themselves) are the interpolated values generated in the demosaicing process, as they were already calculated on a 16-bit basis precision.

Last plot is a zoom out version ranging levels 0 to 24575, as you can see far beyond the 4095 limit. Last level with information in this case was 56239 in the blue channel as a result of a light underexposure (I am a really bad street photographer), but normally a few blown pixels reach 65535 in some channel.

(http://img524.imageshack.us/img524/5896/histozk9.gif)


You can check by yourself making use of Histogrammar (http://www.guillermoluijk.com/software/histogrammar/index.htm) and Histogrammar tutorial (http://www.guillermoluijk.com/tutorial/histogrammar/index.htm) on any developed file of your own.

BTW my program provides a little statistic about the analysed image, among other information. For the image above:
Filled levels:
  R: 42327 (64,6% of available)
  G: 44453 (67,8% of available)
  B: 54404 (83% of available)
Linear dynamic range:
  RGB: 56204 (86% of available), range [36..56239]
  R: 44292 (68% of available), range [36..44327]
  G: 48004 (73% of available), range [119..48122]
  B: 56182 (86% of available), range [58..56239]

However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 10:06:21 AM
Quote
Uh, in the Info palette, see the little flyout menu by the Sampler icon? Check that flyout where you can set the readout to 8/16/32 bit with lots of other options...it's not wise to jump to conclusions...
[a href=\"index.php?act=findpost&pid=130196\"][{POST_SNAPBACK}][/a]

Hi Jeff......Heavens forbid one would be foolish enough to jump to conclusions   , BUT something I've been curious about for a while - relevant - to this discussion - and you may know the answer - you're correct that one can set the histogram read-out for the ino palette to 3 different bit depths; however regardless of that setting, when you pull up a Curves adjustment layer, that dialogue box is still configured from 0 to 255, and when you place a point on a curve, each single step using an arrow key shifts the curve 1 level in the Curves Input/Output data, but some 80~120 levels (give or take) as measured with the 16 bit scale in the info palette. (And 32768/256 = 128, but there is obviously not a lock-step translation probably depending on where in the curve.)

So my question is: why don't we have  a more refined adjustment capability such that we could use the cursors to move these curves one level at a time on a 16 bit scale, hence have more control over the extent of the change with each keystroke? This would be particularly useful when correcting colour casts with the individual channel curves.
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 10:13:23 AM
Quote
So my question is: why don't we have  a more refined adjustment capability such that we could use the cursors to move these curves one level at a time on a 16 bit scale, hence have more control over the extent of the change with each keystroke? This would be particularly useful when correcting colour casts with the individual channel curves.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130249\")

hehe I wonder that many times, and I think the only answer is priorities: how many photographers/graphic designers as you and me are taking care if their curves change Hue? how many are even using curves? how much effort should Adobe put into a good curve editor, specially when there is no commercial product available with such a powerful curve editing capabilities in the market?
Lucky we are that in CS3 they finally decided to plot the image luminance histogram in the curve editor background.

I was this morning looking with great interest to a PS plugin already commented in this thread, calle Curvemeister. It provides a curve editor than can work on any mode (RGB, Lab, CMYK), without changing the real mode in which the image is codified. And that permits to expand (zoom) the curve editor windows as muchs as your screen allows to: [a href=\"http://www.curvemeister.com/]Curvemeister[/url]

BTW regarding the discusion if ACR curves modify or not the Hue of the image, what do you think? I did some more tests this morning on ACR 4.1 and again, its curves show an important Hue shift in some areas of the image.
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 10:32:10 AM
Quote
Long before the PC benchmarks were "standardized" by committees, vendors had been using their proprietary ones. Afterall, they need them to evaluate their own designs and make tradeoffs during the development cycle. Some vendors would then demo their products with these. More sophisticated customers would apply them to competative products, leading those vendors to create their own benchmarks. Eventually, they all come to their senses and grudgingly agree to some "standardized" benchmarks. Not perfect, but certainly a huge improvement over free for all. Design or evaluate by benchmarks are not sufficient, but certainly necessary.

[a href=\"index.php?act=findpost&pid=130241\"][{POST_SNAPBACK}][/a]

OK, by one process or another - there is still a process - that's all I was getting at in essence.

I should add one more point - there's no monopoly over the selection of images for running tests. The validity of the case I made in my essay does not depend on that particular set of images. I've run over a thousand through this software during the past several months and on the whole I find the results it yields very satisfactory - and so do many other users on their own images who have far more professional experience than I do. [Check-out for example Mikkel Aaland's book "Photoshop Lightroom Adventure" just published in an up-dated edition.]

In my essay, I've laid out an approach or methodology that anyone with Camera Raw 4.x or Lightroom and Photoshop could undertake with their own images and see whether or not what I've found is confirmed in their own experience. The common sense criteria are to start with raw files, do the edits in the sequence the software recommends, and push the adjustments as far as necessary to achieve the objectives intended for the image.  So have a go at it with your own images and see for yourself whether my observations are validated in your experience.
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 10:40:44 AM
Quote
OK I will try to pick some samples... please wait.

uffff man, what a pain. did I tell you I hate PS? but I think I managed, and I know why you got the results that ACR preserves tone. Look at these two samples, from top to bottom: ACR curve, PS Luminance blending curve and original image:

[span style=\'font-size:14pt;line-height:100%\']Dress[/span]

(http://img524.imageshack.us/img524/259/test1dv7.jpg)

where ACR doesn't seem to preserve de Hue but PS-Lum does.
[span style=\'font-size:14pt;line-height:100%\']Lips[/span]

(http://img524.imageshack.us/img524/3584/test2yo0.jpg)

still PS-Lum curves preserve the Hue well and ACR gets very close indeed.
It's funny to see saturation increases in both cases, ACR and PS Lum curves. In this last case the appearance is a saturation loss, but this does not seem true at all as in both tests saturation increased with the PS curve. And more with the ACR one.

This is a very agressive curve, and I think both ACR and PS-Lum curves preserve quite well the Hue, but looking at the histogram discrepancies, it seems that ACR does not perform as well in some tones/areas. And the lip is a good example.

What do you think?
[a href=\"index.php?act=findpost&pid=130147\"][{POST_SNAPBACK}][/a]

Yah - it is a pain - now you see - it takes a damn lot of time to do this stuff! One hopes it makes for educational "value-added"! Looking at your illustrations, there is a difference in procedure I think between what you're doing and what I did for making these measurements. For clarity I can explain again what I did: I do not layer the ACR adjusted image on top of a PS image. I have two sets of images for the comparison: One set is the rendered CR image before and after whatever CR adjustments. The other set is the unadjusted (except for white balance) CR image rendered in Photoshop and then adjusted with PS Curves Adjustment Layers. So I am measuring HSB shifts of the rendered images for each of those sets individually.
Title: Your Curves
Post by: RichWagner on July 28, 2007, 10:46:09 AM
Quote
However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
[a href=\"index.php?act=findpost&pid=130244\"][{POST_SNAPBACK}][/a]
And my apologies to Mark, too. This is way off-topic.  Mark wrote a great article, and it deserves further discussion.

--Rich
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 10:46:52 AM
Quote
No Rich, the 0 to 4095 plot is pure RAW data, non processed in any way obtained through DCRAW's special option -D, as I told you. But once developed the 12 bit range is adapted to the expanded 16 bit range, and there all developing stages take place (you can look at how this is performed in DCRAW's source code, look for the scale_colors() function, which BTW deals with floating point numbers not integers).

However this thread is about Curves, so I think we should not discuss this here. My apologies to MarkDS.
[a href=\"index.php?act=findpost&pid=130244\"][{POST_SNAPBACK}][/a]

Guillermo, nothing to apologize about - this is about the technical under-belly of the observations we are discussing so as far as I'm concerned it's fine and very interesting. But what I'm still struggling with - and I haven't seen a simple answer (perhaps there is no such thing) - if we start with 12 bit data and end-up with 15 or 16 bit data, what are all those intervening levels: zeros or interpolations? Because no matter what the gymnastics, there are *only* 4096 levels of original information. And secondly, what are the implications for drawing Curves or making HSB adjustments that so much of the data is zeros or interpolation?
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 11:00:25 AM
Quote
hehe I wonder that many times, and I think the only answer is priorities: how many photographers/graphic designers as you and me are taking care if their curves change Hue? how many are even using curves? how much effort should Adobe put into a good curve editor, specially when there is no commercial product available with such a powerful curve editing capabilities in the market?
Lucky we are that in CS3 they finally decided to plot the image luminance histogram in the curve editor background.

I was this morning looking with great interest to a PS plugin already commented in this thread, calle Curvemeister. It provides a curve editor than can work on any mode (RGB, Lab, CMYK), without changing the real mode in which the image is codified. And that permits to expand (zoom) the curve editor windows as muchs as your screen allows to: Curvemeister (http://www.curvemeister.com/)

BTW regarding the discusion if ACR curves modify or not the Hue of the image, what do you think? I did some more tests this morning on ACR 4.1 and again, its curves show an important Hue shift in some areas of the image.
[a href=\"index.php?act=findpost&pid=130253\"][{POST_SNAPBACK}][/a]

Guillermo,

I just saw your tests on hue shift this morning and commented with a question on the procedure. I'm not getting such discrepancies - yet - but I'm working on more stuff and if I do I'll mention it.

I'm aware of Curvemeister - looks like a neat program and it seems from various web discussions that many people use it. I downloaded a demo once but didn't get into it much. Perhaps it's worth a closer look.

On the Adobe Curves - of course priorities are always an issue for any commercial operation, but you know - Curves is at the heart of this program, probably the single most important tool in the box and I am sure used by millions. It's probably the case that very few people have twigged on the question of how many levels in 16 bit space get shifted with each tweak of the cursor. It's kind of a "fine point", but as you undoubtedly have observed yourself, especially when doing color correction on individual channel curves, there comes a point when you'd like something mid-way between one shift to the left and one to the right!
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 11:03:03 AM
Quote
And my apologies to Mark, too. This is way off-topic.  Mark wrote a great article, and it deserves further discussion.

--Rich
[a href=\"index.php?act=findpost&pid=130262\"][{POST_SNAPBACK}][/a]

Rich, thanks - much appreciated, but I think this is a good discussion - you guys are getting "under the hood" which I think is fine if it helps improve our understanding of what we observe when we use these tools.
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 11:47:55 AM
Quote
But what I'm still struggling with - and I haven't seen a simple answer (perhaps there is no such thing) - if we start with 12 bit data and end-up with 15 or 16 bit data, what are all those intervening levels: zeros or interpolations? Because no matter what the gymnastics, there are *only* 4096 levels of original information.

And secondly, what are the implications for drawing Curves or making HSB adjustments that so much of the data is zeros or interpolation?
[a href=\"index.php?act=findpost&pid=130263\"][{POST_SNAPBACK}][/a]

Luckily the answer is simple: all those thounsands of levels that "should not" be there, as the original range provides a maximimum of 4096 different levels, are just interpolated.
Look at this, it's a real histogram where each X-axis value corresponds to a value in the 0..65535 range (that is why 0..767 values are represented as the plot is 768 pixels wide):

[span style=\'font-size:8pt;line-height:100%\'](NOTE: for simplicity this is the histogram of only the blue channel.
Two blue types were used to distinguish levels according to their origin)[/span]
(http://img340.imageshack.us/img340/5681/histo2ll8.gif)

- In dark blue the captured levels are represented, i.e. those levels captured by your sensor and that were given a value chosen between only 4096 possible values. They appear now equally spaced as to arrange the original 0..4095 range into the 0..65535 range the raw developer had first to spread them along the range, i.e. multiply them by a factor. So between each pair of captured values a lot of zeroes appeared at the first stage but...
- We only know (RGBG Bayer matrix) one of every three values we need to complete the image information, so we need to interpolate the unknown values. And it's after applying this interpolation algorithm to find out the unknown information when all levels until now set to zero in the histogram get filled with interpolated values, presented in cyan blue.


I will show you a numerical example of the process: imagine that you have one pixel with a captured value B=4000. Next to it a pixel of unknown B value according to the Bayer matrix so we will have to interpolate it. And the the third pixel has a value B=4001.

4000,???,4001

If we would represent the histogram at this point, a continuous histogram in the 0..4095 range would appear.

They are 12 bit numbers in the 0..4095 range, ok? now we are going to develop that RAW file. First we scale the RAW data from 12 bit to 16 bit range, i.e. multiply by 2^4=16.
4000*16 -> 64000
4001*16 -> 64016

Our image becomes now

64000,???,64016

If we would represent the histogram at this point, a non continuous histogram in the 0..65535 range would appear, with equally spaced levels separated by 15 zeros in the spaces between.

Now we apply the interpolation algorithm: to calculate the middle pixel blue value we work out the mean: (64000+64016)/2=64008

The final image is:

64000,64008,64016

Repeating the interpolation process for all unknown pixels, statistically all zeroes will be filled with some values so a continuous histogram in the 0..65535 range would appear, but showing peaks (captured) and valleys (interpolated).


Is that clear now?


______________________

regarding the application of curves to the interpolated data, is no problem at all. The editing tools that you may use will not distinguish which is the origin of a given value, they will simply have a bunch of pixels with 3 RGB values each, and operate them without caring about their origin.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
Title: Your Curves
Post by: laughfta on July 28, 2007, 12:13:14 PM
(from post # 43)

Quote
It's funny to see saturation increases in both cases, ACR and PS Lum curves. In this last case the appearance is a saturation loss, but this does not seem true at all as in both tests saturation increased with the PS curve. And more with the ACR one.

What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 12:39:00 PM
Quote
(from post # 43)
What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
[a href=\"index.php?act=findpost&pid=130300\"][{POST_SNAPBACK}][/a]

Gloria, from Bruce Fraser, here are some definitions:

<<Hue: The property of a color that is identified by a color name, such as "red," "green," or "blue." Used as a primary in the HSB (Hue, Saturation, Brightness) color model.

<<Saturation: The property of a color that makes it appear strongly colored. Black, white, and gray have no saturation. A red tomato has high saturation. Pastel colors have low saturation. Also known as Chroma. (This attribute of color is used in the HLS (Hue, Lightness, Saturation) and HSB (Hue, Saturation, Brightness) color models. >>

What we've observed (to varying extent between Guillermo and me) is that curves have much more impact on saturation than they do on hue, but this is how the authors of the program intended it to be. More often than not you will find that if you pump the contrast on an image using Curves in Luminosity Blend Mode, the hue may change little or not at all, but the result looks *crappy* because you inherently expect more saturation than you are getting. That's why the curves were designed that way - but you do have the choice, using Blend Modes in Photoshop, or Vibrance and the HSL panel in ACR 4.x or Lightroom.
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 12:43:35 PM
Quote
Repeating the interpolation process for all unknown pixels, statistically all zeroes will be filled with some values so a continuous histogram in the 0..65535 range would appear, but showing peaks (captured) and valleys (interpolated).
Is that clear now?
______________________

regarding the application of curves to the interpolated data, is no problem at all. The editing tools that you may use will not distinguish which is the origin of a given value, they will simply have a bunch of pixels with 3 RGB values each, and operate them without caring about their origin.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

Thanks very much Guillermo.
Title: Your Curves
Post by: bjanes on July 28, 2007, 12:52:17 PM
Quote
Luckily the answer is simple: all those thounsands of levels that "should not" be there, as the original range provides a maximimum of 4096 different levels, are just interpolated.

The fact that the original image was only 4096 possible levels but the interpolated values are 65536 possible levels, adds a lot of tone richness to our image that will resist now stronger processings thanks to the new set of possible values provided by the interpolation.
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

Bill
Title: Your Curves
Post by: RichWagner on July 28, 2007, 12:59:53 PM
Quote
...
They are 12 bit numbers in the 0..4095 range, ok? now we are going to develop that RAW file. First we scale the RAW data from 12 bit to 16 bit range, i.e. multiply by 2^4=16.
4000*16 -> 64000
4001*16 -> 64016
[a href=\"index.php?act=findpost&pid=130288\"][{POST_SNAPBACK}][/a]

I've re-read our posts, and it looks like we've been talking past each other. I agree with what you've stated above. To expand on it, a 12-bit number can be stored in a 16-bit word, and it will be the "same" 12-bit number (unless it's bit-packed).  That number can be scaled to the full 16-bit range, in this case by multiplying by 16 (2^4). A 14-bit number would be scaled by multiplying by 4 (2^2). This will give a 16-bit range, albeit with "holes" of 16 (or 8) between the values.

CR likely does the initial math this way (and subsequently in FP), but it does not save "16-bit files" as simple unsigned integers in the range 0..65,535.  For perhaps historic reasons, 16-bit files are saved in the 15+1 format described earlier. This format (at least at one time) gave significant processing speed advantages, particularly for blends. If an image pixel ranges from [0 ... 32768], and you multiply image pixels (as in a blending mode) you get a maximum value of 32768x32768. This still fits in a 32bit signed integer. A really fast bit-shift operation can be used instead of a very slow division to bring this value back to the image pixel range. At least that's how the story goes.

I'm not sure if CR scales to 16-bit, or to 15-bit, but I would assume 16-bit, since some cameras now produce 16-bit data files. Either way, one significant bit's worth of data is eventually lost when the image is saved (or at least when opened in Photoshop).  I haven't checked the range of data in CR-generated RAW files - is it 15-bit, or 16-bit?

And now back to curves...

--Rich
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 01:00:02 PM
Quote
(from post # 43)
What, then, makes an image look saturated? This must be related to hue, but clearly I don't understand the relationship. I think I need to go back to something very basic: what is Saturation, how does it relate to Hue?

I sorry to be interrupting on a more mundane level, but it would help me understand some points made in the curve essay. (Page 17)
[a href=\"index.php?act=findpost&pid=130300\"][{POST_SNAPBACK}][/a]

Good point.

Mathematically speaking, Hue, Saturation and Brightness are three independent variables (you can set the value of one of them independently of the value set for the other two).
But one thing is mathematics, and another (usually more important) is perception.

I have been doing some tests and reached the following conclusion of what happens to Saturation when applying a curve in PS Luminance mode (I take this as a reference as until now seems to me the only one that really preserves Hue).
The curves used are a contrast S curve, so dark areas of the image get even darker, and lighted areas get brighter, and an opposite inverted S de-contrast curve.

1. What really happens (I have tested some pixels with your loved probes Mark lol):
- Hue is preserved in all pixels
- Saturation is reduced in those pixels where Bright is increased
- Saturation is increased in those pixels where Bright is reduced


2. What you perceive when looking at the picture:
- There seems to have been an overall saturation loss, but I am looking at the images together again now, and I don't think it is too noticeable, what do you think?

Original
(http://img503.imageshack.us/img503/1295/originalxn5.jpg)


PS Luminance
(http://img503.imageshack.us/img503/5214/psprophotocurveng4.jpg)

Curve on the right was used:
(http://img503.imageshack.us/img503/52/curvesoh4.jpg)


My 2 hypothesis why they could do this:

1. Keep saturation when increasing bright may lead to clipping, that is why saturation is reduced in the pixels where the curve increases Bright. To compensate the overall effect, saturation is increased in the pixels where our curve is applying Bright reduction.

2. Human eye behaviour: since it is more difficult to recognize colours in dark areas than bright ones, saturation is increased in pixels that get darker, and reduced in the ones getting brighter.
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 01:02:15 PM
Quote
Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

Bill
[a href=\"index.php?act=findpost&pid=130308\"][{POST_SNAPBACK}][/a]

You are totally right Bill, we don't GAIN INFORMATION, just GAIN TONE VARIETY. It's the same as when you add noise to avoid banding or posterization. You add no information; in fact you destroy it. But your image gains processing robustness.
This is what I wanted to point, perhaps didn't choose the right words.
Title: Your Curves
Post by: Guillermo Luijk on July 28, 2007, 01:07:51 PM
Quote
For perhaps historic reasons, 16-bit files are saved in the 15+1 format described earlier. This format (at least at one time) gave significant processing speed advantages, particularly for blends. If an image pixel ranges from [0 ... 32768], and you multiply image pixels (as in a blending mode) you get a maximum value of 32768x32768. This still fits in a 32bit signed integer.

OK so we agree now. Yes, I guessed some speed reasons for using just 15 bits in PS, but the true is that Adobe give little or no documentation about this fact.
DCRAW really outputs 16-bit files in the total range. That is why I posted the following example:

16-bit TIFF file output from DCRAW:

(http://www.guillermoluijk.com/tutorial/histogrammar/linearhis.gif)


Now we load it in PS, and press Save.

(http://www.guillermoluijk.com/tutorial/histogrammar/linearhisps.gif)


Adobe has stolen half of my levels!!!!!!!!! wasn't TIFF a losless format?
Title: Your Curves
Post by: RichWagner on July 28, 2007, 01:09:32 PM
Quote
Guillermo,

Your demonstration is brilliant: the levels are filled in by interpolation. However, if we start out with 4096 values I find it difficult to believe that we are actually gaining any information by the interpolation. As with any interpolation, we are merely filling in missing values with estimates. By way of an analogy, if I have a 6 MB file and upres it to 24 MB I don't really have 24 MB of resolution.

Bill
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130308\")

Without interpolation, you wouldn't have a complete set of R,G,B values for every pixel.

Rather than scaling the data to 16-bit and doing the interpolation with integer math, the interpolation could also be done in floating point, but regardless, the data has to be interpolated.  Either way,  you're "gaining" a complete set of RGB data for your 6 MB file.  

As a last comment on this, the choice of interpolation algorithm heavily influences the quality of the rendered image. For a good intro, see:
[a href=\"http://scien.stanford.edu/class/psych221/projects/99/tingchen/index.htm]http://scien.stanford.edu/class/psych221/p...gchen/index.htm[/url]
http://web.cecs.pdx.edu/~cklin/demosaic/ (http://web.cecs.pdx.edu/~cklin/demosaic/)

Many of the algorithms in use are proprietary.

--Rich
Title: Your Curves
Post by: bjanes on July 28, 2007, 02:15:51 PM
Quote
Without interpolation, you wouldn't have a complete set of R,G,B values for every pixel.

Rather than scaling the data to 16-bit and doing the interpolation with integer math, the interpolation could also be done in floating point, but regardless, the data has to be interpolated.  Either way,  you're "gaining" a complete set of RGB data for your 6 MB file. 

As a last comment on this, the choice of interpolation algorithm heavily influences the quality of the rendered image. For a good intro, see:
http://scien.stanford.edu/class/psych221/p...gchen/index.htm (http://scien.stanford.edu/class/psych221/projects/99/tingchen/index.htm)
http://web.cecs.pdx.edu/~cklin/demosaic/ (http://web.cecs.pdx.edu/~cklin/demosaic/)

Many of the algorithms in use are proprietary.

--Rich
[a href=\"index.php?act=findpost&pid=130316\"][{POST_SNAPBACK}][/a]

Obviously, demosaicing is necessary to have a complete color image, but that is not to say that a 6 MB raw file demosaiced to an 18 MB RGB file would be equal in quality to an 18 MB file with true values for all sites, such as from a super Foveon chip. I'm certain that we are losing both spatial and color information.

Bill
Title: Your Curves
Post by: RichWagner on July 28, 2007, 02:31:08 PM
Quote
Obviously, demosaicing is necessary to have a complete color image, but that is not to say that a 6 MB raw file demosaiced to an 18 MB RGB file would be equal in quality to an 18 MB file with true values for all sites, such as from a super Foveon chip. I'm certain that we are losing both spatial and color information.

Bill
[a href=\"index.php?act=findpost&pid=130328\"][{POST_SNAPBACK}][/a]

Certainly, Bill, but that's the trade-off of a CFA chip design. Foveon has its own problems, as do scanning backs like the BetterLight. But I think we all agree - you have to interpolate a RAW file whose data is in a CFA pattern. To go back to your question, what we are gaining by interpolation is the complete RGB data set. That's the only reason it is done.

Rich
Title: Your Curves
Post by: Mark D Segal on July 28, 2007, 04:13:43 PM
Quote
Good point.

..............what do you think?

1. Keep saturation when increasing bright may lead to clipping, that is why saturation is reduced in the pixels where the curve increases Bright. To compensate the overall effect, saturation is increased in the pixels where our curve is applying Bright reduction.

2. Human eye behaviour: since it is more difficult to recognize colours in dark areas than bright ones, saturation is increased in pixels that get darker, and reduced in the ones getting brighter.
[a href=\"index.php?act=findpost&pid=130312\"][{POST_SNAPBACK}][/a]

Guillermo, something strange is going on - of course you have the curve in Luminosity mode which may be producing an opposite effect from what happens in Normal Mode, but in Normal mode the normal expectation is that saturation of the brighter colours increases with increasing contrast. When time permits I should try some saturation measurements before and after a curve shift in Luminosity mode to see whether I replicate your results.
Title: Your Curves
Post by: laughfta on July 29, 2007, 08:12:57 AM
Quote
here seems to have been an overall saturation loss, but I am looking at the images together again now, and I don't think it is too noticeable, what do you think?

(from post #75)

First, Guillermo, thanks for your illustrated response!  Well, I think the corrected image looks less saturated. Mark (thank you Mark) cited Bruse Fraser in response to my question about saturation:

Quote
<<Saturation: The property of a color that makes it appear strongly colored. Black, white, and gray have no saturation. A red tomato has high saturation. Pastel colors have low saturation. Also known as Chroma. (This attribute of color is used in the HLS (Hue, Lightness, Saturation) and HSB (Hue, Saturation, Brightness) color models. >>


For example, the blue shirts/sweaters behind the woman in the red dress both look less saturated to me. Is this just a function of their being brighter? If they were mesured with the eyedropper, I certainly hope they wouldn't show up as more saturated in the second image. But now I don't know, thus am questioning my understanding of saturation.

Do you base it on your perception, or a color sampler reading?
Upon closer examination, the sample you took from the lip, Guillermo, even appears (by my eye) to become slghtly more saturated in your target area. I hope this is the case. It would explain a lot
Title: Your Curves
Post by: laughfta on July 29, 2007, 08:26:11 AM
Quote
What we've observed (to varying extent between Guillermo and me) is that curves have much more impact on saturation than they do on hue, but this is how the authors of the program intended it to be.


Thank you, Mark. My lingering question is what does a curve do to a bunch of pixels to make them "saturated"? It seems that lightening pixels makes them less saturated, darkening them makes them more saturated. Lightening and darkening can be seen in a histogram; where do you see saturation? What is the color sampler tool actually reading?

Does hue impact this in any way?
Title: Your Curves
Post by: Guillermo Luijk on July 29, 2007, 08:50:19 AM
Quote
(from post #75)

First, Guillermo, thanks for your illustrated response!  Well, I think the corrected image looks less saturated. Mark (thank you Mark) cited Bruse Fraser in response to my question about saturation:
For example, the blue shirts/sweaters behind the woman in the red dress both look less saturated to me. Is this just a function of their being brighter? If they were mesured with the eyedropper, I certainly hope they wouldn't show up as more saturated in the second image. But now I don't know, thus am questioning my understanding of saturation.

Do you base it on your perception, or a color sampler reading?
Upon closer examination, the sample you took from the lip, Guillermo, even appears (by my eye) to become slghtly more saturated in your target area. I hope this is the case. It would explain a lot
[a href=\"index.php?act=findpost&pid=130396\"][{POST_SNAPBACK}][/a]

Gloria, the lips get lighter, and less saturated. I showed you the values in the info palette:

(http://img524.imageshack.us/img524/3584/test2yo0.jpg)

Look at the 'S' value, is Saturation.
Original: 23%
PS curves Lum mode: 15%
ACR curves: 12%

Both curves mean desaturation on those areas affected by a bright increase.

Regarding the blue T-Shirt, I have checked with the eyedropper (all checks I do in this thread I am using it): and we have both, Saturation increase (in the dark parts, that get darker because of the curve) and reduction (in the light areas, that get lighter because of the curve):

(http://img165.imageshack.us/img165/3994/bluetestssr0.jpg)

Probe 1 (dark blue area):
Original S: 29%
PS curves Lum mode S: 32%
ACR curves S: 53%

Probe 2 (light blue area):
Original S: 31%
PS curves Lum mode S: 23%
ACR curves S: 27%


Your understanding of saturation is right, I think simply saturation is much more noticeable in bright areas than in dark ones, so the saturation correction in the brigter areas will provide the final overall saturation perception.
As increasing contrast means increase bright in brighter areas, and this means reduce saturation on them, you have a feeling of an overall saturation loss.

This is just my hypothesis, I am investigating at the same time as you all.

Regards.
Title: Your Curves
Post by: laughfta on July 29, 2007, 09:24:30 AM
Quote
Gloria, the lips get lighter, and less saturated. I showed you the values in the info palette:

Of course. Sorry, Guillermo, I was looking at a printout of the thread, and got them turned around. Now the logic is once more in place.

In my previous post, the quote from Bruce Fraser didn't show up:

Quote
<Saturation: The property of a color that makes it appear strongly colored. Black, white, and gray have no saturation. A red tomato has high saturation. Pastel colors have low saturation. Also known as Chroma. (This attribute of color is used in the HLS (Hue, Lightness, Saturation) and HSB (Hue, Saturation, Brightness) color models. >>


Thanks again.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 10:23:28 AM
Quote
(from post #75)

For example, the blue shirts/sweaters behind the woman in the red dress both look less saturated to me. Is this just a function of their being brighter? If they were mesured with the eyedropper, I certainly hope they wouldn't show up as more saturated in the second image. But now I don't know, thus am questioning my understanding of saturation.

Do you base it on your perception, or a color sampler reading?
Upon closer examination, the sample you took from the lip, Guillermo, even appears (by my eye) to become slghtly more saturated in your target area. I hope this is the case. It would explain a lot
[a href=\"index.php?act=findpost&pid=130396\"][{POST_SNAPBACK}][/a]

Gloria, thinking about saturation and brightness, I believe we can be fooled trying to distinguish them unaided by measurements. For example, it is well known that if you add Black to any other colour, it will make that colour look "stronger". Is this because the colour has become darker or because it has become more saturated? I think the former, but we often think that stronger-looking colours are more saturated. Formally however, colours gain saturation as they extend from the center to the edge of a colour wheel or gamut frame.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 10:39:59 AM
Quote
Thank you, Mark. My lingering question is what does a curve do to a bunch of pixels to make them "saturated"? It seems that lightening pixels makes them less saturated, darkening them makes them more saturated. Lightening and darkening can be seen in a histogram; where do you see saturation? What is the color sampler tool actually reading?

Does hue impact this in any way?
[a href=\"index.php?act=findpost&pid=130399\"][{POST_SNAPBACK}][/a]

The fact is you don't see saturation in a histogram. A histogram is a representation of brightness levels either in aggregate or for each channel of the colour space being represented.

When we manipulate a tone curve we are remapping the relationships between lighter and darker pixels. The answer to your lingering question is that by design, saturation is adjusted to match with contrast changes because the developers' evaluation of working these contrast adjustments purely in luminosity mode, where constrast and saturation are not moving in sync, causes the results to look odd.

The colour sampler tool reads what you instruct it to read when you select your options for the read-out of the Info Palette. The tool itself has options to read 1 pixel, or averaged grids of 3*3 or 5*5 pixels. I normally leave mine set to 5*5, because I fear a 1 pixel read-out can be misleading if that one pixel is somehow not representative of the normally visible tone we are trying to understand through the measurement.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 10:48:09 AM
Quote
Your understanding of saturation is right, I think simply saturation is much more noticeable in bright areas than in dark ones, so the saturation correction in the brigter areas will provide the final overall saturation perception.
As increasing contrast means increase bright in brighter areas, and this means reduce saturation on them, you have a feeling of an overall saturation loss.

This is just my hypothesis, I am investigating at the same time as you all.

Regards.
[a href=\"index.php?act=findpost&pid=130403\"][{POST_SNAPBACK}][/a]

Guillermo, we aren't converged on this matter yet. If you go back to my paper and look at the results in Figure 26 reported for the readings done on Figures 24 and 25, you will see that brightness and saturation are positively correlated - not to the same extent for each sample, but same positive direction of association nonetheless. You seem to be getting negative correlation, so there is something different going on here that I don't understand. One thing I do understand, however, is that the results I got do reflect what I am given to understand the program writers intended to achieve.
Title: Your Curves
Post by: Guillermo Luijk on July 29, 2007, 12:29:57 PM
Quote
Guillermo, we aren't converged on this matter yet. If you go back to my paper and look at the results in Figure 26 reported for the readings done on Figures 24 and 25, you will see that brightness and saturation are positively correlated - not to the same extent for each sample, but same positive direction of association nonetheless. You seem to be getting negative correlation, so there is something different going on here that I don't understand. One thing I do understand, however, is that the results I got do reflect what I am given to understand the program writers intended to achieve.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130422\")

Yes, this bright up-saturation down & bright down-saturation up trend is found only in curves in PS with blending mode Luminance. In ACR and Normal blending mode curves, saturation simply increases at every pixel.

I have uploaded a cut of the flag in the sample picture, with 2 probes:
- Probe 1 located at a point where curves increases bright (all curves but PS Lum increase saturation, PS Lum reduces saturation).
(H, S, B ) values:
Original=(50º, 64%, 63%)
PS Lum cur=(50º, 48%, 84%)
PS Norm cur=(58º, 95%, 86%)
ACR cur=(52º, 100%, 95%)

- Probe 2 located at a point where curve reduces bright (all curves increase saturation).
(H, S, B ) values:
Original=(50º, 60%, 34%)
PS Lum cur=(50º, 97%, 21%)
PS Norm cur=(33º, 93%, 26%)
ACR cur=(53º, 100%, 21%)

Please download a portion of the flag picture from: [a href=\"http://www.guillermoluijk.com/download/flag_cut.zip]Sample image[/url]

(http://img214.imageshack.us/img214/7937/probesaa9.jpg)
Title: Your Curves
Post by: PeterLange on July 29, 2007, 12:30:37 PM
Mark wrote
>> No math here – I wouldn’t know where to start.<<

If of interest:

One simplified approach is to look at RGB curves is in terms of adjacent tangents – means to approximate a curve section by section by a straight line which represents the “local” slope and offset.  As common with linear equations, the term Offset refers to the crossing point of a straight line with the vertical “y” axis:

Slope > 1: increase of contrast
Slope < 1: decrease of contrast
Offset > 0: decrease of HSB-Saturation
Offset < 0: increase of HSB-Saturation
---

RGB-Levels’-whitepoint setting
or a respective "curve" which is already a straight line,
or +EV with the Exposure slider in ACR (from an empirical point of view):

Slope > 1: increase of contrast (difference between lighter and darker pixel)
Offset = 0: Color integrity is perfectly maintained. Linear scaling of RGB data does not change the intensity ratios of R:G:B per pixel, which is synonymous to unchanged HSB hue & saturation.
---

RGB-Levels’-blackpoint setting
or a respective "curve" which is already a straight line,
or the Shadows slider in ACR:

Slope > 1: increase of contrast
Offset < 0: increase of HSB-Saturation, mainly for the shadows with decreasing significance towards the highlights.

Note that the saturation boost and damage of color integrity is the more severe the higher the underlying gamma of the working space is: http://www.c-f-systems.com/Docs/ColorIntegrityCFS-243.pdf (http://www.c-f-systems.com/Docs/ColorIntegrityCFS-243.pdf)
---

Increasing brightness w/the RGB-Levels’-midtone slider,
or a respective solely right-curved curve
or the Brightness slider in ACR:

From the shadows to the mids:
Slope > 1: increase of contrast
Offset > 0: decrease of HSB-Saturation

From the mids to the highlights:
Slope < 1: decrease of contrast
Offset > 0: decrease of HSB-Saturation
---

Reducing brightness w/the RGB-Levels’-midtone slider,
or a respective solely left-curved curve:

From the shadows to the mids:
Slope < 1: decrease of contrast
Offset < 0: increase of HSB-Saturation

From the mids to the highlights:
Slope > 1: increase of contrast
Offset < 0: increase of HSB-Saturation
---

Before addressing more complex sigmoidal curves, it should be mentioned that analogous Lab lightness settings or changing to Luminosity blend mode are by far NOT always superior. It depends.

Peter

--
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 01:02:51 PM
Quote
Yes, this bright up-saturation down & bright down-saturation up trend is found only in curves in PS with blending mode Luminance. In ACR and Normal blending mode curves, saturation simply increases at every pixel.
[a href=\"index.php?act=findpost&pid=130436\"][{POST_SNAPBACK}][/a]

OK, that's a relief. You've just saved me some time.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 01:09:41 PM
Quote
Mark wrote
>> No math here – I wouldn’t know where to start.<<.
If of interest:.....................................

............................................
Before addressing more complex sigmoidal curves, it should be mentioned that analogous Lab lightness settings or changing to Luminosity blend mode are by far NOT always superior. It depends.

Peter

--
[a href=\"index.php?act=findpost&pid=130437\"][{POST_SNAPBACK}][/a]

Peter, thanks for all that and for the reference document. I have downloaded it.
Title: Your Curves
Post by: laughfta on July 29, 2007, 01:14:19 PM
Quote
Yes, this bright up-saturation down & bright down-saturation up trend is found only in curves in PS with blending mode Luminance. In ACR and Normal blending mode curves, saturation simply increases at every pixel.


Well...
It is also found if a point is raised or lowered without added contrast—I downloaded your flag file, Guillermo, turned off the curve layer and added a new curve layer. I Control clicked on your yellow target, and used the arrow key to lighten the resulting point on the curve. When checked, the saturation was lower on the lightened image.

I could do this with the target adjustment tool in LR, as well. I don't have CS3, so I have to export from LR into PS2. Nevertheless, I got the same result; less saturation.

From Mark:
Quote
The answer to your lingering question is that by design, saturation is adjusted to match with contrast changes because the developers' evaluation of working these contrast adjustments purely in luminosity mode, where constrast and saturation are not moving in sync, causes the results to look odd.


From Dan:
Quote
When one lightens an image in CR, saturation increases. The operator can not modify or turn off this effect."


Sounds like when CR dynamic range adjustments are used as they are meant to be used they add contrast, and increase saturation. It appears to me that the operator can modify this effect, but not turn it off.

Is this accurate?
Title: Your Curves
Post by: Guillermo Luijk on July 29, 2007, 01:33:14 PM
Oops, I am talking about the picture with the flag, and I have just realised I used it in another forum. I show you here the results with that picture, which confirm all we are discussing:

Original
(http://img341.imageshack.us/img341/219/cucuoriginaluh6.jpg)

Result of applying curve in ACR / Result of applying curve in PS (Luminosity blending mode)

(http://img341.imageshack.us/img341/9962/cucucurvaacrcx5.jpg)  .  (http://img341.imageshack.us/img341/6366/cucucurvapslumdp6.jpg)

Curves:
(http://img503.imageshack.us/img503/52/curvesoh4.jpg)

Comparision of tone histograms (animated GIFs: 'original' corresponds to the Original image):

Original vs curve in ACR / Original vs curve in PS (Luminosity blending mode)
(http://img442.imageshack.us/img442/6669/compcurvaacranimdd2.gif)  .  (http://img442.imageshack.us/img442/2607/compcurvapslumanimqb7.gif)

ACR generates new blue tones that did not exist in the original image.
On the other hand PS Luminosity curves accurately replicate tones in such a way that is really difficult to find the differences (look closely at some blinking pixels in the histogram).
Title: Your Curves
Post by: Schewe on July 29, 2007, 02:51:44 PM
Personally, the Luminance Curve image looks dead to me...
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 03:28:28 PM
Quote
Personally, the Luminance Curve image looks dead to me...
[a href=\"index.php?act=findpost&pid=130470\"][{POST_SNAPBACK}][/a]

Of course it does - that's exactly what Thomas said would happen (and I saw it over and over again as I played with the images for my essay), so they developed the synchronous adjustment of contrast and saturation.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 03:31:18 PM
Quote
ACR generates new blue tones that did not exist in the original image.
On the other hand PS Luminosity curves accurately replicate tones in such a way that is really difficult to find the differences (look closely at some blinking pixels in the histogram).
[a href=\"index.php?act=findpost&pid=130455\"][{POST_SNAPBACK}][/a]

Guillermo, it would surprise me if CR were generating "new blue tones" (whatever that means) that didn;t exist before. For sure it generates much more saturated blue given the hugely pronounced S curve you put into that rendition, and the brightnesses will be very different, so yes it can look like "new blue" but is it really? - have the hue values shifted at all or by more than a couple of degrees?
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 03:40:58 PM
Quote
From Dan:

Sounds like when CR dynamic range adjustments are used as they are meant to be used they add contrast, and increase saturation. It appears to me that the operator can modify this effect, but not turn it off.

Is this accurate?
[a href=\"index.php?act=findpost&pid=130450\"][{POST_SNAPBACK}][/a]

Firstly, what does Dan mean when he says "when dynamic range adjustments are used as they are meant to be used" - they are meant to be used in any way you the user wants to use them to achieve whatever effects you think the image needs. This may be to increase contrast, but there are times when one may wish to downplay contrast. So the quote starts out being a bit vague. That's a quibble. Let's assume he means increasing contrast. I believe he is correct that the effect can be modified but not "turned off". There are at least three ways to modify it:

(1) reduce Vibrance, (2) reduce Saturation, (3) in the HSL tab alter the luminance and/or saturation of specific colour ranges that may be problematic. Because all this is happening simultaneously in meta-data before rendering it should be non-destructive, and more often than not it should give you the result you want, or very close thereto. This is where we want to end-up isn't it? If we get there, does it matter whether the effect can be "turned-off" or not? I would think not; at the same time however, I can see some merit to the idea of a pure luminance-based contrast tool in CR. That said, not clear to me how much priority Adobe would assign to its development given the other ways available there to do the needful.
Title: Your Curves
Post by: digitaldog on July 29, 2007, 03:42:34 PM
Quote
Of course it does - that's exactly what Thomas said would happen (and I saw it over and over again as I played with the images for my essay), so they developed the synchronous adjustment of contrast and saturation.

I read it's all sloppy math. That the product isn't suitable for professional users. Are you suggesting that the guys who wrote the math and looked at the final color appearance (that historically have pleased its users) are right?
Title: Your Curves
Post by: RichWagner on July 29, 2007, 03:44:39 PM
Quote
Personally, the Luminance Curve image looks dead to me...
[a href=\"index.php?act=findpost&pid=130470\"][{POST_SNAPBACK}][/a]
Well, the shot on the left was by Jay Maisel, and the shot on the right... no, wait a minute...
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 04:11:25 PM
Quote
I read it's all sloppy math. That the product isn't suitable for professional users. Are you suggesting that the guys who wrote the math and looked at the final color appearance (that historically have pleased its users) are right?
[a href=\"index.php?act=findpost&pid=130485\"][{POST_SNAPBACK}][/a]

Go to my article and look at Figure 20. Would you want such a sick-looking cat? Now I'm just working up some citrus to further test this business about how CR can handle images with a very bright predominant colour and you should see what those oranges and grapefruits look like in luminosity mode - yuch - the Citrus Growers would sack that photographer!

OK, I happen to think Thomas and Co. got it right. And they also got it right by providing a Luminosity Mode. Like everything in Photoshop as we all know, there are alternative ways to get what we want. I showed a few in the article. Another approach is to layer a Normal curve on a Luminosity curve and adjust opacities till one has the "right" contrast and saturation. But that's a bit trickier.
Title: Your Curves
Post by: laughfta on July 29, 2007, 04:32:27 PM
Not quibbling here, but Dan didn't say that, I did. Dan's quote is in a quote box.

Quote
If we get there, does it matter whether the effect can be "turned-off" or not? I would think not; at the same time however, I can see some merit to the idea of a pure luminance-based contrast tool in CR.


Nope, I don't think it matters. However, the more understanding of how these tools work, the better one can use them. And we can't learn or when to use them if they can't be discussed.

For example, if the "hue locking" curve allows a (mild or not) shift in hue, isn't that worth knowing?  

If every curve you pull on the ACR/LR curve affects saturation, shouldn't we also know that?

I've learned a lot the last few days. Guillermo, thanks for all those visuals, and the info. Peter, I'm going to go study your chart. Thanks.

Mark, great effort but the Twins are back, so...discussion is over.
Title: Your Curves
Post by: Guillermo Luijk on July 29, 2007, 04:35:12 PM
Quote
Guillermo, it would surprise me if CR were generating "new blue tones" (whatever that means) that didn;t exist before. For sure it generates much more saturated blue given the hugely pronounced S curve you put into that rendition, and the brightnesses will be very different, so yes it can look like "new blue" but is it really? - have the hue values shifted at all or by more than a couple of degrees?
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130479\")

No no Mark, believe me, actual NEW blues appear. The X axis of these histograms means Hue ranging from 0..255 (I used this scale instead of 0º..360º for compatibility with the other histograms [a href=\"http://www.guillermoluijk.com/software/tonehacker/index.htm]Tone Hacker[/url] calculates).

If the result is acceptable or it is not will depend on how demanding you and/or your work are about tone precision.

The main peak where almost all original blue tones concentrate shifts by 2 pixels; and in addition to this an important secondary peak with a blue closer to cyan than the original one appears at a distance of 7 pixels:

(http://img509.imageshack.us/img509/491/compek4.gif)

That means:
- Main tone being shifted by 2*360/256=2.81º, and
- Secondary tone appearing with an error respect to the original of 7*360/256=9.84º

Is this acceptable for you?


Independently of how important is this issue for a given user, I simply say: if PS in Luminance blending mode can achieve an almost perfect tone preservation, why ACR (from the same Adobe) cannot?
Title: Your Curves
Post by: digitaldog on July 29, 2007, 04:46:05 PM
Quote
If every curve you pull on the ACR/LR curve affects saturation, shouldn't we also know that?

All I have to do is look. I've got numbers, I've got color appearance. Knowing what's going on under the hood is mildly useful to some. Its not a requirement for producing acceptable and desired color rendering. That the curves affect saturation is only a problem if the user can't produce a desired color appearance with the toolset. So far, no one has demonstrated that this is a problem, in fact the opposite.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 05:06:35 PM
Quote
Well, the shot on the left was by Jay Maisel, and the shot on the right... no, wait a minute...
[a href=\"index.php?act=findpost&pid=130486\"][{POST_SNAPBACK}][/a]

By Andrew Rodney?  
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 05:13:55 PM
Quote
No no Mark, believe me, actual NEW blues appear. The X axis of these histograms means Hue ranging from 0..255 (I used this scale instead of 0º..360º for compatibility with the other histograms

If the result is acceptable or it is not will depend on how demanding you and/or your work are about tone precision.

The main peak where almost all original blue tones concentrate shifts by 2 pixels; and in addition to this an important secondary peak with a blue closer to cyan than the original one appears at a distance of 7 pixels:

Is this acceptable for you?
Independently of how important is this issue for a given user, I simply say: if PS in Luminance blending mode can achieve an almost perfect tone preservation, why ACR (from the same Adobe) cannot?
[a href=\"index.php?act=findpost&pid=130492\"][{POST_SNAPBACK}][/a]

Guillermo, I'm puzzled about this, because the outcome is supposed to be the other way around: CR curves are supposed to preserve hue, Photoshop Curves do not necessarily preserve hue. So there is some disconnect between the measurements you have made and the purported behaviour of the programs. Not saying who's right or wrong here, just pointing out that there is a disconnect, and I don't understand why it's happening. Now I hate to ask you because I know it is tedious, but if you were to do the same kind of HSB measurements from selected pixels in the image that I have been doing, would you get the same general conclusion? Perhaps it is worth checking to see whether you come to the same finding using two different measurement techniques.
Title: Your Curves
Post by: Schewe on July 29, 2007, 05:14:50 PM
Quote
Is this acceptable for you?
Independently of how important is this issue for a given user, I simply say: if PS in Luminance blending mode can achieve an almost perfect tone preservation, why ACR (from the same Adobe) cannot?
[a href=\"index.php?act=findpost&pid=130492\"][{POST_SNAPBACK}][/a]


It's acceptable to me...and has been since Camera Raw 1.0 (even before the bundled version in CS) because I get more than acceptable raw conversions. If I need to do more, later in Photoshop, I do.

At a certain point, what use is navel gazing...it all comes down to the image. Can you get the image to look exactly the way you want? I can...as for why, Mark explained it, luminance without a sat changes looks weird (as I indicated in the sample image you showed).

If you want that changed, take it up with Thomas Knoll on the Camera Raw forum where he hangs out. But I'll warn you, ya better have something more than what you've shown so far...charts and graphs are one thing, use cases with example images go a lot further.
Title: Your Curves
Post by: Mark D Segal on July 29, 2007, 05:20:29 PM
Quote
Not quibbling here, but Dan didn't say that, I did. Dan's quote is in a quote box.
Nope, I don't think it matters. However, the more understanding of how these tools work, the better one can use them. And we can't learn or when to use them if they can't be discussed.

For example, if the "hue locking" curve allows a (mild or not) shift in hue, isn't that worth knowing? 

If every curve you pull on the ACR/LR curve affects saturation, shouldn't we also know that?

I've learned a lot the last few days. Guillermo, thanks for all those visuals, and the info. Peter, I'm going to go study your chart. Thanks.

Mark, great effort but the Twins are back, so...discussion is over.
[a href=\"index.php?act=findpost&pid=130491\"][{POST_SNAPBACK}][/a]

Hi Gloria,

I know what Dan said and it is similar to what you said he said, so agreed no quibble.

Of course what these curves do and don't do can and should be discussed here - no question - the purpose of my paper and this whole discussion.

Emjoy the twins. We just had a whole week with the grand-children. They were great fun, but it sure is nice their parents are back from vacation!  
Title: Your Curves
Post by: Guillermo Luijk on July 29, 2007, 05:43:42 PM
Quote
Guillermo, I'm puzzled about this, because the outcome is supposed to be the other way around: CR curves are supposed to preserve hue, Photoshop Curves do not necessarily preserve hue. So there is some disconnect between the measurements you have made and the purported behaviour of the programs. Not saying who's right or wrong here, just pointing out that there is a disconnect, and I don't understand why it's happening. Now I hate to ask you because I know it is tedious, but if you were to do the same kind of HSB measurements from selected pixels in the image that I have been doing, would you get the same general conclusion? Perhaps it is worth checking to see whether you come to the same finding using two different measurement techniques.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130498\")

Well, on my side these tone histograms match the conclusions obtained with all HSB values provided by PS probes (picture of the girl, and picture of the flag).

Always when checking Hue on PS Lum mode curves, it is perfectly preserved. On the contrary, when checking Hue on ACR originated curves there is a Hue shift in some degree.

In the picture of the flag that you downloaded this can could be seen, did you check Hue values on some other spots of the picture?


The formulas my program uses to generate a Hue value from every R,G,B triad are the standard I found on the [a href=\"http://en.wikipedia.org/wiki/HSV_color_space]Wikipedia page[/url] and this is my implementation, if you know about coding you will see there is no secret:

(http://img126.imageshack.us/img126/8158/functionhk4.gif)

And the fact that PS Lum mode curves preserve perfectly Hue according to this RGB to HSB formulation makes me think I am doing things right in that code.

What else can we do? could you upload some picture where you found Hue not changing when applying curves in ACR?
You must see that my curve was very agressive; maybe those curves you used in your tests were not so strong and Hue shift was minor.
Title: Your Curves
Post by: Ray on July 29, 2007, 09:52:10 PM
I find this thread quite fascinating, although I'm not going to pretend I understand it all.

There are a number of analogies that spring to mind. Do you need to be a car mechanic in order to pass your driving test? Is it helpful to know something about the mechanics of a car if you're driving it? Definitely yes, I would say.

Does a piano player, well let's upgrade, a concert pianist need to know how to tune a piano? No he/she doesn't, but the processes involved should perhaps be background knowledge; the fact that certain frequencies interfere with each other and produce 'beats' which the piano tuner listens for, is something which must be of interest.

The use of curves in Photoshop or ACR is akin to playing the piano. As I wrote before, it's very heuristic. One gets a sense through continual practice that a nudge here and a nudge there produces the desired effect.

Should we delve deeper into what's going on under the bonnet? Why not! It will at least increase our awareness of the issues.
Title: Your Curves
Post by: Guillermo Luijk on July 30, 2007, 04:47:17 AM
Quote
I have created this thread for any feedback and discussion of my essay "Do Your Curves Throw You a Curve?", published on Luminous-Landscape today. It would be ideal if all contributors to this discussion posted in this thread, for continuity and ease of reference.
[a href=\"index.php?act=findpost&pid=129766\"][{POST_SNAPBACK}][/a]

how strange, I already answered to you yesterday, showing how many degrees Hue shifted when using ACR curves, but my answer is now gone

- The main peak shifted by 2.8º I think
- And a new hue peak appeared more than beyond the original tone
Title: Your Curves
Post by: laughfta on July 30, 2007, 05:49:40 AM
Quote
how strange, I already answered to you yesterday, showing how many degrees Hue shifted when using ACR curves, but my answer is now gone

Not gone, Guillermo, just covered by some others  ...I think you are referring to post#103?
Title: Your Curves
Post by: Guillermo Luijk on July 30, 2007, 06:15:16 AM
Quote
Not gone, Guillermo, just covered by some others  ...I think you are referring to post#103?
[a href=\"index.php?act=findpost&pid=130572\"][{POST_SNAPBACK}][/a]

hehe, yes that must be the reason. I am at work now and here, I don't know why, the threads structure is presented in form of expanding trees with posts related ones to others. I don't like this way of presentation, and I don't know how to get to post #103. It does not appear in my present tree view.

How should I do it?
Title: Your Curves
Post by: laughfta on July 30, 2007, 07:21:24 AM
Quote
hehe, yes that must be the reason. I am at work now and here, I don't know why, the threads structure is presented in form of expanding trees with posts related ones to others. I don't like this way of presentation, and I don't know how to get to post #103. It does not appear in my present tree view.

How should I do it?
[a href=\"index.php?act=findpost&pid=130573\"][{POST_SNAPBACK}][/a]

Up at the top of the page, on the title bar and on the right, there are options for Outline, Standard, and Linear+. I am on Standard...does that do it?
Title: Your Curves
Post by: Mark D Segal on July 30, 2007, 08:59:14 AM
Guillermo, Gloria has it right - just select the presentation option that keeps all the posts presented in sequence. Somehow or other without my knowing how, my L-L set-up got converted into one of those trees - messed me up until I saw how to get back to the "staightforward" presentation of one post after the other.

On the substantive issue, I saw that Jeff Schewe answered your message on the hue shift. I haven't answered yet because I'm working on some stuff that is related. I think I may be able to replicate that kind of behaviour in a completely different image. It is I imagine conceivable that the hue retention is not absolutely perfect accross the spectrum in CR, but it also conceivable that there are limitations with the measurements themselves. I think this may an issue worth posting to the Adobe Camera Raw Forum. Jeff has said Thomas Knoll watches that traffic - if it comes to attention of either Thomas or others involved, they may have something to say about it.
Title: Your Curves
Post by: Brian Gilkes on July 30, 2007, 06:01:26 PM
Eureka!
I've got rid of the tree! I thought it was a permanent affliction. Thanks.
Now on thread (I hope).
The problem of colour shifts when using curves to control luminosity, even when blending in luminosity ,can be solved for $50.with Lobster
See www.freegamma.com
I couldn't believe it when I first saw it work.
This will solve a lot of other Photoshop problems too.
I'd be interested in comments by some of the experts on this thread.
Cheers,
Brian
www.pharoseditions.com.au

PS I have no shares in the company and paid for my copy.
Title: Your Curves
Post by: Mark D Segal on July 30, 2007, 07:23:36 PM
Quote
Eureka!
I've got rid of the tree! I thought it was a permanent affliction. Thanks.
Now on thread (I hope).
The problem of colour shifts when using curves to control luminosity, even when blending in luminosity ,can be solved for $50.with Lobster
See www.freegamma.com
I couldn't believe it when I first saw it work.
This will solve a lot of other Photoshop problems too.
I'd be interested in comments by some of the experts on this thread.
Cheers,
Brian
www.pharoseditions.com.au

PS I have no shares in the company and paid for my copy.
[a href=\"index.php?act=findpost&pid=130738\"][{POST_SNAPBACK}][/a]

Brian, I'm aware of it, I see it is only in BEta for Windows so I'd have to wait. I see one also needs to send it flattened files, so that has workflow implications. I also see it is not specified for CS3 yet, and they don't say whether it can work with 16 bit images. But it does sound like an attractive complement to Photoshop once up-dated and brought to commercial use for Windows.
Title: Your Curves
Post by: laughfta on July 31, 2007, 08:36:33 AM
From the Wiki site (Thanks Mark, Guillermo, Rich):
RGB Saturation = 1-(Min/Max).
(other color mode equations  will be different, I'm sure)

I sampled a green pixel and obtained these  RGB values: R 53, G 64, B 85
Minimum  is the Red component at 53.  Maximum is the Blue component, at 85.
53/85 is .6235.
1-.6235 is .3765,
which rounds up to 38 and is expressed as a percentage— so that particular hue has a saturation of 38%.

At this point there was no need to actually DO the math, because PS does that for you.  I soon came to realize that the closer together in value the min and max were, the less saturated they were.  (if they were only separated by a few points say 128,130,131, we would have a saturation of 2%.)
The further apart the values were, the higher the saturation percentage.
0, 128, 86 is also green, and shows saturation of 100%.

The 'B' element HSB is even easier to determine—it is the maximum reading obtained from the three components of the RGB pixel  expressed as a percentage.  In the case above, it is 85%
Hue is a little more complicated, but also uses the Min and Max measurements.

My  original saturation question stemmed from a need to understand if or how hue, sat, and brightness affected each other. I see now what Guillermo meant when he said these are all independent of each other.  

The relationship instead rests in the RGB values.  

Raising or lowering the three RGB components of a pixel equally should only impact Brightness (Max) Changing the relationship between the Min or the Max, though (by raising or lowering them independently of each other), will affect the Saturation and Hue of that pixel.

This amounts to a small, unnecessary, but very satisfying peek under the hood, for me. I hope it is accurate.
Title: Your Curves
Post by: Mark D Segal on July 31, 2007, 10:06:57 AM
Quote
Raising or lowering the three RGB components of a pixel equally should only impact Brightness (

...................I hope it is accurate.

[a href=\"index.php?act=findpost&pid=130821\"][{POST_SNAPBACK}][/a]

Not quite.  Demonstration:

Start with your RGB values of 53,64,85. As you show, 1-(53/85) = 0.376.

Now add 100 to each (if this is what you mean by raising or lowering a pixel equally). You get the following outcome:

1-(153/185) = 0.173.

However, if what you mean by "equally is an equal PERCENTAGE, then we get the following result, using a 50% adder: i.e. each value multiplied by 1.5:

1-(79.5/127.5) = 0.376

So you preserve the S value if you add a constant percentage to each value, but not a constant amount.
Title: Your Curves
Post by: laughfta on July 31, 2007, 03:16:55 PM
Quote
However, if what you mean by "equally is an equal PERCENTAGE, then we get the following result, using a 50% adder: i.e. each value multiplied by 1.5:...


Well, I'd like to say I meant percentage, but no, I just got carried away and started thinking subtraction instead of division...I should have let it perk awhile longer. But thanks for pointing that out, Mark. It's interesting to consider that if I had just known how to ask the question to begin with,  I would have received around 4000 answers by now!

Moving on, I have a question about the fill and recovery sliders. How do these compare with the shadow/highlight sliders in PS? I have found that I use the shadow/highlight very carefully, and for just the same reason you mentioned about fill—if one is not careful, a light, flat shadow is the result. Have you seen any disconnect between what looks good on a monitor, and what prints well with these tools?
Title: Your Curves
Post by: Guillermo Luijk on July 31, 2007, 03:42:43 PM
Good study Mark. I think I know the satisfaction feeling you got when doing these tests on the genuine HSB conversion formulas.

To really understand something and take control of it, we must always go to the idea. The concept is always much more powerful than the implementation and will take you much farer.

Curves of any kind, are just implementations. PS Luminance mode curves seem to modify saturation when altering contrast. ACR do it as well, but in a different way. Is that enough to conclude that Brightness cannot be set independently of Saturation? no way.

We now go to the theory, to the concept, and we look at the numbers provided by the RGB to HSB conversion formulas, and back. In them, H, S and B are three values that can freely be set, independently of each other. Exactly the same as yoy can set R, G or B independently of the other 2 variables.

We have formulas to convert from a {R,G,B} triad to a {H,S,B} triad in a unique way. We have formulas to go back to a {R,G,B} triad from a {H,S,B}. So apparently is totally possible to set H, S, or B independently of the other 2 variables.

E.g. we want to change Bright without modifying H or S.

Original values: {R,G,B}
We convert them into: {H,S,B}
Now we simply decide to switch B by B', so we get: {H,S,B'}
And we convert it back to: {R',G',B'}
The three values R,G and B have changed, but in a HSB colour model, only B changed.

Why most programs don't do it that way, and altering B means altering S or S and H as well? I am not sure about the reasons, but I am certainly sure it was not a technological limit. The author simply decided it to be that way. Maybe because they didn't abandon at any time the RGB colour space, maybe they did but altered S to compensate the higher human eye saturation sensitivity in highlights,...

If you are really interested I can write a routine to alter B without altering H nor S at all, and see how the change affects the appearance of the image. I am fairly certain that the result will look unnatural, disgusting or wathever to our view; although mathematically correct according to our formulas. H and S didn't change a bit.
Title: Your Curves
Post by: Mark D Segal on July 31, 2007, 04:10:21 PM
Quote
Moving on, I have a question about the fill and recovery sliders. How do these compare with the shadow/highlight sliders in PS? I have found that I use the shadow/highlight very carefully, and for just the same reason you mentioned about fill—if one is not careful, a light, flat shadow is the result. Have you seen any disconnect between what looks good on a monitor, and what prints well with these tools?
[a href=\"index.php?act=findpost&pid=130875\"][{POST_SNAPBACK}][/a]

Gloria, I'm not much of a fan of Photoshop's shadow/highlight tool. I know some people rave about it, and used carefully in certain situations it can be very helpful, but in general I find Camera Raw better for controlling highlights and with the new Fill Light and Blacks in Camera Raw working interactively, I get richer shadows with better detail retention more easily than I did with highlight/shadow. There are other tools in Photoshop proper for dealing with dense images areas as well.

As for disconnects between monitor and print - definitely - especially in the shadow areas. A monitor will normally show you richer black and more detail in shadow areas than a print can reflect. The best way to bridge this gap, assuming your colour management set-up is good, is to soft-proof the image with your printer/paper profile (making sure that "Simulate Paper White" is seleted) and make your final curves tweaks in soft proof mode. That way, you should get a 90~95% predictable match between the impression from the monitor and the print. It will never be perfect because of the inherent differences between transmitted and reflected light, and it will never be 100% fool-proof. But set-up right it's pretty darn good.
Title: Your Curves
Post by: Guillermo Luijk on July 31, 2007, 04:46:51 PM
Quote
Gloria, I'm not much of a fan of Photoshop's shadow/highlight tool. I know some people rave about it, and used carefully in certain situations it can be very helpful

I have to say that Photoshop's shadow/highlight tool is (almost) equivalent to an inverted S-shaped curve. It's no mistery nor magic.
I said "almost" as this tool also adds some zone treatment (in fact one of its parameters is a radius of action which if set too high can lead to visible hallos appearing) that obviously will never be imitated by a curve. But in general terms is just an adaptive de-contrast curve.

Look at this example:

E.g. Photoshop's shadow/highlight tool. Amount=70%, standard wide and radius.
This is the histogram of the image where the tool was applied to:
(http://img297.imageshack.us/img297/6993/batter2srgbjpghiski1.gif)

And this is the curve that achieves exactly the same result (see how the shadow/highlight tool is really sofisticated as it adapts specifically to the image's histogram shape):
(http://img261.imageshack.us/img261/1259/batter2srgbluces100tifctz6.gif)

If you want to see more Photoshop tools expressed in terms of a single curve: "What you should use, and what you should not use in Photoshop" (http://www.ojodigital.com/foro/showthread.php?t=136412)
Title: Your Curves
Post by: Mark D Segal on July 31, 2007, 05:05:11 PM
Quote
I have to say that Photoshop's shadow/highlight tool is (almost) equivalent to an inverted S-shaped curve. It's no mistery nor magic.

If you want to see more Photoshop tools expressed in terms of a single curve: "What you should use, and what you should not use in Photoshop" (http://www.ojodigital.com/foro/showthread.php?t=136412)
[a href=\"index.php?act=findpost&pid=130889\"][{POST_SNAPBACK}][/a]

I'm not surprised - the results kind of look that way.

That website you sent us to: looks fascinating - wish I could read Spanish. I did understand that Curvas = Curves and Niveles = Levels. Wow - isn't that brilliant? Now to a pure Anglo the last one could be a bit of a challenge but I also speak French, where the word "niveau" means "level", so it wasn't too big a transition to "niveles" given the context. The desirability of learning Spanish also came home to me when we visited Spain last October. We found the country fabulous and wished we knew the language.
Title: Your Curves
Post by: Guillermo Luijk on July 31, 2007, 05:15:26 PM
Quote
I'm not surprised - the results kind of look that way.

That website you sent us to: looks fascinating - wish I could read Spanish. I did understand that Curvas = Curves and Niveles = Levels. Wow - isn't that brilliant? Now to a pure Anglo the last one could be a bit of a challenge but I also speak French, where the word "niveau" means "level", so it wasn't too big a transition to "niveles" given the context. The desirability of learning Spanish also came home to me when we visited Spain last October. We found the country fabulous and wished we knew the language.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130890\")

hehe yeah Mark, you are right.

Curve=Curva
Level=Nivel
Bright=Brillo
Contrast=Contraste
Hue=Tono or Color

On this other link I showed in that forum the ability of a program of mine to work out the precise RGB curve to be applied to emulate any number of level adjustments applied in a row (Curves, Levels, Bright/Contrast, Colour balance,...). For colour pictures it needs the initial image, and the final resulting one, and calculates the curves that take you from one to the other.
I was amazed at the results, these curves emulated in just one step a number of level adjustments: [a href=\"http://www.ojodigital.com/foro/showthread.php?t=134449]All your level adjustments summarized in one single curve[/url]

As you can see I have been fond of curves for a long time.

PS: next time you visit Spain let me know


An example. We have this pic (do you remember it?):
 
(http://img211.imageshack.us/img211/7858/picadilly1original2me9.jpg)
 
We apply some bad-guy adjustments: Curves (quite strange ones), Levels (including some intentional clipping), Bright/Contrast control and Colour balance:
 
http://perso.wanadoo.es/gluijk/[COLOR=#...acv[/COLOR] (http://perso.wanadoo.es/gluijk/blues&yellows_CUR.acv)[/url]
 
(http://img293.imageshack.us/img293/9343/niveleshd9.jpg)
 

And we get this pic:
 
(http://img293.imageshack.us/img293/8938/resultado1tv8.jpg)
 

Now we put those 2 images into the routine and my program obtain these curves (look at how well the clipping is emulated and also the blue colour balance):

 
http://perso.wanadoo.es/gluijk/curva_ps.acv (http://perso.wanadoo.es/gluijk/curva_ps.acv)
(http://img394.imageshack.us/img394/199/picafinal8bmpcurrf6.gif)
(BTW they are 256-point curves, forget the 19 point PS limitation hehe).
 
That applied to the original image gets in only one step this image, indistinguisable from the resulting one with the 4 treatments:
 
(http://img394.imageshack.us/img394/1061/resultado2ac3.jpg)
 
Once we have the curves, we can apply them to some other picture (http://www.pbase.com/gluijk/image/68292170 (http://www.pbase.com/gluijk/image/68292170)) obtaining the same feeling (histograms must be similarly distributed of course):
 
(http://img77.imageshack.us/img77/3597/gloucester3ql5.jpg)
Title: Your Curves
Post by: laughfta on July 31, 2007, 06:44:31 PM
Quote
If you are really interested I can write a routine to alter B without altering H nor S at all, and see how the change affects the appearance of the image. I am fairly certain that the result will look unnatural, disgusting or wathever to our view; although mathematically correct according to our formulas. H and S didn't change a bit.


but wait a minute, Guillermo...would this perhaps be accomplished through raising the percentage of all three RGB components, as Mark showed with saturation?  

 I'm always interested in seeing your illustrations, Guillermo, nor would I necessarily rule out unnatural and disgusting.  On the other hand, it sounds like a great deal of work.
Title: Your Curves
Post by: PeterLange on July 31, 2007, 06:50:45 PM
Quote
Start with your RGB values of 53,64,85. As you show, 1-(53/85) = 0.376.

Now add 100 to each (if this is what you mean by raising or lowering a pixel equally). You get the following outcome:
1-(153/185) = 0.173.

However, if what you mean by "equally is an equal PERCENTAGE, then we get the following result, using a 50% adder: i.e. each value multiplied by 1.5:
1-(79.5/127.5) = 0.376

So you preserve the S value if you add a constant percentage to each value, but not a constant amount.
Mark, - I’m pleased to see such clear analysis. If you now would exchange the terms "percentage" or "multiplier" by "slope",
as well as the terms to "add" or "subtract" by "offset"
it is meeting the gist of my initial post #90.  With a bit of training such side effects on saturation can be "seen" from the shape of an RGB curve.
--

Quote
... I simply say: if PS in Luminance blending mode can achieve an almost perfect tone preservation, why ACR (from the same Adobe) cannot?
Brightening S-curves which are probably most common to work from a scene-referred, dark & dull "Raw state" to an output-referred, "pleasing" rendition are better left in normal RGB mode rather than changing to Lab or Luminosity blend mode. The latter are more damaging with regard to color integrity (= intensity ratios of R:G:B alias HSB-hue & -saturation).
--

Quote
If you are really interested I can write a routine to alter B without altering H nor S at all, and see how the change affects the appearance of the image. I am fairly certain that the result will look unnatural, disgusting or whatever to our view; although mathematically correct according to our formulas. H and S didn't change a bit.
IF not mentioned earlier, HSB brightness curves can be obtained from: http://www.curvemeister.com (http://www.curvemeister.com) . It is however more complicate to equip Lab lightness curves with a HSB-hue & -saturation lock:
http://www.xs4all.nl/~tindeman/raw/color_reproduction.html (http://www.xs4all.nl/~tindeman/raw/color_reproduction.html)
http://www.xs4all.nl/~tindeman/raw/curve_tools.html (http://www.xs4all.nl/~tindeman/raw/curve_tools.html)

Anyway, you’re right that these are Color models and not Color appearance models. We may prefer a blue sky which is more saturated, or green grass which is less bright (so that it doesn’t dominate a scene) while having a slight hue-shift to warm red, etc…


Peter

--
Title: Your Curves
Post by: Guillermo Luijk on July 31, 2007, 07:38:38 PM
Quote
but wait a minute, Guillermo...would this perhaps be accomplished through raising the percentage of all three RGB components, as Mark showed with saturation? 

 I'm always interested in seeing your illustrations, Guillermo, nor would I necessarily rule out unnatural and disgusting.  On the other hand, it sounds like a great deal of work.
[a href=\"index.php?act=findpost&pid=130908\"][{POST_SNAPBACK}][/a]

OK tomorrow I will apply a:
- H change preserving S,B
- S change preserving H,B
- B change preserving H,S

I am exhausted now, we had a team building session at work and spent all day doing this kind of kid games   :

(http://img240.imageshack.us/img240/7332/gunit9.jpg)
(me testing weaponry)

Completely agree Peter.
Title: Your Curves
Post by: Mark D Segal on July 31, 2007, 09:03:56 PM
Quote
Mark, - I’m pleased to see such clear analysis. If you now would exchange the terms "percentage" or "multiplier" by "slope",
as well as the terms to "add" or "subtract" by "offset"
it is meeting the gist of my initial post #90.  With a bit of training such side effects on saturation can be "seen" from the shape of an RGB curve.
--
Brightening S-curves which are probably most common to work from a scene-referred, dark & dull "Raw state" to an output-referred, "pleasing" rendition are better left in normal RGB mode rather than changing to Lab or Luminosity blend mode. The latter are more damaging with regard to color integrity (= intensity ratios of R:G:B alias HSB-hue & -saturation).
--
.............................tc…
Peter

--
[a href=\"index.php?act=findpost&pid=130909\"][{POST_SNAPBACK}][/a]

Peter - I can live with "slope" and "offset" instead of "percentage" and "add" ! And as you say it does help one visualize a relationship between curve shape and impact on saturation. Your concern about adjusting Luminosity in Lab space rather than RGB space is mentioned in other words on page 3 of my essay, adapted from the referenced discussion with Thomas Knoll, who also referenced corroboration from Bruce Lindbloom - so there is consensus between the three of you on this point.
Title: Your Curves
Post by: Mark D Segal on July 31, 2007, 09:43:49 PM
Quote
On this other link I showed in that forum the ability of a program of mine to work out the precise RGB curve to be applied to emulate any number of level adjustments applied in a row (Curves, Levels, Bright/Contrast, Colour balance,...). For colour pictures it needs the initial image, and the final resulting one, and calculates the curves that take you from one to the other.
I was amazed at the results, these curves emulated in just one step a number of level adjustments: All your level adjustments summarized in one single curve (http://www.ojodigital.com/foro/showthread.php?t=134449)

As you can see I have been fond of curves for a long time.

PS: next time you visit Spain let me know
[a href=\"index.php?act=findpost&pid=130893\"][{POST_SNAPBACK}][/a]

Guillermo, I do hope to get back to Spain one of these days when the right opportunity arises and if I do I shall let you know.

Those are fascinating effects, and when time permits, if there were documentation in English I would be interested to experment with your programs.  I'll tell you - the day you develop one that can adjust Curves in much smaller increments than we have now (as we discussed earlier on) - I'll be URGENTLY interested.

Cheers,

Mark
Title: Your Curves
Post by: laughfta on August 01, 2007, 07:52:33 AM
Quote
hose are fascinating effects, and when time permits, if there were documentation in English I would be interested to experment with your programs.  I'll tell you - the day you develop one that can adjust Curves in much smaller increments than we have now (as we discussed earlier on) - I'll be URGENTLY interested.


I found that this website, (there are probably others) freetranslation.com (http://www.freetranslation.com) that is able to translate sections of Guillermo's website perfectly adequately for you. Amazing. For a small consideration, they will do the whole website.

PS I imagine Guillermo will have the results for a process of adjusting curves in smaller increments by this afternoon
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 09:11:14 AM
Quote
I found that this website, (there are probably others) freetranslation.com (http://www.freetranslation.com) that is able to translate sections of Guillermo's website perfectly adequately for you. Amazing. For a small consideration, they will do the whole website.

PS I imagine Guillermo will have the results for a process of adjusting curves in smaller increments by this afternoon
[a href=\"index.php?act=findpost&pid=130986\"][{POST_SNAPBACK}][/a]

gloria, yes, I'm aware of that website - but didn't think of it in this context. Good idea - thanks. Now, if Guillermo can program a 32,768 one-step-at-a-time Curve adjustor by this afternoon he's on his way to becoming a multi-multi-millionaire in digital imaging. Wouldn't that be nice for Guillermo!  
Title: Your Curves
Post by: Guillermo Luijk on August 01, 2007, 09:54:27 AM
Quote
gloria, yes, I'm aware of that website - but didn't think of it in this context. Good idea - thanks. Now, if Guillermo can program a 32,768 one-step-at-a-time Curve adjustor by this afternoon he's on his way to becoming a multi-multi-millionaire in digital imaging. Wouldn't that be nice for Guillermo! 
[a href=\"index.php?act=findpost&pid=131002\"][{POST_SNAPBACK}][/a]


I don't understand this: why should you be happy with a 32,768 one-step-at-a-time Curve adjustor, when you can have it in 65,536 one-step-at-a-time?    


To tell you the truth, I have thought many times about developing a super zoom curve editor. What I find disappointing in PS, apart from the low step precision, is the kind of curve available: always polynomial. Sometimes when you set curve point very close to others, the curve performs strange shapes very difficult to control. In addition to this, if curve is made of three points: A, B and C, the segment B-C is afected by the location of A.
A curve editor allowing straight linear segments would be much better in some high precision cases-

I would like to have a curve editor with:
- More resolution (input-output pairs in the 0..65535 range)
- Different kind of segment behaviours (polynomial, straight lines, stairs)
- Different input-output variable transfer functions:

Classical RGB:
R=f(R )
G=f(G )
B=f(B )

Constrast with Hue and Saturation preservation (B=Bright):
B=f(B )

Saturation control according to Hue:
S=f(H )
This is really interesting, you could oversaturate/desaturate only certain tones. It's an extension of a PS's Saturation layer but more precise and flexible

Saturation according to Bright: to saturate more dark areas and desaturate light ones.
S=f(B )

...

Combinations are endless. Not all interesting, but some can be really worth to experiment with.
This is an idea for the future. Requires a good control of the screen display to make it easy for the user to move in the whole curve plane, add/delete/edit points, show effect in real time,... This is a task for real programmers and I am not.
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 11:01:42 AM
Ya, but jokes aside, I thought of 65000 and then said to myself there must be a limit to the ability of human visual perception to see the difference in small changes below a certain amount. I can definitely see quite important changes the way they have it now, which is well in excess of 70 levels per cursor movement. If it could be brought to 8 levels per cursor push I think that would be more than adequate, which means a curve adjustor with 4096 adjustable levels covering a 32768 level range. So this is now a proposition ready for the Adobe Feature Request list?
Title: Your Curves
Post by: Guillermo Luijk on August 01, 2007, 04:13:46 PM
Here are the examples of individual H, S and B modifications.
This is the original image:

(http://img128.imageshack.us/img128/7979/tulipsoriginalbm6.jpg)


[1] H shift of 49º preserving S and B (I applied it only to the tulips, which were very easy to identify by just making sure only to shift their clearly identified tone range):

(http://img245.imageshack.us/img245/6794/tulipshchangejv2.jpg)

Uunatural tulips but the tone shift looks ok. In fact I repetead it in PS making use of the select by colour gamma tool, and tone/saturation tool to shift the Hue, and the result was almost identical.

The original (up) vs final (down) Hue histograms are here. The tulips merge into the same tone range as the crops, making them now indistinguisable in this histogram:

(http://img127.imageshack.us/img127/4922/plantillaql3.gif)


[2] S shift down to 1/3 of the original preserving H and B

(http://img245.imageshack.us/img245/4594/tulipsschange33sb5.jpg)

Strange view, but seems OK according to what we are doing and get the same appearance as with PS saturation tool.


[3] B applied an 's'-shape contrast curve preserving H and S

(http://img128.imageshack.us/img128/2833/tulipsbchangebd0.jpg)

This one looks quite disgusting and unnatural, and seems to lack some detail (this was however expected as I am working in 8-bits in these tests that makes posterization easy to happen).
Hypothesis: maybe this is a perceptive reason for most programs to introduce some parallel adjust in Saturation (ACR, PS Norm, PS Lum) and in Hue (ACR, PS Norm) when performing contrast control.
But I want to remark that mathematically this test is as correct as the other two ones.


For those interested in the code to achieve these tests:


            lColour = MyObj1.GetColorAt(lX, lY)
            iRGB(1) = GetR(lColour)
            iRGB(2) = GetG(lColour)
            iRGB(3) = GetB(lColour)

            RGBtoHSV iRGB(1) / 255, iRGB(2) / 255, iRGB(3) / 255, H, S, V


                Test 1
                    If H <> -1 And (H >= 240 Or H <= 15) Then
                        HSVtoRGB IIf(H + iNTonos > 255, H + iNTonos - 255, H + iNTonos), S, V, R, G, B
                        MyObj2.LineColor = RGB(Round(R * 255), Round(G * 255), Round(B * 255))
                        MyObj2.DrawPoint lX, lY
                    Else
                        MyObj2.LineColor = lColour
                        MyObj2.DrawPoint lX, lY
                    End If
                   
                Test 2
                    HSVtoRGB H, S / 3, V, R, G, B
                    MyObj2.LineColor = RGB(Round(R * 255), Round(G * 255), Round(B * 255))
                    MyObj2.DrawPoint lX, lY
                   
                Test 3
                    HSVtoRGB H, S, IIf(V <= 0.5, 2 * V * V, 0.5 * V ^ 0.5 / 0.5 ^ 0.5), R, G, B
                    MyObj2.LineColor = RGB(Round(R * 255), Round(G * 255), Round(B * 255))
                    MyObj2.DrawPoint lX, lY
Title: Your Curves
Post by: Eric Myrvaagnes on August 01, 2007, 04:42:54 PM
This thread continues to be one of the most surprising, entertaining, and informative ones on the LL forum. Please keep it coming!

And thank you to Guillermo and Mark and laughfta for keeping it alive.
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 04:45:08 PM
Guillermo -This is a nice demo and your hypothesis is correct. The fact is that (at least some of) the people (and for sure Thomas Knoll) who developed Photoshop are first class photographers in their own right, so when they wrote these algorithms it was after testing all kinds of possibliities and evaluating the results in a photographic context. That is why it is particularly misplaced criticism when certain people identify these intended relationships as "errors" or "inadequacies".
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 04:46:39 PM
Quote
This thread continues to be one of the most surprising, entertaining, and informative ones on the LL forum. Please keep it coming!

And thank you to Guillermo and Mark and laughfta for keeping it alive.
[a href=\"index.php?act=findpost&pid=131066\"][{POST_SNAPBACK}][/a]

Thanks Eric - and stay tuned.
Title: Your Curves
Post by: laughfta on August 01, 2007, 06:21:20 PM
A very nice thing to say, Eric. I think Guillermo did some especially fine work today, probably because he was pumped after his "team building" exercise. I know which team I wouldn't want to be on...


Quote
This one looks quite disgusting and unnatural, and seems to lack some detail (this was however expected as I am working in 8-bits in these tests that makes posterization easy to happen).


This disgusting and unnatural image #4 (of Poppies)—a contrast curve in which the hue and saturation were unchanged. We have seen in PS luminosity mode the saturation is affected, but hue unchanged. It sure doesn't look like this image. So, is this blocky look primarily due to the fact that the saturation was unchanged?

The original image is beautiful, Guillermo. And thanks for doing another study.
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 06:45:59 PM
Quote
We have seen in PS luminosity mode the saturation is affected, but hue unchanged.
[a href=\"index.php?act=findpost&pid=131081\"][{POST_SNAPBACK}][/a]

Gloria, In principle, in Luminosity mode neither the hue nor the saturation should be affected.
Title: Your Curves
Post by: Guillermo Luijk on August 01, 2007, 07:09:45 PM
Oops! I made a mistake, this is why not all space rockets reach the Moon. The formula to implement the curve in test 3 is not completely right, so bright didn't reach the maximum. This is the right expression:

HSVtoRGB H, S, IIf(V <= 0.5, 2 * V * V, 0.5 + ((2 * (IIf(V < 0.5, 0.5, V) - 0.5)) ^ 0.5) / 2), R, G, B

And the result (this was B constrast preserving H and S):
(http://img512.imageshack.us/img512/7905/tulipsbchangecorrectrs5.jpg)

Same curve in PS Luminance mode (yes, saturation changes as Gloria says Mark, it's Hue here that doesn't change):
(http://img512.imageshack.us/img512/3599/tulipsbchangepslumqv7.jpg)

Same curve in PS Normal mode:
(http://img166.imageshack.us/img166/2167/tulipsbchangepsnormwy1.jpg)

_________________

The look improves noticeably with the correction (I am talking about the first picture now), but it's still far from the result achieved with PS Luminance blending mode. Just need to look at the sky, far crops or flower textures (BTW they are not tulips, they are amapolas. Don't know the name in English).
Title: Your Curves
Post by: Mark D Segal on August 01, 2007, 07:52:40 PM
Quote
PS Luminance mode[/b] (yes, saturation changes as Gloria says Mark, it's Hue here that doesn't change):

[a href=\"index.php?act=findpost&pid=131091\"][{POST_SNAPBACK}][/a]

Well, maybe it does in the images you have displayed, but IN PRINCIPLE it is not meant to change. You may verify this at any number of the more serious photography websites which provide tutorial information, or from standard reference books, such as:

Real World Photoshop CS2 (Fraser & Blatner) page 357: "... Luminosity is the inverse of Color. It creates a result color with the hue and saturation of the underlying layer and the luminosity of the overlying layer."

Photoshop Masking and Compositing (Eismann), page 199: " In this example the Curves adjustment improved the image contrast, but it also over-saturated the little girl's sweater.....By changing the Curves layer blending mode to Luminosity, the contrast correction is maintained while the false saturation problem is negated..."
Title: Your Curves
Post by: laughfta on August 02, 2007, 12:15:10 AM
Quote
Well, maybe it does in the images you have displayed, but IN PRINCIPLE it is not meant to change. You may verify this at any number of the more serious photography websites


I don't quite know what to think

Back in the day, (Post #75) Guillermo in his tests came to this conclusion about PS Luminosity:

"What really happens (I have tested some pixels with your loved probes Mark lol):
- Hue is preserved in all pixels
- Saturation is reduced in those pixels where Bright is increased
- Saturation is increased in those pixels where Bright is reduced"

When I look at an image in PS, with a curve contrast layer in luminosity mode, a color sampler point set using 'point sample' so that one can make an accurate sample, and turning the layer on and off I measure this: In the lighter areas, the saturation is reduced, in the darker areas the saturation is increased, and in the middtones, it stays exactly the same.  Theoretically, everyone can be right.  

Does anyone else measure something different?
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 07:59:31 AM
Not everyone can be right - would be nice, but not to be. If you drew the "S" around the mid-tone you tested (such that the mid-tone were positioned roughly in the middle of the "S"), then of course that value would have experienced very little movement so you wouldn't get much of a change of anything. Your findings for the brights and the darks, however, do not cohere with the principle. Using a 3*3 or 5*5 sample grid would be preferable to rule out anomolies but somehow I doubt that is really the issue here. I have just completed another set of exercises to test a hypothesis related to how CR handles areas of bright pre-dominant colour, where I did a considerable set of measurements, and I too am getting variability between brightness and saturation changes. I think while the principle of saturation neutraility is supposed to be preserved by the manner in which Photoshop is programmed, from what I have been informed, the problem is more likely to be imperfections in the HSB calculations themselves. In the final analysis, as photographers, our objective is the appearance of the photographs - hence I've come to the conclusion that the pixel-value accounting, while academically interesting, is less important than whether the photograph does what we want it to do.
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 08:33:40 AM
I would like to point that the behaviour of the Saturation in PS Luminance curves (and with Saturation I mean the mathematical definition defined in the HSB colour model; the degree of agreement between this model and human eye perception is another analysis to do), is not exactly S increase in dark areas, and S reduction in light areas. It's S increase in areas that get darker, and S reduction in areas that get lighter, when applying the particular curve.

- In the most common s-shaped contrast curve, where dark areas are made darker, and light areas are made brighter, this behaviour translates as: more saturation in dark areas, less saturation in bright areas.
- But if we took an inverted s-shaped curve (contrast reduction), the behaviour would be dark areas would get less saturated, and light areas would get more saturated.
Title: Your Curves
Post by: Kenneth Sky on August 02, 2007, 08:47:42 AM
I fear to tread where angels walk. I have followed this thread as I suspect most of us with bewilderment. All of these mathematical models don't take in the perception of a photograph by the eye and its interpretation by the cortex. If we could create a standardized ambience for viewing prints and then get a statistically signifigant number of viewers to report the just noticeable differences that all of these mathematical models make, it would make a lot more sense to a lot of us. I am not belittleing this discussion, but I am saying that with my post-doctoral education I am still getting confused as to how this helps me make a better print.
Title: Your Curves
Post by: laughfta on August 02, 2007, 08:50:13 AM
Quote
I think while the principle of saturation neutraility is supposed to be preserved by the manner in which Photoshop is programmed, from what I have been informed, the problem is more likely to be imperfections in the HSB calculations themselves. In the final analysis, as photographers, our objective is the appearance of the photographs - hence I've come to the conclusion that the pixel-value accounting, while academically interesting, is less important than whether the photograph does what we want it to do.

I agree. My goal is to make an excellent final print of the image. If anything, this exercise just showed that whatever Adobe did with the luminosity mode, it is an improvement to making a contrast curve with only brightness. (At least in this case, at least to me)

The one area that I noticed as being possibly problematic to a final print, is the highlights in the sky, some seem to be either blown or approaching blown in the PS Lum and normal version. They look fine in the original, and in the B version with the same contrast curve. But it may be hard to discuss this if it isn't happening.  I guess if I was developing a raw image in ACR, I would take care to correct this with one of the many ways available (if it were, indeed, happening). I would dearly love an info palette in ACR.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 09:29:17 AM
Quote
I fear to tread where angels walk. I have followed this thread as I suspect most of us with bewilderment. All of these mathematical models don't take in the perception of a photograph by the eye and its interpretation by the cortex. If we could create a standardized ambience for viewing prints and then get a statistically signifigant number of viewers to report the just noticeable differences that all of these mathematical models make, it would make a lot more sense to a lot of us. I am not belittleing this discussion, but I am saying that with my post-doctoral education I am still getting confused as to how this helps me make a better print.
[a href=\"index.php?act=findpost&pid=131164\"][{POST_SNAPBACK}][/a]

Kenneth - of course underlying everything we do in these programs is a lot of math. Do users need to understand the math to use the programs? No. Is it good for users to gain a more precise appreciation of the behaviour of the programs' tools - Yes. Again, one doesn't need to know the math to do this, but some insight into how the numbers describing the results come out is a useful complement to the essential thing - as you say - the perceptual quality of the photographs; hence my comment in my previous post.  I think it helps you make a better print to know roughly how saturation will behave as you adjust a curve - of course you can see it when it happens -and all the more so if you are aware of the effect in the first place.
Title: Your Curves
Post by: laughfta on August 02, 2007, 09:34:56 AM
Quote
... I am still getting confused as to how this helps me make a better print.

There is something about PS that kind of sucks you in, I think:) You start out trying to clone out some imperfection, someone shows you how to  use various blurs, layers and  modes and it looks clearly better, then  you try converting it to Black and White, and the techniques pile up...

I have reached critical mass with techniques, and feel the need to understand the principals behind them that make them work. One reason is that I would remember them better, another is that I would be able to evaluate them to some extent without trying each and every one on every problem image. Most importantly I would be better able to modify and create my own workflow, which has to start in ACR.

But I do get carried away, though unlike Guillermo and Mark and many others, I am hanging on by the skin of my teeth in this discussion.

So, Mark, how do you like that target tool in CR for modifying the curve?  
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 09:35:08 AM
Quote
I would dearly love an info palette in ACR.
[a href=\"index.php?act=findpost&pid=131165\"][{POST_SNAPBACK}][/a]

I would like this too. To get it, one would need to make a feature request to Adobe along with an argument for why it would advance the usefulness of the program.
Title: Your Curves
Post by: Kenneth Sky on August 02, 2007, 09:47:49 AM
Mark
I agree. Just bring the discussion down to the level us "plebes" can understand and use, i.e. in a practical sense. The science is wonderful but I would like to know how each model advances the art. For a lot of us, digital post processing has just recently come out of the "black box" with recent iterations of Photoshop and the introduction of Lightroom. I guess I'm pleading for the KISS principle.
Ken
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 09:52:10 AM
Vey often I hear "I like to do in ACR all possible adjustments so that I save time in PS". Maybe I am wrong, but this aseveration doesn't seem brilliant to me; I could tell this person "I like to do in PS all possible adjustments so that I save time in my RAW developer":

I know this will not suffice (almost) anyone, but as I was commenting in other thread in this sub-forum I use DCRAW as a RAW developer, and do all adjustments once in PS:
- Exposure correction
- Camera profile
- Colour profile conversion and gamma
- Constrast and saturation
- Noise reduction
- Sharpening
...
I only miss from ACR the good noise reduction ability, which really works well.

I think having more and more features in the RAW developer only makes sense if you really wanto to get rid of PS, and end your processing in the RAW developer. But if the point is to go anyway to PS, I think this feature duplication is not useful to simplify and hence improve anyone's workflow.

I share the point of Angela that knowing how a particular of tool internally works can lead you to know if it is adequate for a certaing problem, saving testing times. A very typical case for this is the discusion: "sharp mask vs high pass filter". All sharpening techniques are based in high pass filtering which is the common tecnique to increase high spatial-frequency details; so they are basically the same. Use the one that makes you feel more confortable, but don't think one is better than the other.
Title: Your Curves
Post by: digitaldog on August 02, 2007, 10:04:32 AM
Quote
Vey often I hear "I like to do in ACR all possible adjustments so that I save time in PS". Maybe I am wrong, but this aseveration doesn't seem brilliant to me; I could tell this person "I like to do in PS all possible adjustments so that I save time in my RAW developer":

This gets back to the guru who only understands Photoshop and doesn't understand rendering.

A Raw processor is a rendering engine. Its not a correction tool so to speak as we have in Photoshop. With Photoshop, you've got rendered, baked pixels. You can fix them but you can't re-render them. A Raw processor isn't as much a 'correction' tool as a rendering tool. There's a difference! Raw has no color, you create the color and tone from essentially Grayscale data. You do this by building metadata instructions that will eventually be used to build colored pixels that you may further need to edit in a pixel editor (Photoshop).

The beauty of metadata rendering is you have all the original data to work with that the camera captured.

You can build as many sets of instructions to render as many pixel based documents you wish in a truly non destructive manner.

You have linear encoded, high bit, potentially very wide gamut data to render. After rendering, you get what you get, you can't really put all that toothpaste back into the tube.

I'm sure I'm missing other useful features of instruction based rendering from Raw, but the big point is, its not pixel editing in Photoshop by a long shot. For this reason, the idea of doing as much work in CR than Photoshop makes a heck of a lot more sense in terms of quality, toolset and speed. Naturally there are all kinds of operations that can't happen until one has a pixel based document. Then Photoshop is king. Different tools for different tasks. Not the same as looking at these processes as a hammer in search of a nail.

It is here the guru doesn't get it. Worse, he says the toolset is unfit for professional use due to sloppy math despite Mark's continuing efforts to show that isn't at all the case. Meanwhile, getting Raws from the guru to illustrate his point have gone nowhere. Could be due not to sloppy math but sloppy rendering techiques? Where's the spreadsheet proving the faulty math?
Title: Your Curves
Post by: digitaldog on August 02, 2007, 10:12:30 AM
Quote
I guess I'm pleading for the KISS principle.

For me, its about making the image look the way I want it to. The math isn't important after awhile.

For CR and LR, working top down, left to right is the KISS approach and design.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 10:41:01 AM
Quote
Mark
I agree. Just bring the discussion down to the level us "plebes" can understand and use, i.e. in a practical sense. The science is wonderful but I would like to know how each model advances the art. For a lot of us, digital post processing has just recently come out of the "black box" with recent iterations of Photoshop and the introduction of Lightroom. I guess I'm pleading for the KISS principle.
Ken
[a href=\"index.php?act=findpost&pid=131175\"][{POST_SNAPBACK}][/a]

Ken, Just for the record, I am not a programmer and not a digital imaging mathematician - by a long shot. The way I approach this is to do carefully controlled experiments that allow me to evaluate outcomes as a result of adjustments using one tool at a time (or more depending on the objective) in a manner that I can associate the character of the outcome with the nature of the adjustment. For me, the final arbiter is what it is for you - how does the image look? I use the numbers to corroborate or amplify. I also find the numbers in the info palette very handy for making the adjustments. They do help keep our eyes "honest". I do hope you found the discussion in my paper "down to earth" enough to be useful.
Title: Your Curves
Post by: Ray on August 02, 2007, 10:54:36 AM
Quote
For this reason, the idea of doing as much work in CR than Photoshop makes a heck of a lot more sense in terms of quality, toolset and speed. Naturally there are all kinds of operations that can't happen until one has a pixel based document. Then Photoshop is king. Different tools for different tasks. [a href=\"index.php?act=findpost&pid=131180\"][{POST_SNAPBACK}][/a]

Andrew,
I think we are all in favour of as much non-destructive editing as possible. I notice that CS3 allows for more editing options in 32 bit than CS2. Levels have now been included on the sparse list, but not curves yet.

Just how significant is this non-destructive aspect of editing in ACR? Are we talking about a degree of difference equivalent to Photoshop editing in 16 bit as opposed to 8 bit? Or perhaps converting an image that's originally in 8 bit to 16 bit for editing purposes?

There appears to be a progression towards more editing of pixel based documents in 32 bit mode. How would doing all editing in 32 bit mode, in Photoshop, compare with the so-called non-destructive editing with ACR curves?
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 10:58:40 AM
[
Quote
This gets back to the guru who only understands Photoshop and doesn't understand rendering.

A Raw processor is a rendering engine. Its not a correction tool so to speak as we have in Photoshop. With Photoshop, you've got rendered, baked pixels. You can fix them but you can't re-render them. A Raw processor isn't as much a 'correction' tool as a rendering tool. ........

The beauty of metadata rendering is you have all the original data to work with that the camera captured.

You can build as many sets of instructions to render as many pixel based documents you wish in a truly non destructive manner.

..................

It is here the guru doesn't get it. Worse, he says the toolset is unfit for professional use due to sloppy math despite Mark's continuing efforts to show that isn't at all the case. Meanwhile, getting Raws from the guru to illustrate his point have gone nowhere. Could be due not to sloppy math but sloppy rendering techiques? Where's the spreadsheet proving the faulty math?
[a href=\"index.php?act=findpost&pid=131180\"][{POST_SNAPBACK}][/a]

Andrew, OK - technically all correct - as usual - but to add a bit of semantics, I would suggest that the rendering instructions we build into the file are also "corrections" or "adjustments" - except they aren't correcting or adjusting pixels, and the beauty of the new tools is that we can now do so much more image editing in a non-destructive manner, why we recommend doing as much as feasible in CR before rendering into Photoshop, where as you say, it is king for doing things CR or Lightroom cannot do.

As for getting images from the Guru, I believe the images he refers to are the ones on the CD-ROM which comes with the Guru's book and there are Terms of Use. So you need to buy the book in order to have the images. Needless to say, I own a copy of the Guru's book, because eventhough I may disagree with a lot of what he says about raw rendering, there's much other useful stuff in the book.

So being entitled to download and play with the images in Chapter 16 related to raw conversion, I have run these images through CR 4.0 on my computer,  and I believe that I get great results (and in two cases I believe arguably better than his) with a minimal amount of work in CR4.0 alone. Before I share any of this stuff beyond my computer I need to verify the legal rights involved. Meanwhile, I'm using my own images where there are no legal problems. There may be more to say about this anon.  But I agree with you - it would be great if he were to share openly the raw images he believes CR either can't correct properly or CR "damages" and then we can have a more specific dialogue on an open forum with him about those very images.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 11:16:19 AM
Quote
So, Mark, how do you like that target tool in CR for modifying the curve? 
[a href=\"index.php?act=findpost&pid=131172\"][{POST_SNAPBACK}][/a]

I'm using CR 4.0 in Windows and there is no targeted adjustment tool there. It is in Lightroom and I think it is very intuitive and helpful.
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 11:24:05 AM
I am sorry to get back to a bit technical terminology, but I don't understand very well what is understood by "non-destructive edition". It means you can undo? It mens you even don't need to undo an action to make a new adjustmente without any quality loss? what is it?

Performing operations such as curves in PS with mask layers provides this kind of control. If you load a plain developed RAW (for instance developed using DCRAW), the only parameter applied in a "destructive" manner (and now I mean you cannot change it without going back to the original file) is white balance. And even in that case you can save all your set of Curves, Levels, or wathever mask layers in use over the present image.

So I don't see a clear advantage in the theoretically "non-destructive" processing found on most RAW developers (or renderers or whatever they are called).
Title: Your Curves
Post by: digitaldog on August 02, 2007, 11:59:13 AM
Quote
I am sorry to get back to a bit technical terminology, but I don't understand very well what is understood by "non-destructive edition". It means you can undo? It mens you even don't need to undo an action to make a new adjustmente without any quality loss? what is it?

Depends on who you ask. Marketing folks use the term incorrectly IMHO. No, undo isn't non destructive nor is saving out a copy. We've had this since day one on computers, nothing new or special.

IF you edit an existing pixel value, there's some 'damage' due to rounding errors, greatly reduced using high bit data. If you don't alter the values, there's no edit (so its not non destructive editing). Saving a copy, having adjustment layers which postpone the pixels undergoing a numeric change are NOT non destructive. Raw rendering truly is. The Raw data is never touched or altered. The result is a new, pixel based image that has yet undergone no number changing pixel edits.

The idea of an Adjustment layer being non destructive isn't correct. IF you flatten the image or print the document, the edit is stamped somewhere (even if the term stamped applies to data being sent to a printer). So I don't consider this non destructive. Nor do I find using metadata edits on existing rendered images in CR or LR non destructive. If anything, it might be more destructive (or less) depending on the edits. An existing rendered image in CR and LR still need to be converted to high bit, linear encoded ProPhoto RGB just to apply any tweak from the metadata instructions.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 12:13:18 PM
Quote
The idea of an Adjustment layer being non destructive isn't correct. IF you flatten the image or print the document, the edit is stamped somewhere (even if the term stamped applies to data being sent to a printer). So I don't consider this non destructive. [a href=\"index.php?act=findpost&pid=131207\"][{POST_SNAPBACK}][/a]

Andrew, for clarity here, do you agree that an adjustment is non-destructive if you DO NOT flatten the image, because it is a layer of meta data on top of the image?

I guess the issue is what happens to the pixels as a result of the meta-data once you do certain things - for example: if I send a file having adjustment layers to the printer without flattening it (but obviously it does get temporarily flattened for printing purposes somewhere in the processing between Photoshop and the printer driver) those meta-data instructions are temporarily "carried-out" on the file. Is this destructive or non-destructive in the strict sense of creating rounding errors in the process?

Once the file is printed, but my adjustment layers are still there intact, have I created some "destruction" regardless, because of the print process I just described here?
Title: Your Curves
Post by: digitaldog on August 02, 2007, 12:20:39 PM
Quote
Andrew, for clarity here, do you agree that an adjustment is non-destructive if you DO NOT flatten the image, because it is a layer of meta data on top of the image?

Yes, as long as all you're doing is viewing the image.

Quote
if I send a file having adjustment layers to the printer without flattening it (but obviously it does get temporarily flattened for printing purposes somewhere in the processing between Photoshop and the printer driver) those meta-data instructions are temporarily "carried-out" on the file. Is this destructive or non-destructive in the strict sense of creating rounding errors in the process?

To print the file, the adjustments if visible HAVE to be applied to the pixels, so there's damage.

In my mind, the bottom line is this. IF you alter the pixels, to print or anything besides just looking at the document, there's some data loss, the edit isn't non destructive. If you don't touch the pixels, you haven't edited the document. This too isn't non destructive editing (cause its not editing). Saving a copy isn't changing the facts that you've altered the pixels and saved them into a new document while leaving the original untouched. Same with Undo.
Title: Your Curves
Post by: Ray on August 02, 2007, 12:27:38 PM
Quote
The idea of an Adjustment layer being non destructive isn't correct. IF you flatten the image or print the document, the edit is stamped somewhere (even if the term stamped applies to data being sent to a printer). So I don't consider this non destructive. Nor do I find using metadata edits on existing rendered images in CR or LR non destructive. If anything, it might be more destructive (or less) depending on the edits. An existing rendered image in CR and LR still need to be converted to high bit, linear encoded ProPhoto RGB just to apply any tweak from the metadata instructions.
[a href=\"index.php?act=findpost&pid=131207\"][{POST_SNAPBACK}][/a]

As much as I respect your knowledge and experience, Andrew, this sort of reasoning needs some graphic examples.

Speaking for myself, I need to see some examples comparing non-destructive ACR editing with with 'destructive' 16 bit editing in PS, using the best procedures in each case to achieve the desired result.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 12:36:11 PM
Quote
As much as I respect your knowledge and experience, Andrew, this sort of reasoning needs some graphic examples.

Speaking for myself, I need to see some examples comparing non-destructive ACR editing with with 'destructive' 16 bit editing in PS, using the best procedures in each case to achieve the desired result.
[a href=\"index.php?act=findpost&pid=131216\"][{POST_SNAPBACK}][/a]

Ray while this sounds like a reasonable reequest, it may not be easy to fulfil. The errors may be small enough to go un-noticed or be hardly noticeable, except for really contrived stress conditions - and I've never fussed myself about what those may be.
Title: Your Curves
Post by: digitaldog on August 02, 2007, 12:36:21 PM
Quote
As much as I respect your knowledge and experience, Andrew, this sort of reasoning needs some graphic examples.

Speaking for myself, I need to see some examples comparing non-destructive ACR editing with with 'destructive' 16 bit editing in PS, using the best procedures in each case to achieve the desired result.
[a href=\"index.php?act=findpost&pid=131216\"][{POST_SNAPBACK}][/a]

Well that's going to be somewhat difficult because in one case, you have Raw data you're going to turn into pixels, versus taking rendered data you want to edit in Photoshop and applying an edit there. The gamma encoding isn't the same (although one could adjust that), the processing probably isn't identical. This goes back to a question posed to Thomas Knoll about upszing in CR versus in Photoshop. He said the practical effects should be about the same but the math certainly isn't. So its apples to oranges yet the practical effects are, you can hardly see any difference even when you use the Apply Image technique to subtract the differences in the two processes.

The math is undeniable, if you alter the values of pixels in any bit depth Photoshop supports, there are going to be errors. Some call this destruction and if you go way over board, certainly with 8-bit files, eventually the result is banding (aliasing). But doing this work in high bit, using say 64000 levels instead of 256 makes the damage pretty moot. But do you think its fair to use the term non destructive?
Title: Your Curves
Post by: Ray on August 02, 2007, 01:04:14 PM
Quote
But do you think its fair to use the term non destructive?
[a href=\"index.php?act=findpost&pid=131218\"][{POST_SNAPBACK}][/a]

Fair? Misleading? Confusing? It's all relative. I get back to my analogy of 16 bit editing versus 8 bit.

I recall some time ago we had a visiting young guru on this site demonstrating some photoshop techniques in an article on LL (rather than the forum).

He made the blunder of stating that, if an image was already in 8 bit, there was no need to to convert it to 16 bit for editing purposes. Jonathan Wienke proved him wrong.

I felt the visitor's embarrassment. But we need to substantiate our claims with examples. Theory has to be put into practice.

It sounds very reasonable that edits made in ACR before conversion are non-destructive, but seeing is believing, as one very famous photographer said - HCB of course.

Show us the difference.
Title: Your Curves
Post by: digitaldog on August 02, 2007, 01:21:56 PM
Quote
Fair? Misleading? Confusing? It's all relative. I get back to my analogy of 16 bit editing versus 8 bit.

I recall some time ago we had a visiting young guru on this site demonstrating some photoshop techniques in an article on LL (rather than the forum).

He made the blunder of stating that, if an image was already in 8 bit, there was no need to to convert it to 16 bit for editing purposes. Jonathan Wienke proved him wrong.

I'd like to see that because based on my work and conversations with Adobe engineers, the only thing going from 8bit to 16-bit brings to the party is the ability to now composite differing bit depth images.

Quote
It sounds very reasonable that edits made in ACR before conversion are non-destructive, but seeing is believing, as one very famous photographer said - HCB of course.

Show us the difference.
[a href=\"index.php?act=findpost&pid=131223\"][{POST_SNAPBACK}][/a]

The difference is, the Raw, the original data isn't touched. That's not what is happening when you edit a rendered image. The original pixels HAVE to undergo a numeric change otherwise, you don't produce any change and you're not editing the data.

Of course, we should discuss the kinds of editing. If I rotate an image 180 degrees, the numbers remain the same in each pixel, I've just changed the order so to speak. So to be clear, when I talk about editing, I'm referring to altering the numeric value of pixels.
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 01:30:01 PM
Quote
It sounds very reasonable that edits made in ACR before conversion are non-destructive

But I still don't get the point. What do you mean by saying "edits made un ACR before conversion"? with "conversion" you mean to perform the whole RAW developing process and import the resulting 16-bit TIFF into PS?

What's the difference between playing with ACR's curves until you get the desired result, and playing with a mask layer in PS until you get the desired result? is the first non-destructive and the second destructive? If so I disagree with this.
If ACR shows you the effect of let's say a curve, is because has performed the whole RAW developing process at least on the area currently displayed. And that means Bayer interpolation, and pixel levels alteration. Otherwhise it simply couldn't be displayed.

ACR is not going to perform all its adjustments at a time over the RAW file. They look like that to the user, but internally what ACR does is a completely sequential process where, for speed and simlpicity reasons, adjustments are applied one after another. White balance and exposure control are first, demosaicing comes next, hightlight recovery (if activated) is next, then comes colour profile conversion, curve adjustments,...
Some of the elements can be applied in differente positions obtaining advantages in some cases, but finally the process is a sequence.

The same happens in PS when many mask layers are used. I find it difficult to believe that PS summarizes all of them before applying them to the image, avoiding error propagation for rounding. Layer adjustments are applied one after another; but still 16 bit (actually 15) is still good enough to keep a high level of quality in the results.
Title: Your Curves
Post by: digitaldog on August 02, 2007, 01:35:39 PM
Quote
What's the difference between playing with ACR's curves until you get the desired result, and playing with a mask layer in PS until you get the desired result? is the first non-destructive and the second destructive? If so I disagree with this.

One takes the Raw data, a set of instructions and builds new, virgin pixels. The other takes existing rendered pixels and alters their numbers.

One works in linear high bit color space, the other may work in high bit, but almost always in a gamma corrected space.

Quote
ACR is not going to perform all its adjustments at a time over the RAW file.

The Raw remains untouched and is only used to build a set of colored pixels that didn't exist. Not the case with the original and existing pixels.
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 01:50:35 PM
Quote
One takes the Raw data, a set of instructions and builds new, virgin pixels. The other takes existing rendered pixels and alters their numbers.

One works in linear high bit color space, the other may work in high bit, but almost always in a gamma corrected space.
The Raw remains untouched and is only used to build a set of colored pixels that didn't exist. Not the case with the original and existing pixels.
[a href=\"index.php?act=findpost&pid=131232\"][{POST_SNAPBACK}][/a]

With "high bit" you mean 16 bits or more? integers or floating point numbers?

At the moment in which ACR curves (for instance) are plotted versus a gamma corrected histogram (the one that appears on the background in ACR), one has the feeling they are already working over a gamma corrected space. In fact it has to be so as in a linear image, information is so deeply concentrated in the low end of the histogram that curve edition is an almost impossible task.
Or you think that ACR converts the curve set by the user into what it would be in a non gamma corrected image to apply it in linear mode? I found this a really weird movement. It's nonsense to translate a curve designed to be applied on a gamma corrected image, to linear mode, to be then applied in linear mode.

Some adjustments are easier and more precisely to be performed in linear mode (WB, exposure control), some others are better performed once gamma has been corrected as they are directly related to human eye non linear response (curves, black and white points, Hue and Saturation adjust,...)
Title: Your Curves
Post by: digitaldog on August 02, 2007, 01:54:32 PM
Quote
With "high bit" you mean 16 bits or more? integers or floating point numbers?

More than 8-bits.

Quote
At the moment in which ACR curves (for instance) are plotted versus a gamma corrected histogram (the one that appears on the background), one has the feeling they are already working over a gamma corrected space.

Nope, all processing is done in a linear encoded space. Even if you import or open an existing rendered image into CR or LR, its converted to a linear encoded space (ProPhoto primaries) for all editing.
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 02:02:11 PM
Quote
Nope, all processing is done in a linear encoded space. Even if you import or open an existing rendered image into CR or LR, its converted to a linear encoded space (ProPhoto primaries) for all editing.
[a href=\"index.php?act=findpost&pid=131236\"][{POST_SNAPBACK}][/a]

well if so that is good news. But I find strange then that all user parameter adjustments in ACR (most of them conceptually and visually "gamma corrected") are translated into a linear version of themselves prior to being applied.
I am talking about the Curves, the black point, the Bright, Contrast and Saturation controls,...

BTW, do you know if ACR's noise reduction (both colour and luminance) algorithm is applied, before or after the demosaicing process?
Title: Your Curves
Post by: digitaldog on August 02, 2007, 02:09:51 PM
Quote
well if so that is good news. But I find strange then that all user parameter adjustments in ACR (most of them conceptually and visually "gamma corrected") are translated into a linear version of themselves prior to being applied.
I am talking about the Curves, the black point, the Bright, Contrast and Saturation controls,...

http://www.ppmag.com/reviews/200701_rodneycm.pdf (http://www.ppmag.com/reviews/200701_rodneycm.pdf)

Also this podcast (first half) is worth listening to:

http://photoshopnews.com/2006/07/07/lightr...isode-8-posted/ (http://photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted/)
Title: Your Curves
Post by: Guillermo Luijk on August 02, 2007, 02:23:24 PM
Quote
http://www.ppmag.com/reviews/200701_rodneycm.pdf (http://www.ppmag.com/reviews/200701_rodneycm.pdf)

Also this podcast (first half) is worth listening to:

http://photoshopnews.com/2006/07/07/lightr...isode-8-posted/ (http://photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted/)
[a href=\"index.php?act=findpost&pid=131242\"][{POST_SNAPBACK}][/a]

Interesting, specially when PS is such a gamma corrected oriented application. I would have always expected Adobe to try to leave behind the linear state of the RAW file as soon as possible in ACR/LR. Glad to see it is not like that.

Trying to edit linear images in PS is a pain, simply impossible. Just exposure control can be correctly applied.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 03:57:07 PM
Quote
http://www.ppmag.com/reviews/200701_rodneycm.pdf (http://www.ppmag.com/reviews/200701_rodneycm.pdf)

Also this podcast (first half) is worth listening to:

http://photoshopnews.com/2006/07/07/lightr...isode-8-posted/ (http://photoshopnews.com/2006/07/07/lightroom-podcast-episode-8-posted/)
[a href=\"index.php?act=findpost&pid=131242\"][{POST_SNAPBACK}][/a]

Andrew, is there a way to access the MP3 said to be on George's iDisk. I went there and it is empty. iTunes won't cut it for me.
Title: Your Curves
Post by: digitaldog on August 02, 2007, 04:03:24 PM
Quote
Andrew, is there a way to access the MP3 said to be on George's iDisk. I went there and it is empty. iTunes won't cut it for me.
[a href=\"index.php?act=findpost&pid=131261\"][{POST_SNAPBACK}][/a]

What do you mean iTunes won't cut it? What else is there? <G>

I see MP3's and MP4's on his iDisk.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 04:12:32 PM
ITunes won't cut it because I don't have an iPod. My wife does, but I can't start learning this now - no time.

I think as for the MP3, MP4 once again some fundamental issues between iDisk technology and Windows Internet Explorer - but when I open the link on Jeff's page to George's iDisk it is completely blank. Do you or anyone reading this thread know about this problem and how to cut through it?
Title: Your Curves
Post by: digitaldog on August 02, 2007, 04:23:58 PM
Quote
ITunes won't cut it because I don't have an iPod. My wife does, but I can't start learning this now - no time.

You can still use it on your computer to store and listen to the podcast (or anything else). You have speakers on that computer? Load and listen.
Title: Your Curves
Post by: Mark D Segal on August 02, 2007, 04:35:25 PM
OK, but I tried loading and it stalled. Perhaps server overload somewhere. I'll try later.
Title: Your Curves
Post by: PeterLange on August 02, 2007, 04:53:51 PM
Quote
He made the blunder of stating that, if an image was already in 8 bit, there was no need to to convert it to 16 bit for editing purposes. Jonathan Wienke proved him wrong.
[a href=\"index.php?act=findpost&pid=131223\"][{POST_SNAPBACK}][/a]
And Jonathan was right.
The secret may lie in the sequence:

After changing an 8 bit file to 16 bit, next step should be to apply some mild noise reduction depending on needs.  Even if it’s just at the threshold of visibility, this does not only smoothen and wipe out inherent posterization (not yet visible without further editing). Noise reduction as a technique of averaging fills the reservoir of real 16 bit data which don’t have an integer 8 bit equivalent anymore. Resulting files can tolerate further editing much better before showing distinguishable steps with smooth gradients.  That’s not rocket science.

Engineers might wish to reconsider this, before throwing 8 bit JPG’s in a linear gamma ProPhoto space.

Peter

--
Title: Your Curves
Post by: PeterLange on August 02, 2007, 05:36:36 PM
Quote
Peter - I can live with "slope" and "offset" instead of "percentage" and "add" ! And as you say it does help one visualize a relationship between curve shape and impact on saturation. Your concern about adjusting Luminosity in Lab space rather than RGB space is mentioned in other words on page 3 of my essay, adapted from the referenced discussion with Thomas Knoll, who also referenced corroboration from Bruce Lindbloom - so there is consensus between the three of you on this point.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=130939\")
Mark,

Could it be that there's some humor included with the last sentence. Anyway, it's fine with me .
 
 
Quote
Gloria, In principle, in Luminosity mode neither the hue nor the saturation should be affected.
[a href=\"index.php?act=findpost&pid=131087\"][{POST_SNAPBACK}][/a]
Photoshop’s HSL blend modes including Luminosity blend mode are supposed to refer to a proprietary version of the HSL color model wherein Luminosity is computed as a weighted average of green, red and blue. This accounts for many similarities with CIE Lab even though these blend modes are a pure RGB derivative.

In other words, Luminosity blend mode and the HSL double cone are different from HSB brightness and the HSB cylinder.
[a href=\"http://en.wikipedia.org/wiki/HSV_color_space]http://en.wikipedia.org/wiki/HSV_color_space[/url]
http://en.wikipedia.org/wiki/HSL_color_space (http://en.wikipedia.org/wiki/HSL_color_space)
http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf (http://www.fho-emden.de/~hoffmann/hlscone03052001.pdf)

Hence the definitions for Saturation are different.
Definitions for the Hue angle are the same.

Peter

--
Title: Your Curves
Post by: laughfta on August 02, 2007, 07:48:53 PM
Quote
In other words, Luminosity blend mode and the HSL double cone are different from HSB brightness and the HSB cylinder.
--
[a href=\"index.php?act=findpost&pid=131272\"][{POST_SNAPBACK}][/a]


Hi Peter,

I am so glad you took the time to relay this info! I did look at the Wiki site at the beginning of this thread, due in part to trying to understand the data you provided. The HSL article said that the Adobe applications used the HSV color model. Maybe you could edit it—I suspect you could have written the article! Anyway, I appreciate you clearing the path.

Gloria
Title: Your Curves
Post by: PeterLange on August 03, 2007, 05:56:46 PM
Quote
... The HSL article said that the Adobe applications used the HSV color model. Maybe you could edit it—I suspect you could have written the article! Anyway, I appreciate you clearing the path.
Hello Gloria,

Many thanks for the kind words.

As far as I can tell, Photoshop likes to mix different color models under the hood. This may or may not always make sense. I’d like to hear the thoughts of the engineers, but obviously their marketing decided for a "looks good, is good" approach. Here are some examples from my files. I’d be more than happy if someone would like to check:

With the Shadow/Highlight-tool, the main Shadows and Highlights controls are already operating in Luminosity blend mode. That’s OK with regard to the curves (plus selections) standing behind. However, the black and white clipping settings refer to normal RGB mode and the RGB color model.  Too much saturation can be added depending on Black clip percentage if it is used at all.

With the Hue/Sat.-tool, the Hue slider is always HSB (alias HSV) which in this case is the same as HSL-hue anyway. OK with me. But the Saturation slider is a very different beast:
http://luminous-landscape.com/forum/index....opic=11074&hl=# (http://luminous-landscape.com/forum/index.php?showtopic=11074&hl=#)

With the main Adjust tab in ACR, the main tonal controls such as Exposure, Shadows, Brightness and Contrast are referring to normal RGB mode and the RGB color model. – even though they’re acting on linear gamma data (and Exposure might be realized as the 9th degree of freedom during initial matrix conversion). Oh and yes, the resulting invisible curves were reported to be equipped with a hue lock. As agreed earlier there’s a competitive edge compared to Lab or Luminosity blend mode. But I’m not sure if I finally like this set-up because RGB or HSB curves are prone to effect yellow-green hues much more than other colors with regard to perception.  So let’s be tolerant by concluding that it is no Color appearance model yet. Anyway, the Saturation slider obviously acts in Saturation blend mode.  I think that’s OK.

HSB readings in Photoshop are however really HSB. And also the HSL blend modes are consistent in itself.

Hope this is of help.
Best regards, Peter

--
Title: Your Curves
Post by: laughfta on August 13, 2007, 11:18:45 PM
Hi Mark,

I would like to thank you for part two of your Curves essay. You have brought up a lot of information in a very accessible presentation. Just as importantly for the readers who are trying to evaluate occasionally conflicting opinions, you have stated your beliefs and presented your results with great courtesy and respect, which I have come to understand is both your style and your preference.

I am trying to understand something about CR. I see that several other Raw converters have 3 channel curve functions. After your work on the files in part 2, do you feel that having access to 3 channels in CR would have made a noticeable difference in outcome?
I know this entails different ways of working, so perhaps I'm asking if 3 channels in CR would have made your adjustments any easier or offered any other advantage?

Also, are you evaluating these as prints? As I suspect you are, can you provide some details in that regard?

Again, congratulations and thank you!
Title: Your Curves
Post by: Mark D Segal on August 14, 2007, 12:08:20 AM
Quote
Hi Mark,

I would like to thank you for part two of your Curves essay. You have brought up a lot of information in a very accessible presentation. Just as importantly for the readers who are trying to evaluate occasionally conflicting opinions, you have stated your beliefs and presented your results with great courtesy and respect, which I have come to understand is both your style and your preference.

I am trying to understand something about CR. I see that several other Raw converters have 3 channel curve functions. After your work on the files in part 2, do you feel that having access to 3 channels in CR would have made a noticeable difference in outcome?
I know this entails different ways of working, so perhaps I'm asking if 3 channels in CR would have made your adjustments any easier or offered any other advantage?

Also, are you evaluating these as prints? As I suspect you are, can you provide some details in that regard?

Again, congratulations and thank you!
[a href=\"index.php?act=findpost&pid=133099\"][{POST_SNAPBACK}][/a]

Thanks Gloria, glad you enjoyed the article.

First, I think we need to recognize that Curves is a User Interface. The important thing is what the math does to individual pixel values behind the Curves. And in Camera Raw, before you get to the Curves there is the Basic Tab. What math underlies those functions? And after the Curves tab there is the HSL Tab, with three possible sets of operations on each of eight colour groups. The short answer to your question I can think of is that IF CR had individual tone curves for each of the primary colours, it may be helpful, but I haven't felt any compelling need for it. That said, I do not have experience using other raw converters that are said to have such "Curves". For sure, 3 channels wouldn't make life easier, because the more the options the more the work in selecting what is best. The real issue is whether they would improve quality, and that remains an open question. Based on what I've been doing, I'm skeptical. Anyone reading this who does have comparative experience with this should jump in and tell us.

When I evaluate images on the monitor, I do so in soft-proof mode, which is about as faithful as a print. I did not print all those variants because the soft-proof is a good indicator.
Title: Your Curves
Post by: Mark D Segal on October 05, 2007, 08:09:43 AM
Those of you subscribed to this topic (and possibly others) may be interested to know that Martin Evening's latest essay was published on the Adobe Lightroom News site yesterday; it deals extensively with the subject of this thread. His findings are on the whole consistent with mine, but he derived his results in a different, and ingenious, manner. You will find his essay here: Martin Evening on LR and PS Curves (http://lightroom-news.com/2007/10/04/lightroom-versus-photoshop-curves/)
Title: Your Curves
Post by: laughfta on October 05, 2007, 08:51:52 AM
Thanks so much for pointing this out, Mark.  

I think Peter explains the saturation differences back a few posts, and goes into more detail here:  http://luminous-landscape.com/forum/index....opic=11074&hl=# (http://luminous-landscape.com/forum/index.php?showtopic=11074&hl=#)

I don't pretend to fully understand, but it's nice to think the saturation behavior/inconsistency is explainable!

Gloria
Title: Your Curves
Post by: Guillermo Luijk on October 05, 2007, 02:28:52 PM
In brief my conclusions were:
- PS Luminosity curves preserve Hue in all cases, and increase saturation where luminance is reduced, and reduce saturation where luminance is increased.
- PS Normal and ACR curves do not preserve Hue, and increase saturation in all cases.

In Martin's parrot:

(http://img106.imageshack.us/img106/6751/dibuld4.jpg)

* Point A and B: reduce luminance because of the 'S' curve (and increase Saturation in PS Lum).
* Point C: remains approximately with the same luminance after 'S' curve (and preserves saturation as well in PS Lum).
* Point D: reduces luminance because of the 'S' curve (and reduces Saturation in PS Lum).

Regarding LR, the new one:
- Seems to preserve Hue much better than PS Normal, but still modifies Hue.
- Increases saturation nearly the same as PS Normal.

Again what can be more pleasant to our eyes because of the apparent PS Luminance desaturation, can be PS Normal or LR.
However numbers say PS Luminance preserve better the original parameters.

In fact I wonder, looking at the final parrot point D, if PS Normal and LR could be losing some information (texture) because of the heavy saturation, specially PS Normal. LR seems to keep texture better in that area however.
Title: Your Curves
Post by: Mark D Segal on October 05, 2007, 03:09:37 PM
Quote
In fact I wonder, looking at the final parrot point D, if PS Normal and LR could be losing some information (texture) because of the heavy saturation, specially PS Normal. LR seems to keep texture better in that area however.
[a href=\"index.php?act=findpost&pid=144067\"][{POST_SNAPBACK}][/a]

Guillermo, this was a good part of the basis for Dan Margulis's complaint about using an RGB curve: he says the saturation boost "hoses" image detail in bright colours. The problem with his argument is that if you implement the curve shift in CR or LR and you notice the saturation of certain colourts becoming excessive, it can be scaled back down to taste, and bingo, the so-called "hosed" detail comes back, because it was never truly lost in the first place - of course one can lose it by rendering into Photoshop an over-saturated image with smothered detail, but why do that when the application allows us to avoid this error? Especially when there is a limit to the saturation of any colour that a printer can handle.

Mark