Interactive Hue Clock

If you have an idea for a new feature or other improvement to Curvemeister, this is the place to propose, discuss, and even vote on it. All suggestions are welcome, even the ones that are impossible!
leeharper_admin
Posts: 263
Joined: Tue Aug 20, 2013 2:39 pm

Postby leeharper_admin » Wed Jan 12, 2011 5:44 pm

Of course, if CM had to create localized masks to make this work in Lab, the control points would only be meaningful if CM allowed users to create multiple sets of curves without having to close/reopen the plug-in;
Is that a problem that only a standalone application could fix - or could you allow curve 'layers' within the Photoshop plug-in architecture?

So, two solutions:



  • Automatic localized masks when in Lab, CMYK, or HSB

  • Control points are only added to a user's curves if they are in RGB




I would prefer a solution that created adjustable control points, because it would be 1) a better learning tool for new users, and 2) more powerful for intermediate/advanced users - but obviously, from a coding point-of-view, the more powerful solution would be more time consuming to code.

Lee.

-default
Posts: 1916
Joined: Thu Mar 26, 2015 1:53 am

Postby -default » Wed Jan 12, 2011 7:27 pm

It's actually RGB that is more vulnerable to global effects of hue changes, not HSB and Lab.  As an example, changing the hue of an object whose color is RGB(128,128,0) would change the values of any pixel with a red value of 128, green of 128, or blue of zero.  So, for example, black objects would turn blue, and neutrals would  (oops, gotta catch a plane!!)

ggroess
Posts: 5342
Joined: Wed May 24, 2006 2:15 am
Contact:

Postby ggroess » Wed Jan 12, 2011 8:07 pm

Mike is flying off to a Scuba vacation...Seriously South....
So..For the next two weeks you are stuck with me  8)  and no new builds of the plug-in. 

Mike will most likely try to check in but do not count on it...
This is a great discussion and I know he wants it to go forward...

Greg

sjordan93436
Posts: 462
Joined: Sun Jul 11, 2010 4:23 am
Contact:

Postby sjordan93436 » Thu Jan 13, 2011 1:34 am

(Warning.  I am wayyyyy  overrrrr my head.  You guys are much better.)

From a beginner point of view..  Let me go through a narrative.

(me talking to myself)
I open a photo in PS or PSE.  (Hmm....  the faces look bad and the sky too.  )

Open CM, use RGB color space. 

Alt click a hue clock on the face and sky.  (Hmmm...  Where should those hands be pointing?)

Open hue face adjustment box- about 2 or 3 inches square.  Click on dialog box for pin target.  Select "skin"

(hmm.  the hand points to 1:30 and is 95 units long, CM says it should be somewhere around 12:30 and 60 units)

Grab the hand.  Move it left and inward toward the suggested area.  Release.  All three curves move (R,g,B) Skin clears up. There is a control point on all three curves.  It is labeled "Skin 1". 

(hmm not bad but if I move it around within his suggested box, it might be better).

Using cursor control, I tweak the points and curves.  (hmm.... not bad, what next)

(hmm..  the skin seems dark)  Bump up the luminosity slider.  All three curves move again.

Do the same for the sky, the neutrals, shadows, highlights, greenery.  (hmm...  oops, too many points and the curves have kinks.)  Manually adjust curves.

________________

Experienced or advanced users do not require this crutch, but it might help newbies.

Every point in the RGB color space has a HSB value.  Every HSB value has an RGB value.  If you move the hands of the clock from one HSB value to another HSB value, the RGB value changes.  If you change the values of a point, then one, two, or three curves move.  This is what "pinning" does. 

Mike is right.  If you drag a HSB point, it gets weird around 12:00 noon (red).  The curves go strange.

If I garbled this up, just forget this post.

ggroess
Posts: 5342
Joined: Wed May 24, 2006 2:15 am
Contact:

Postby ggroess » Thu Jan 13, 2011 2:34 am

Steve,
You have described a work flow..That is just fine with some conditions....
The real trouble is that when you start adjusting based on a hue or any other point you move entire sections of the curve.  This has implications when you switch back to RGB from the HSB adjustment or convert it on the fly...

Your questions are valid...What color should the sky be...you can sample 100 sky images and get 100 different answers from almost white to a deep indigo and frankly any color in between including Green...

