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.
