Your Curves

[Guillermo Luijk]

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.

[Mark D Segal]

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.

[Guillermo Luijk]

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:


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):


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"

[Mark D Segal]

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"
[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.

[Guillermo Luijk]

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]

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?):
 

 
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][/url]
 

 

And we get this pic:
 

 

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

(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:
 

 
Once we have the curves, we can apply them to some other picture (http://www.pbase.com/gluijk/image/68292170) obtaining the same feeling (histograms must be similarly distributed of course):
 

[laughfta]

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.

[PeterLange]

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

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

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

--

[Guillermo Luijk]

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   :


(me testing weaponry)

Completely agree Peter.

[Mark D Segal]

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.

[Mark D Segal]

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

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

[laughfta]

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

[Mark D Segal]

I found that this website, (there are probably others) 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!  

[Guillermo Luijk]

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.

[Mark D Segal]

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?

[Guillermo Luijk]

Here are the examples of individual H, S and B modifications.
This is the original image:




[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):



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:




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



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



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

[Eric Myrvaagnes]

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.

[Mark D Segal]

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

[Mark D Segal]

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.

[laughfta]

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

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.

[Mark D Segal]

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.