Grab the Hue hand...Well that is where the discussion is currently at...The problem with "grabbing the hand" as it were is that you bring all of the pixels in the image with the same HSB value with you when you adjust not just the local area of the image that you want to fix.  Yes they relate to an RGB pixel but many times there is not an exact match...There is some math in the mix that can make a mess of this...  and as Mike started to describe...If you have a point that is (128, 128, 0) in RGB and you "grab that point and move it...to say (128,128,128) all of the B values that are 0 will move to 128 across the entire image...if I read his logic right... 

There is a program out there that Art told us about in the last class...it's an older program and well I don't quite remember the name but it allowed similar adjustments.  Trouble was it had limits...

I'll see what I can dig up from the last class...

Greg

mikemeister_admin
Posts: 4927
Joined: Fri Sep 20, 2013 8:29 pm

Postby mikemeister_admin » Thu Jan 13, 2011 12:22 pm

This seemed so simple a few days ago ;)

Taking a step back... When (and why) do we use Hue Clocks?

When: After we have set the shadow, highlight, and neutral (if a neutral is present; we use an appropriate color pin if not).

Why: To check that particular 'memory' colors fall into an expected range. The memory colors that we are likely  to check are: skin, grass/foliage, sky, fruit/vegetables.

If a memory color is present within an image, we use the Hue Clock to check whether it is in the right place on the clock. As Steve mentions, we know - for example - that skin tones should fall close to 12:30 on the Hue Clock.

Having already set our shadow, highlight, and neutral point, memory colors within the image should be very close to where they need to be on the clock. Skin might be slightly too magenta, or too yellow - but having set our shadow, highlight and neutral, skin tones are unlikely to be cyan (for example).

Therefore, if we move the position of the Hue Clock's hand, we shouldn't need to move it very far.

As a practical example, one of the recent challenge images was a bowl of fruit. In that particular image there were some Blackberries. Greg stated that those blackberries should be more blue than red. I noticed that in my initial correction of that image, the HSB values for the blackberries fell around: H34 S37 B19. I was happy with the saturation and brightness (37 and 19) of the blackberries, but clearly a Hue value of 34 degrees was too red.

In the Photoshop color picker I have just checked to see what a Hue correction would do to the RGB values.

Initial HSB values of H34 S37 B19 created RGB values of R49 G41 B31. I then made a Hue-only adjustment to the color - adding blue (I was trying to create a nice 'Blackberry' color). This adjustment created HSB values of: H268 S37 B19 (a Hue rotation of 66 degrees).

A 66 degree Hue adjustment had a very small effect on my RGB values. The RGB values changed from R49 G41 B31 to R40 G31 B49.

Whilst I accept that "If you have a point that is (128, 128, 0) in RGB and you "grab that point and move it...to say (128,128,128) all of the B values that are 0 will move to 128 across the entire image" - I just don't see anyone making such extreme adjustments.

Whilst such a move (R128 G128 B0 to R128 G128 B128) would mess up the image, anyone trying to turn something from mid-green to mid-grey in RGB is asking for trouble ;) It's simply a case of using the right tool for the right job. Drastically changing the color of something (a car for example) is the preserve of Lab - as is covered on CM 101.

My conception of an interactive Hue Clock is that the moves would be fairly small (as with my Blackberry example). Also, I think that it makes sense that these adjustments only work in RGB. Why? Setting shadows, highlights, and a neutral point will remove a uniform color cast from an image. Any color casts remaining will be restricted to specific brightness ranges (i.e., there might be a cast that only affects the quarter-tones). If that is the case, then as Greg mentions - if we work in anything other than RGB we won't be able to restrict our correction to the appropriate brightness range.

I'm hopeful that we can all take this forward - please keep pushing on this...

All best,
Lee.

ggroess
Posts: 5342
Joined: Wed May 24, 2006 2:15 am
Contact:

Postby ggroess » Thu Jan 13, 2011 2:14 pm

Lee,
I think you have finally gotten close to how this would work "real world".
I'll keep thinking about this as well...

Greg

leeharper_admin
Posts: 263
Joined: Tue Aug 20, 2013 2:39 pm

Postby leeharper_admin » Thu Jan 13, 2011 2:32 pm

That would be great Greg - thanks so much :)

I've been thinking about how the Saturation slider is Lab-only, so I don't think that this being RGB-only is necessarily a problem - it's just a case of "the right tool for the right job". Really, it reinforces what is taught on CM 101 and within the CM manual - certain color modes have particular strengths...

Cheers,
Lee.


Return to “Vote on and Discuss New Features”

Who is online

Users browsing this forum: No registered users and 3 guests