PS CS3 puzzler - non-linear behaviour in gradients
Members
Search
Help
Register
Login
Home
:: E-mail to friend 
1) In PS, follow the instructions at:
http://www.luminous-landscape.com/essays/test-charts.shtml and generate
the Granger chart as shown. Oddly, it has a strange distribution given
that the gradient layer is linear top-to-bottom. What is creating those
diagonals in the chart?
2) For comparison, see;
http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
--
gmail originated posts are filtered due to spam.
  |
  |
> Can anyone shed light on this?
>
> 1) In PS, follow the instructions at:
>
> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
> the Granger chart as shown. Oddly, it has a strange distribution given
> that the gradient layer is linear top-to-bottom. What is creating those
> diagonals in the chart?
>
> 2) For comparison, see;
>
> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>
>
Perhaps simply because the individual gradients themselves are
non-linear, compared to gradients applied by other photo-editing programs.
Gimp "colorcube analysis" shows the non-linearity of the gradients here:
http://i49.tinypic.com/25jxge9.png
Gradients produced in Gimp (the same as gradients produced in other
programs) are on the left).
| |
|
On Mon, 08 Feb 2010 09:34:07 +1300, Me wrote:
> Alan Browne wrote:
>> Can anyone shed light on this?
>>
>> 1) In PS, follow the instructions at:
>>
>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>> the Granger chart as shown. Oddly, it has a strange distribution given
>> that the gradient layer is linear top-to-bottom. What is creating those
>> diagonals in the chart?
>>
>> 2) For comparison, see;
>>
>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>
>>
> Perhaps simply because the individual gradients themselves are
> non-linear, compared to gradients applied by other photo-editing programs.
> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
> http://i49.tinypic.com/25jxge9.png
> Gradients produced in Gimp (the same as gradients produced in other
> programs) are on the left).
Photoshop can provide linear gradients, but not by default. Use
Photoshop's gradient editor, set the smoothing parameter to zero, and no
dither. Why did they do it this way? Why ask why.
--
Mike Russell - http://www.curvemeister.com
> Alan Browne wrote:
>> Can anyone shed light on this?
>>
>> 1) In PS, follow the instructions at:
>>
>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>> the Granger chart as shown. Oddly, it has a strange distribution given
>> that the gradient layer is linear top-to-bottom. What is creating those
>> diagonals in the chart?
>>
>> 2) For comparison, see;
>>
>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>
>>
> Perhaps simply because the individual gradients themselves are
> non-linear, compared to gradients applied by other photo-editing programs.
> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
> http://i49.tinypic.com/25jxge9.png
> Gradients produced in Gimp (the same as gradients produced in other
> programs) are on the left).
Photoshop can provide linear gradients, but not by default. Use
Photoshop's gradient editor, set the smoothing parameter to zero, and no
dither. Why did they do it this way? Why ask why.
--
Mike Russell - http://www.curvemeister.com
| |
|
Mike Russell wrote:
> On Mon, 08 Feb 2010 09:34:07 +1300, Me wrote:
>
>> Alan Browne wrote:
>>> Can anyone shed light on this?
>>>
>>> 1) In PS, follow the instructions at:
>>>
>>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>>> the Granger chart as shown. Oddly, it has a strange distribution given
>>> that the gradient layer is linear top-to-bottom. What is creating those
>>> diagonals in the chart?
>>>
>>> 2) For comparison, see;
>>>
>>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>>
>>>
>> Perhaps simply because the individual gradients themselves are
>> non-linear, compared to gradients applied by other photo-editing programs.
>> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
>> http://i49.tinypic.com/25jxge9.png
>> Gradients produced in Gimp (the same as gradients produced in other
>> programs) are on the left).
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
>
Thanks - that works - problem solved.
Now perhaps someone can advise Ludicrous Landscape's editors with
instructions on how to make a "proper" Granger chart.
> On Mon, 08 Feb 2010 09:34:07 +1300, Me wrote:
>
>> Alan Browne wrote:
>>> Can anyone shed light on this?
>>>
>>> 1) In PS, follow the instructions at:
>>>
>>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>>> the Granger chart as shown. Oddly, it has a strange distribution given
>>> that the gradient layer is linear top-to-bottom. What is creating those
>>> diagonals in the chart?
>>>
>>> 2) For comparison, see;
>>>
>>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>>
>>>
>> Perhaps simply because the individual gradients themselves are
>> non-linear, compared to gradients applied by other photo-editing programs.
>> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
>> http://i49.tinypic.com/25jxge9.png
>> Gradients produced in Gimp (the same as gradients produced in other
>> programs) are on the left).
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
>
Thanks - that works - problem solved.
Now perhaps someone can advise Ludicrous Landscape's editors with
instructions on how to make a "proper" Granger chart.
| |
|
On 10-02-07 19:40 , Mike Russell wrote:
> On Mon, 08 Feb 2010 09:34:07 +1300, Me wrote:
>
>> Alan Browne wrote:
>>> Can anyone shed light on this?
>>>
>>> 1) In PS, follow the instructions at:
>>>
>>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>>> the Granger chart as shown. Oddly, it has a strange distribution given
>>> that the gradient layer is linear top-to-bottom. What is creating those
>>> diagonals in the chart?
>>>
>>> 2) For comparison, see;
>>>
>>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>>
>>>
>> Perhaps simply because the individual gradients themselves are
>> non-linear, compared to gradients applied by other photo-editing programs.
>> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
>> http://i49.tinypic.com/25jxge9.png
>> Gradients produced in Gimp (the same as gradients produced in other
>> programs) are on the left).
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
Doesn't work here - I turned off dither (for spectrum and gradient) and
I set the smooth to zero for both and for either one. I get the same
non-linear plot.
Fresh eyes tomorrow.
--
gmail originated posts are filtered due to spam.
> On Mon, 08 Feb 2010 09:34:07 +1300, Me wrote:
>
>> Alan Browne wrote:
>>> Can anyone shed light on this?
>>>
>>> 1) In PS, follow the instructions at:
>>>
>>> http://www.luminous-landscape.com/essays/test-charts.shtml and generate
>>> the Granger chart as shown. Oddly, it has a strange distribution given
>>> that the gradient layer is linear top-to-bottom. What is creating those
>>> diagonals in the chart?
>>>
>>> 2) For comparison, see;
>>>
>>> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
>>>
>>>
>> Perhaps simply because the individual gradients themselves are
>> non-linear, compared to gradients applied by other photo-editing programs.
>> Gimp "colorcube analysis" shows the non-linearity of the gradients here:
>> http://i49.tinypic.com/25jxge9.png
>> Gradients produced in Gimp (the same as gradients produced in other
>> programs) are on the left).
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
Doesn't work here - I turned off dither (for spectrum and gradient) and
I set the smooth to zero for both and for either one. I get the same
non-linear plot.
Fresh eyes tomorrow.
--
gmail originated posts are filtered due to spam.
| |
|
On 10-02-07 19:40 , Mike Russell wrote:
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
Hi Mike, I followed your instructions, but I do not get the 'standard'
Granger. I set no dither for both the spectrum and the gradient. I set
smoothing to 0 (for either and both). But I do not get the Granger w/o
the artifacts. Any idea what I'm missing?
(If I do this with "HardLight" instead of Luminosity, it does work).
--
gmail originated posts are filtered due to spam.
>
> Photoshop can provide linear gradients, but not by default. Use
> Photoshop's gradient editor, set the smoothing parameter to zero, and no
> dither. Why did they do it this way? Why ask why.
Hi Mike, I followed your instructions, but I do not get the 'standard'
Granger. I set no dither for both the spectrum and the gradient. I set
smoothing to 0 (for either and both). But I do not get the Granger w/o
the artifacts. Any idea what I'm missing?
(If I do this with "HardLight" instead of Luminosity, it does work).
--
gmail originated posts are filtered due to spam.
| |
|
On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
> On 10-02-07 19:40 , Mike Russell wrote:
>
>>
>> Photoshop can provide linear gradients, but not by default. Use
>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>> dither. Why did they do it this way? Why ask why.
>
> Hi Mike, I followed your instructions, but I do not get the 'standard'
> Granger. I set no dither for both the spectrum and the gradient. I set
> smoothing to 0 (for either and both). But I do not get the Granger w/o
> the artifacts. Any idea what I'm missing?
>
> (If I do this with "HardLight" instead of Luminosity, it does work).
Photoshop is giving an accurate result in both cases. The hard light layer
will darken RGB values of the target layer for values less than 128, and
lighten it for values greater than 128. The result is an artifact free
Granger chart, similar to what you see from other products.
Luminosity is a hue dependent function, weighted by the luminosity values,
with b the darkest and green the lightest of the rgb primaries. It's not
possible, in RGB space, for a pure blue to have a luminosity greater than
11%. Above that it is necessary to add white to the blue to get the value
dictated by the luminosity layer.
The zig zag artifact has six peaks, one for each primary of the HSL
hexcone. Another way to think of it is a plot of the luminosity of various
mixtures of r, g, and b, with blue being the darkest, and yellow being the
lightest. Or think of it as a flattened cylindrical projection of the HSL
hexcone.
Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
from luma" operation shown in the geometric derivation illustration is what
is happening with Photoshop's luminosity mode.
---
Mike Russell - http://www.curvemeister.com
> On 10-02-07 19:40 , Mike Russell wrote:
>
>>
>> Photoshop can provide linear gradients, but not by default. Use
>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>> dither. Why did they do it this way? Why ask why.
>
> Hi Mike, I followed your instructions, but I do not get the 'standard'
> Granger. I set no dither for both the spectrum and the gradient. I set
> smoothing to 0 (for either and both). But I do not get the Granger w/o
> the artifacts. Any idea what I'm missing?
>
> (If I do this with "HardLight" instead of Luminosity, it does work).
Photoshop is giving an accurate result in both cases. The hard light layer
will darken RGB values of the target layer for values less than 128, and
lighten it for values greater than 128. The result is an artifact free
Granger chart, similar to what you see from other products.
Luminosity is a hue dependent function, weighted by the luminosity values,
with b the darkest and green the lightest of the rgb primaries. It's not
possible, in RGB space, for a pure blue to have a luminosity greater than
11%. Above that it is necessary to add white to the blue to get the value
dictated by the luminosity layer.
The zig zag artifact has six peaks, one for each primary of the HSL
hexcone. Another way to think of it is a plot of the luminosity of various
mixtures of r, g, and b, with blue being the darkest, and yellow being the
lightest. Or think of it as a flattened cylindrical projection of the HSL
hexcone.
Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
from luma" operation shown in the geometric derivation illustration is what
is happening with Photoshop's luminosity mode.
---
Mike Russell - http://www.curvemeister.com
| |
|
On 10-02-09 23:52 , Mike Russell wrote:
> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>
>> On 10-02-07 19:40 , Mike Russell wrote:
>>
>>>
>>> Photoshop can provide linear gradients, but not by default. Use
>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>> dither. Why did they do it this way? Why ask why.
>>
>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>> Granger. I set no dither for both the spectrum and the gradient. I set
>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>> the artifacts. Any idea what I'm missing?
>>
>> (If I do this with "HardLight" instead of Luminosity, it does work).
>
> Photoshop is giving an accurate result in both cases. The hard light layer
> will darken RGB values of the target layer for values less than 128, and
> lighten it for values greater than 128. The result is an artifact free
> Granger chart, similar to what you see from other products.
>
> Luminosity is a hue dependent function, weighted by the luminosity values,
> with b the darkest and green the lightest of the rgb primaries. It's not
> possible, in RGB space, for a pure blue to have a luminosity greater than
> 11%. Above that it is necessary to add white to the blue to get the value
> dictated by the luminosity layer.
>
> The zig zag artifact has six peaks, one for each primary of the HSL
> hexcone. Another way to think of it is a plot of the luminosity of various
> mixtures of r, g, and b, with blue being the darkest, and yellow being the
> lightest. Or think of it as a flattened cylindrical projection of the HSL
> hexcone.
I sort of got all that from the result (without the fine disection you
give it of course).
>
> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
> from luma" operation shown in the geometric derivation illustration is what
> is happening with Photoshop's luminosity mode.
I really wanted to know why if I'm following your instructions, I'm not
getting your result. Someone else did. ("Me" but not me).
eg: I'm doing something wrong in the process.
--
gmail originated posts are filtered due to spam.
> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>
>> On 10-02-07 19:40 , Mike Russell wrote:
>>
>>>
>>> Photoshop can provide linear gradients, but not by default. Use
>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>> dither. Why did they do it this way? Why ask why.
>>
>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>> Granger. I set no dither for both the spectrum and the gradient. I set
>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>> the artifacts. Any idea what I'm missing?
>>
>> (If I do this with "HardLight" instead of Luminosity, it does work).
>
> Photoshop is giving an accurate result in both cases. The hard light layer
> will darken RGB values of the target layer for values less than 128, and
> lighten it for values greater than 128. The result is an artifact free
> Granger chart, similar to what you see from other products.
>
> Luminosity is a hue dependent function, weighted by the luminosity values,
> with b the darkest and green the lightest of the rgb primaries. It's not
> possible, in RGB space, for a pure blue to have a luminosity greater than
> 11%. Above that it is necessary to add white to the blue to get the value
> dictated by the luminosity layer.
>
> The zig zag artifact has six peaks, one for each primary of the HSL
> hexcone. Another way to think of it is a plot of the luminosity of various
> mixtures of r, g, and b, with blue being the darkest, and yellow being the
> lightest. Or think of it as a flattened cylindrical projection of the HSL
> hexcone.
I sort of got all that from the result (without the fine disection you
give it of course).
>
> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
> from luma" operation shown in the geometric derivation illustration is what
> is happening with Photoshop's luminosity mode.
I really wanted to know why if I'm following your instructions, I'm not
getting your result. Someone else did. ("Me" but not me).
eg: I'm doing something wrong in the process.
--
gmail originated posts are filtered due to spam.
| |
|
On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
> I really wanted to know why if I'm following your instructions, I'm not
> getting your result. Someone else did. ("Me" but not me).
>
> eg: I'm doing something wrong in the process.
I think they were referring to the gradient not having a clean histogram,
rather than the result with the granger chart. The granger chart will
have the artifacts you mention for Luminosity, because of the relationship
of hue and luminosity, but not for other modes such as hard light.
--
Mike Russell - http://www.curvemeister.com
> I really wanted to know why if I'm following your instructions, I'm not
> getting your result. Someone else did. ("Me" but not me).
>
> eg: I'm doing something wrong in the process.
I think they were referring to the gradient not having a clean histogram,
rather than the result with the granger chart. The granger chart will
have the artifacts you mention for Luminosity, because of the relationship
of hue and luminosity, but not for other modes such as hard light.
--
Mike Russell - http://www.curvemeister.com
| |
|
On 10-02-10 17:25 , Mike Russell wrote:
> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>
>> I really wanted to know why if I'm following your instructions, I'm not
>> getting your result. Someone else did. ("Me" but not me).
>>
>> eg: I'm doing something wrong in the process.
>
> I think they were referring to the gradient not having a clean histogram,
> rather than the result with the granger chart. The granger chart will
> have the artifacts you mention for Luminosity, because of the relationship
> of hue and luminosity, but not for other modes such as hard light.
You're not hearing me.
"Me" (a different poster) followed your suggestion for turning off
dithering and setting smoothing to 0. Using Luminosity He got a
nominally correct Granger.
I (that is me, not "Me") followed your instructions and did not get the
nominally correct Granger using Luminosity (I did with "Hardlight").
What could account for the different result?
--
gmail originated posts are filtered due to spam.
> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>
>> I really wanted to know why if I'm following your instructions, I'm not
>> getting your result. Someone else did. ("Me" but not me).
>>
>> eg: I'm doing something wrong in the process.
>
> I think they were referring to the gradient not having a clean histogram,
> rather than the result with the granger chart. The granger chart will
> have the artifacts you mention for Luminosity, because of the relationship
> of hue and luminosity, but not for other modes such as hard light.
You're not hearing me.
"Me" (a different poster) followed your suggestion for turning off
dithering and setting smoothing to 0. Using Luminosity He got a
nominally correct Granger.
I (that is me, not "Me") followed your instructions and did not get the
nominally correct Granger using Luminosity (I did with "Hardlight").
What could account for the different result?
--
gmail originated posts are filtered due to spam.
| |
|
On Wed, 10 Feb 2010 18:15:55 -0500, Alan Browne wrote:
> On 10-02-10 17:25 , Mike Russell wrote:
>> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>>
>>> I really wanted to know why if I'm following your instructions, I'm not
>>> getting your result. Someone else did. ("Me" but not me).
>>>
>>> eg: I'm doing something wrong in the process.
>>
>> I think they were referring to the gradient not having a clean histogram,
>> rather than the result with the granger chart. The granger chart will
>> have the artifacts you mention for Luminosity, because of the relationship
>> of hue and luminosity, but not for other modes such as hard light.
>
>
> You're not hearing me.
>
> "Me" (a different poster) followed your suggestion for turning off
> dithering and setting smoothing to 0. Using Luminosity He got a
> nominally correct Granger.
>
> I (that is me, not "Me") followed your instructions and did not get the
> nominally correct Granger using Luminosity (I did with "Hardlight").
>
> What could account for the different result?
I think I'm hearing both you, and Me. I guess we'll just have to wait for
Me to clear up the matter.
--
Mike Russell - http://www.curvemeister.com
> On 10-02-10 17:25 , Mike Russell wrote:
>> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>>
>>> I really wanted to know why if I'm following your instructions, I'm not
>>> getting your result. Someone else did. ("Me" but not me).
>>>
>>> eg: I'm doing something wrong in the process.
>>
>> I think they were referring to the gradient not having a clean histogram,
>> rather than the result with the granger chart. The granger chart will
>> have the artifacts you mention for Luminosity, because of the relationship
>> of hue and luminosity, but not for other modes such as hard light.
>
>
> You're not hearing me.
>
> "Me" (a different poster) followed your suggestion for turning off
> dithering and setting smoothing to 0. Using Luminosity He got a
> nominally correct Granger.
>
> I (that is me, not "Me") followed your instructions and did not get the
> nominally correct Granger using Luminosity (I did with "Hardlight").
>
> What could account for the different result?
I think I'm hearing both you, and Me. I guess we'll just have to wait for
Me to clear up the matter.
--
Mike Russell - http://www.curvemeister.com
| |
|
On 2/9/2010 8:52 PM, Mike Russell wrote:
> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>
>> On 10-02-07 19:40 , Mike Russell wrote:
>>
>>>
>>> Photoshop can provide linear gradients, but not by default. Use
>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>> dither. Why did they do it this way? Why ask why.
>>
>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>> Granger. I set no dither for both the spectrum and the gradient. I set
>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>> the artifacts. Any idea what I'm missing?
>>
>> (If I do this with "HardLight" instead of Luminosity, it does work).
>
> Photoshop is giving an accurate result in both cases. The hard light layer
> will darken RGB values of the target layer for values less than 128, and
> lighten it for values greater than 128. The result is an artifact free
> Granger chart, similar to what you see from other products.
Hard light is not exactly the same, I managed to make a matching chart
with Screen mode above 128 and Multiply mode below 128. That's what most
programs call luminosity. The question is why the different approaches?
> Luminosity is a hue dependent function, weighted by the luminosity values,
> with b the darkest and green the lightest of the rgb primaries. It's not
> possible, in RGB space, for a pure blue to have a luminosity greater than
> 11%. Above that it is necessary to add white to the blue to get the value
> dictated by the luminosity layer.
>
> The zig zag artifact has six peaks, one for each primary of the HSL
> hexcone. Another way to think of it is a plot of the luminosity of various
> mixtures of r, g, and b, with blue being the darkest, and yellow being the
> lightest. Or think of it as a flattened cylindrical projection of the HSL
> hexcone.
>
> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
> from luma" operation shown in the geometric derivation illustration is what
> is happening with Photoshop's luminosity mode.
http://en.wikipedia.org/wiki/HSL_and_HSV
That first illustration looks a lot like what we are discussing here.
Math for luma figured into the best explanation I could find. That
explained the asymetrical humps in the PS version with 'luminance' but
what is the scheme that shows symmetrical peaks in the diagram and why
did the other programs chose that math for what they call luminance? The
big difference I saw was that if you convert to grayscale, the PS
version goes to a smooth transition where the other shows the colors for
their lightness: yellow is light, blue is dark, green and red
intermediate. The PS version preserves grayscale lightness/darkness as
can be seen in the last frame of the set below.
Here's examples and the blending modes used to achieve them:
http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
I also tried it in lab mode, out of curiosity.
#2 was pasted together from using those two blending modes for top &
bottom, then squishing them back to fit in a square. Most programs work
this way for what they call luminance. #1 is the default PS behavior.
At first I was just curious but I do use the luminance blending mode
pretty often on contrast type adjustment layers so that I can tweak
curves or levels without changing saturation. Normally a contrast
increase will give a more saturated image and I often like to keep
things subtle. I'm aware that lab mode is the better way to do this but
it's a hassle and I'm just not in the habit of working in lab. Is the
luminosity blend mode going to mess up my colors? Like if curves darken
a blue area, it looks like that might turn pale. Or maybe this really is
the better way to do it and actually preserves luminosity better.
> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>
>> On 10-02-07 19:40 , Mike Russell wrote:
>>
>>>
>>> Photoshop can provide linear gradients, but not by default. Use
>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>> dither. Why did they do it this way? Why ask why.
>>
>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>> Granger. I set no dither for both the spectrum and the gradient. I set
>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>> the artifacts. Any idea what I'm missing?
>>
>> (If I do this with "HardLight" instead of Luminosity, it does work).
>
> Photoshop is giving an accurate result in both cases. The hard light layer
> will darken RGB values of the target layer for values less than 128, and
> lighten it for values greater than 128. The result is an artifact free
> Granger chart, similar to what you see from other products.
Hard light is not exactly the same, I managed to make a matching chart
with Screen mode above 128 and Multiply mode below 128. That's what most
programs call luminosity. The question is why the different approaches?
> Luminosity is a hue dependent function, weighted by the luminosity values,
> with b the darkest and green the lightest of the rgb primaries. It's not
> possible, in RGB space, for a pure blue to have a luminosity greater than
> 11%. Above that it is necessary to add white to the blue to get the value
> dictated by the luminosity layer.
>
> The zig zag artifact has six peaks, one for each primary of the HSL
> hexcone. Another way to think of it is a plot of the luminosity of various
> mixtures of r, g, and b, with blue being the darkest, and yellow being the
> lightest. Or think of it as a flattened cylindrical projection of the HSL
> hexcone.
>
> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
> from luma" operation shown in the geometric derivation illustration is what
> is happening with Photoshop's luminosity mode.
http://en.wikipedia.org/wiki/HSL_and_HSV
That first illustration looks a lot like what we are discussing here.
Math for luma figured into the best explanation I could find. That
explained the asymetrical humps in the PS version with 'luminance' but
what is the scheme that shows symmetrical peaks in the diagram and why
did the other programs chose that math for what they call luminance? The
big difference I saw was that if you convert to grayscale, the PS
version goes to a smooth transition where the other shows the colors for
their lightness: yellow is light, blue is dark, green and red
intermediate. The PS version preserves grayscale lightness/darkness as
can be seen in the last frame of the set below.
Here's examples and the blending modes used to achieve them:
http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
I also tried it in lab mode, out of curiosity.
#2 was pasted together from using those two blending modes for top &
bottom, then squishing them back to fit in a square. Most programs work
this way for what they call luminance. #1 is the default PS behavior.
At first I was just curious but I do use the luminance blending mode
pretty often on contrast type adjustment layers so that I can tweak
curves or levels without changing saturation. Normally a contrast
increase will give a more saturated image and I often like to keep
things subtle. I'm aware that lab mode is the better way to do this but
it's a hassle and I'm just not in the habit of working in lab. Is the
luminosity blend mode going to mess up my colors? Like if curves darken
a blue area, it looks like that might turn pale. Or maybe this really is
the better way to do it and actually preserves luminosity better.
| |
|
On Thu, 11 Feb 2010 11:02:52 -0800, Paul Furman wrote:
> On 2/9/2010 8:52 PM, Mike Russell wrote:
>> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>>
>>> On 10-02-07 19:40 , Mike Russell wrote:
>>>
>>>>
>>>> Photoshop can provide linear gradients, but not by default. Use
>>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>>> dither. Why did they do it this way? Why ask why.
>>>
>>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>>> Granger. I set no dither for both the spectrum and the gradient. I set
>>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>>> the artifacts. Any idea what I'm missing?
>>>
>>> (If I do this with "HardLight" instead of Luminosity, it does work).
>>
>> Photoshop is giving an accurate result in both cases. The hard light layer
>> will darken RGB values of the target layer for values less than 128, and
>> lighten it for values greater than 128. The result is an artifact free
>> Granger chart, similar to what you see from other products.
>
> Hard light is not exactly the same, I managed to make a matching chart
> with Screen mode above 128 and Multiply mode below 128. That's what most
> programs call luminosity. The question is why the different approaches?
>
>
>> Luminosity is a hue dependent function, weighted by the luminosity values,
>> with b the darkest and green the lightest of the rgb primaries. It's not
>> possible, in RGB space, for a pure blue to have a luminosity greater than
>> 11%. Above that it is necessary to add white to the blue to get the value
>> dictated by the luminosity layer.
>>
>> The zig zag artifact has six peaks, one for each primary of the HSL
>> hexcone. Another way to think of it is a plot of the luminosity of various
>> mixtures of r, g, and b, with blue being the darkest, and yellow being the
>> lightest. Or think of it as a flattened cylindrical projection of the HSL
>> hexcone.
>>
>> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
>> from luma" operation shown in the geometric derivation illustration is what
>> is happening with Photoshop's luminosity mode.
>
> http://en.wikipedia.org/wiki/HSL_and_HSV
> That first illustration looks a lot like what we are discussing here.
>
>
> Math for luma figured into the best explanation I could find. That
> explained the asymetrical humps in the PS version with 'luminance' but
> what is the scheme that shows symmetrical peaks in the diagram and why
> did the other programs chose that math for what they call luminance?
I think the other programs simply multiplied the RGB channels equally by
the grayscale value over 255.
> The
> big difference I saw was that if you convert to grayscale, the PS
> version goes to a smooth transition where the other shows the colors for
> their lightness: yellow is light, blue is dark, green and red
> intermediate. The PS version preserves grayscale lightness/darkness as
> can be seen in the last frame of the set below.
>
> Here's examples and the blending modes used to achieve them:
> http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
> I also tried it in lab mode, out of curiosity.
> #2 was pasted together from using those two blending modes for top &
> bottom, then squishing them back to fit in a square. Most programs work
> this way for what they call luminance. #1 is the default PS behavior.
>
> At first I was just curious but I do use the luminance blending mode
> pretty often on contrast type adjustment layers so that I can tweak
> curves or levels without changing saturation. Normally a contrast
> increase will give a more saturated image and I often like to keep
> things subtle. I'm aware that lab mode is the better way to do this but
> it's a hassle and I'm just not in the habit of working in lab. Is the
> luminosity blend mode going to mess up my colors? Like if curves darken
> a blue area, it looks like that might turn pale. Or maybe this really is
> the better way to do it and actually preserves luminosity better.
It all depends on the image - the important thing is to be quick enough in
your workflow to try it one way, then another, and compare results. Dan
Margulis's Picture Postcard workflow is an example of this, though it is
done with a combination of curves and Photoshop's apply image command.
Speaking of just blues in the context of sky - most viewers like skies to
be dark and saturated, so yes, applying a luminosity layer to a blue sky
would generally lighten it. In this case you would use apply image, uaing
the red channel in luminosity mode, and use a curve to boost the effect
further. If there are important foreground elements, then use the green or
blue channels (or the b channel in Lab) as a mask.
There are dozens of ways to use curves, masking, apply image, layer
blending, and other functions, each of which adds a bit of punch to your
image as far as color or detail.
BTW - on your flickr page you pose the question of why use a Granger chart
at all - for me it's a curiousity item that is helpful for understanding
the RGB color space, but nothing more than that. As an artificial
gradient, it is of no relevance to photography or printing related to
photography.
--
Mike Russell - http://www.curvemeister.com
> On 2/9/2010 8:52 PM, Mike Russell wrote:
>> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>>
>>> On 10-02-07 19:40 , Mike Russell wrote:
>>>
>>>>
>>>> Photoshop can provide linear gradients, but not by default. Use
>>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>>> dither. Why did they do it this way? Why ask why.
>>>
>>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>>> Granger. I set no dither for both the spectrum and the gradient. I set
>>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>>> the artifacts. Any idea what I'm missing?
>>>
>>> (If I do this with "HardLight" instead of Luminosity, it does work).
>>
>> Photoshop is giving an accurate result in both cases. The hard light layer
>> will darken RGB values of the target layer for values less than 128, and
>> lighten it for values greater than 128. The result is an artifact free
>> Granger chart, similar to what you see from other products.
>
> Hard light is not exactly the same, I managed to make a matching chart
> with Screen mode above 128 and Multiply mode below 128. That's what most
> programs call luminosity. The question is why the different approaches?
>
>
>> Luminosity is a hue dependent function, weighted by the luminosity values,
>> with b the darkest and green the lightest of the rgb primaries. It's not
>> possible, in RGB space, for a pure blue to have a luminosity greater than
>> 11%. Above that it is necessary to add white to the blue to get the value
>> dictated by the luminosity layer.
>>
>> The zig zag artifact has six peaks, one for each primary of the HSL
>> hexcone. Another way to think of it is a plot of the luminosity of various
>> mixtures of r, g, and b, with blue being the darkest, and yellow being the
>> lightest. Or think of it as a flattened cylindrical projection of the HSL
>> hexcone.
>>
>> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
>> from luma" operation shown in the geometric derivation illustration is what
>> is happening with Photoshop's luminosity mode.
>
> http://en.wikipedia.org/wiki/HSL_and_HSV
> That first illustration looks a lot like what we are discussing here.
>
>
> Math for luma figured into the best explanation I could find. That
> explained the asymetrical humps in the PS version with 'luminance' but
> what is the scheme that shows symmetrical peaks in the diagram and why
> did the other programs chose that math for what they call luminance?
I think the other programs simply multiplied the RGB channels equally by
the grayscale value over 255.
> The
> big difference I saw was that if you convert to grayscale, the PS
> version goes to a smooth transition where the other shows the colors for
> their lightness: yellow is light, blue is dark, green and red
> intermediate. The PS version preserves grayscale lightness/darkness as
> can be seen in the last frame of the set below.
>
> Here's examples and the blending modes used to achieve them:
> http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
> I also tried it in lab mode, out of curiosity.
> #2 was pasted together from using those two blending modes for top &
> bottom, then squishing them back to fit in a square. Most programs work
> this way for what they call luminance. #1 is the default PS behavior.
>
> At first I was just curious but I do use the luminance blending mode
> pretty often on contrast type adjustment layers so that I can tweak
> curves or levels without changing saturation. Normally a contrast
> increase will give a more saturated image and I often like to keep
> things subtle. I'm aware that lab mode is the better way to do this but
> it's a hassle and I'm just not in the habit of working in lab. Is the
> luminosity blend mode going to mess up my colors? Like if curves darken
> a blue area, it looks like that might turn pale. Or maybe this really is
> the better way to do it and actually preserves luminosity better.
It all depends on the image - the important thing is to be quick enough in
your workflow to try it one way, then another, and compare results. Dan
Margulis's Picture Postcard workflow is an example of this, though it is
done with a combination of curves and Photoshop's apply image command.
Speaking of just blues in the context of sky - most viewers like skies to
be dark and saturated, so yes, applying a luminosity layer to a blue sky
would generally lighten it. In this case you would use apply image, uaing
the red channel in luminosity mode, and use a curve to boost the effect
further. If there are important foreground elements, then use the green or
blue channels (or the b channel in Lab) as a mask.
There are dozens of ways to use curves, masking, apply image, layer
blending, and other functions, each of which adds a bit of punch to your
image as far as color or detail.
BTW - on your flickr page you pose the question of why use a Granger chart
at all - for me it's a curiousity item that is helpful for understanding
the RGB color space, but nothing more than that. As an artificial
gradient, it is of no relevance to photography or printing related to
photography.
--
Mike Russell - http://www.curvemeister.com
| |
|
On 2/11/2010 10:00 PM, Mike Russell wrote:
> On Thu, 11 Feb 2010 11:02:52 -0800, Paul Furman wrote:
>
>> On 2/9/2010 8:52 PM, Mike Russell wrote:
>>> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>>>
>>>> On 10-02-07 19:40 , Mike Russell wrote:
>>>>
>>>>>
>>>>> Photoshop can provide linear gradients, but not by default. Use
>>>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>>>> dither. Why did they do it this way? Why ask why.
>>>>
>>>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>>>> Granger. I set no dither for both the spectrum and the gradient. I set
>>>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>>>> the artifacts. Any idea what I'm missing?
>>>>
>>>> (If I do this with "HardLight" instead of Luminosity, it does work).
>>>
>>> Photoshop is giving an accurate result in both cases. The hard light layer
>>> will darken RGB values of the target layer for values less than 128, and
>>> lighten it for values greater than 128. The result is an artifact free
>>> Granger chart, similar to what you see from other products.
>>
>> Hard light is not exactly the same, I managed to make a matching chart
>> with Screen mode above 128 and Multiply mode below 128. That's what most
>> programs call luminosity. The question is why the different approaches?
>>
>>
>>> Luminosity is a hue dependent function, weighted by the luminosity values,
>>> with b the darkest and green the lightest of the rgb primaries. It's not
>>> possible, in RGB space, for a pure blue to have a luminosity greater than
>>> 11%. Above that it is necessary to add white to the blue to get the value
>>> dictated by the luminosity layer.
>>>
>>> The zig zag artifact has six peaks, one for each primary of the HSL
>>> hexcone. Another way to think of it is a plot of the luminosity of various
>>> mixtures of r, g, and b, with blue being the darkest, and yellow being the
>>> lightest. Or think of it as a flattened cylindrical projection of the HSL
>>> hexcone.
>>>
>>> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
>>> from luma" operation shown in the geometric derivation illustration is what
>>> is happening with Photoshop's luminosity mode.
>>
>> http://en.wikipedia.org/wiki/HSL_and_HSV
>> That first illustration looks a lot like what we are discussing here.
>>
>>
>> Math for luma figured into the best explanation I could find. That
>> explained the asymetrical humps in the PS version with 'luminance' but
>> what is the scheme that shows symmetrical peaks in the diagram and why
>> did the other programs chose that math for what they call luminance?
>
> I think the other programs simply multiplied the RGB channels equally by
> the grayscale value over 255.
>
>> The
>> big difference I saw was that if you convert to grayscale, the PS
>> version goes to a smooth transition where the other shows the colors for
>> their lightness: yellow is light, blue is dark, green and red
>> intermediate. The PS version preserves grayscale lightness/darkness as
>> can be seen in the last frame of the set below.
>>
>> Here's examples and the blending modes used to achieve them:
>> http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
>> I also tried it in lab mode, out of curiosity.
>> #2 was pasted together from using those two blending modes for top&
>> bottom, then squishing them back to fit in a square. Most programs work
>> this way for what they call luminance. #1 is the default PS behavior.
>>
>> At first I was just curious but I do use the luminance blending mode
>> pretty often on contrast type adjustment layers so that I can tweak
>> curves or levels without changing saturation. Normally a contrast
>> increase will give a more saturated image and I often like to keep
>> things subtle. I'm aware that lab mode is the better way to do this but
>> it's a hassle and I'm just not in the habit of working in lab. Is the
>> luminosity blend mode going to mess up my colors? Like if curves darken
>> a blue area, it looks like that might turn pale. Or maybe this really is
>> the better way to do it and actually preserves luminosity better.
>
> It all depends on the image - the important thing is to be quick enough in
> your workflow to try it one way, then another, and compare results. Dan
> Margulis's Picture Postcard workflow is an example of this, though it is
> done with a combination of curves and Photoshop's apply image command.
>
> Speaking of just blues in the context of sky - most viewers like skies to
> be dark and saturated, so yes, applying a luminosity layer to a blue sky
> would generally lighten it. In this case you would use apply image, uaing
> the red channel in luminosity mode, and use a curve to boost the effect
> further. If there are important foreground elements, then use the green or
> blue channels (or the b channel in Lab) as a mask.
>
> There are dozens of ways to use curves, masking, apply image, layer
> blending, and other functions, each of which adds a bit of punch to your
> image as far as color or detail.
>
> BTW - on your flickr page you pose the question of why use a Granger chart
> at all - for me it's a curiousity item that is helpful for understanding
> the RGB color space, but nothing more than that. As an artificial
> gradient, it is of no relevance to photography or printing related to
> photography.
Thanks! I've been discovering snapshots on the history toolbar are good
for that filp-back-n-forth type comparison; an effective way to evaluate
complex options.
I take it you mean, if blues are getting washed out, then just work on
the red (and or green) channel of an adjustment layer (when setting
luminance blend mode to avoid saturation changes as I described). I
tried that on one typical sort of landscape with a washed out sky and
all it did was emphasize the dark vignetting in the corners, so yeah, it
all depends on the image and any number of tweaks can be applied till it
looks right.
The value of the chart for general comprehension is like this question -
looking at a few of these charts flipping through the blend modes has
helped me understand blend modes and what to look for.
> On Thu, 11 Feb 2010 11:02:52 -0800, Paul Furman wrote:
>
>> On 2/9/2010 8:52 PM, Mike Russell wrote:
>>> On Tue, 09 Feb 2010 16:14:44 -0500, Alan Browne wrote:
>>>
>>>> On 10-02-07 19:40 , Mike Russell wrote:
>>>>
>>>>>
>>>>> Photoshop can provide linear gradients, but not by default. Use
>>>>> Photoshop's gradient editor, set the smoothing parameter to zero, and no
>>>>> dither. Why did they do it this way? Why ask why.
>>>>
>>>> Hi Mike, I followed your instructions, but I do not get the 'standard'
>>>> Granger. I set no dither for both the spectrum and the gradient. I set
>>>> smoothing to 0 (for either and both). But I do not get the Granger w/o
>>>> the artifacts. Any idea what I'm missing?
>>>>
>>>> (If I do this with "HardLight" instead of Luminosity, it does work).
>>>
>>> Photoshop is giving an accurate result in both cases. The hard light layer
>>> will darken RGB values of the target layer for values less than 128, and
>>> lighten it for values greater than 128. The result is an artifact free
>>> Granger chart, similar to what you see from other products.
>>
>> Hard light is not exactly the same, I managed to make a matching chart
>> with Screen mode above 128 and Multiply mode below 128. That's what most
>> programs call luminosity. The question is why the different approaches?
>>
>>
>>> Luminosity is a hue dependent function, weighted by the luminosity values,
>>> with b the darkest and green the lightest of the rgb primaries. It's not
>>> possible, in RGB space, for a pure blue to have a luminosity greater than
>>> 11%. Above that it is necessary to add white to the blue to get the value
>>> dictated by the luminosity layer.
>>>
>>> The zig zag artifact has six peaks, one for each primary of the HSL
>>> hexcone. Another way to think of it is a plot of the luminosity of various
>>> mixtures of r, g, and b, with blue being the darkest, and yellow being the
>>> lightest. Or think of it as a flattened cylindrical projection of the HSL
>>> hexcone.
>>>
>>> Jacob Rus has recently done a wiki page on HSL and HSB. The "set height
>>> from luma" operation shown in the geometric derivation illustration is what
>>> is happening with Photoshop's luminosity mode.
>>
>> http://en.wikipedia.org/wiki/HSL_and_HSV
>> That first illustration looks a lot like what we are discussing here.
>>
>>
>> Math for luma figured into the best explanation I could find. That
>> explained the asymetrical humps in the PS version with 'luminance' but
>> what is the scheme that shows symmetrical peaks in the diagram and why
>> did the other programs chose that math for what they call luminance?
>
> I think the other programs simply multiplied the RGB channels equally by
> the grayscale value over 255.
>
>> The
>> big difference I saw was that if you convert to grayscale, the PS
>> version goes to a smooth transition where the other shows the colors for
>> their lightness: yellow is light, blue is dark, green and red
>> intermediate. The PS version preserves grayscale lightness/darkness as
>> can be seen in the last frame of the set below.
>>
>> Here's examples and the blending modes used to achieve them:
>> http://www.flickr.com/photos/edgehill/sets/72157623375625518 /
>> I also tried it in lab mode, out of curiosity.
>> #2 was pasted together from using those two blending modes for top&
>> bottom, then squishing them back to fit in a square. Most programs work
>> this way for what they call luminance. #1 is the default PS behavior.
>>
>> At first I was just curious but I do use the luminance blending mode
>> pretty often on contrast type adjustment layers so that I can tweak
>> curves or levels without changing saturation. Normally a contrast
>> increase will give a more saturated image and I often like to keep
>> things subtle. I'm aware that lab mode is the better way to do this but
>> it's a hassle and I'm just not in the habit of working in lab. Is the
>> luminosity blend mode going to mess up my colors? Like if curves darken
>> a blue area, it looks like that might turn pale. Or maybe this really is
>> the better way to do it and actually preserves luminosity better.
>
> It all depends on the image - the important thing is to be quick enough in
> your workflow to try it one way, then another, and compare results. Dan
> Margulis's Picture Postcard workflow is an example of this, though it is
> done with a combination of curves and Photoshop's apply image command.
>
> Speaking of just blues in the context of sky - most viewers like skies to
> be dark and saturated, so yes, applying a luminosity layer to a blue sky
> would generally lighten it. In this case you would use apply image, uaing
> the red channel in luminosity mode, and use a curve to boost the effect
> further. If there are important foreground elements, then use the green or
> blue channels (or the b channel in Lab) as a mask.
>
> There are dozens of ways to use curves, masking, apply image, layer
> blending, and other functions, each of which adds a bit of punch to your
> image as far as color or detail.
>
> BTW - on your flickr page you pose the question of why use a Granger chart
> at all - for me it's a curiousity item that is helpful for understanding
> the RGB color space, but nothing more than that. As an artificial
> gradient, it is of no relevance to photography or printing related to
> photography.
Thanks! I've been discovering snapshots on the history toolbar are good
for that filp-back-n-forth type comparison; an effective way to evaluate
complex options.
I take it you mean, if blues are getting washed out, then just work on
the red (and or green) channel of an adjustment layer (when setting
luminance blend mode to avoid saturation changes as I described). I
tried that on one typical sort of landscape with a washed out sky and
all it did was emphasize the dark vignetting in the corners, so yeah, it
all depends on the image and any number of tweaks can be applied till it
looks right.
The value of the chart for general comprehension is like this question -
looking at a few of these charts flipping through the blend modes has
helped me understand blend modes and what to look for.
| |
|
Mike Russell wrote:
> On Wed, 10 Feb 2010 18:15:55 -0500, Alan Browne wrote:
>
>> On 10-02-10 17:25 , Mike Russell wrote:
>>> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>>>
>>>> I really wanted to know why if I'm following your instructions, I'm not
>>>> getting your result. Someone else did. ("Me" but not me).
>>>>
>>>> eg: I'm doing something wrong in the process.
>>> I think they were referring to the gradient not having a clean histogram,
>>> rather than the result with the granger chart. The granger chart will
>>> have the artifacts you mention for Luminosity, because of the relationship
>>> of hue and luminosity, but not for other modes such as hard light.
>>
>> You're not hearing me.
>>
>> "Me" (a different poster) followed your suggestion for turning off
>> dithering and setting smoothing to 0. Using Luminosity He got a
>> nominally correct Granger.
>>
>> I (that is me, not "Me") followed your instructions and did not get the
>> nominally correct Granger using Luminosity (I did with "Hardlight").
>>
>> What could account for the different result?
>
> I think I'm hearing both you, and Me. I guess we'll just have to wait for
> Me to clear up the matter.
You solved the problem with non-linear gradients.
The relationship between luminosity and hue in photoshop also explains
why the method suggested by Luminous Landscape fails.
It remains a mystery why Luminous Landscape didn't see that their
"Granger chart" was a shameful mistake, and a further mystery - to me
anyway - why they thought that a Granger chart was useful, except as a
curiosity. They also failed to suggest that using jpeg compression on
such a chart was a waste of time and to be seriously avoided, and why on
the sort of monitors many people use these days, correct display of
gradients can be a big problem.
But from years of reading articles about photography on Luminous
Landscape, I'd come to the conclusion that they are a pretty hapless lot
of obsessive gadget-geeks, not real photographers.
> On Wed, 10 Feb 2010 18:15:55 -0500, Alan Browne wrote:
>
>> On 10-02-10 17:25 , Mike Russell wrote:
>>> On Tue, 09 Feb 2010 23:56:35 -0500, Alan Browne wrote:
>>>
>>>> I really wanted to know why if I'm following your instructions, I'm not
>>>> getting your result. Someone else did. ("Me" but not me).
>>>>
>>>> eg: I'm doing something wrong in the process.
>>> I think they were referring to the gradient not having a clean histogram,
>>> rather than the result with the granger chart. The granger chart will
>>> have the artifacts you mention for Luminosity, because of the relationship
>>> of hue and luminosity, but not for other modes such as hard light.
>>
>> You're not hearing me.
>>
>> "Me" (a different poster) followed your suggestion for turning off
>> dithering and setting smoothing to 0. Using Luminosity He got a
>> nominally correct Granger.
>>
>> I (that is me, not "Me") followed your instructions and did not get the
>> nominally correct Granger using Luminosity (I did with "Hardlight").
>>
>> What could account for the different result?
>
> I think I'm hearing both you, and Me. I guess we'll just have to wait for
> Me to clear up the matter.
You solved the problem with non-linear gradients.
The relationship between luminosity and hue in photoshop also explains
why the method suggested by Luminous Landscape fails.
It remains a mystery why Luminous Landscape didn't see that their
"Granger chart" was a shameful mistake, and a further mystery - to me
anyway - why they thought that a Granger chart was useful, except as a
curiosity. They also failed to suggest that using jpeg compression on
such a chart was a waste of time and to be seriously avoided, and why on
the sort of monitors many people use these days, correct display of
gradients can be a big problem.
But from years of reading articles about photography on Luminous
Landscape, I'd come to the conclusion that they are a pretty hapless lot
of obsessive gadget-geeks, not real photographers.
| |
|
Alan Browne wrote:
> 1) In PS, follow the instructions at:
> http://www.luminous-landscape.com/essays/test-charts.shtmlan d generate
> the Granger chart as shown. Oddly, it has a strange distribution given
> that the gradient layer is linear top-to-bottom. What is creating those
> diagonals in the chart?
As Mike mentioned, this is because Photoshop's hue/saturation/color/
luminosity blend modes are with reference to what my Wikipedia article
about HSL & HSV [1] calls a "luma/chroma/hue" model. If you look at
the second image in that article, it's the shape at the bottom right.
What Photoshop's blend modes call “luminosity” is close to .3*R + .6*G
+ .1*B, what the blend modes call “saturation” is max(R, G, B) -
min(R, G, B) -- notice that this is different from both HSL
"saturation" and HSV "saturation" -- and what the blend modes call hue
is the same as HSL/HSV hue.
[1]: http://en.wikipedia.org/wiki/HSL_and_HSV
So anyway, that "granger chart" (I've never heard of such a thing, and
can't imagine a use for it; I wonder how the luminous landscape guys
came up with it) basically shows what would happen if you stretched
out the odd asymmetrical bicone shape of the luma/chroma/hue model
into a cylinder. In other words, for each combination of hue and luma,
it shows the color with maximum chroma.
Perhaps the purpose of this is to aid selection of as-chromatic-as-
possible colors, based on some scheme in hue/lightness? If so, this
isn't such a great tool, and really highlights the problems of using
luma as a proxy for lightness (e.g. CIELAB L* or CIECAM02 J): luma is
derived directly from the gamma-corrected R, G, B values stored in an
image in a space like Adobe RGB or sRGB, but human brightness/
lightness perception is a non-linear adjustment to the direct
luminance (Y) signal taken in by the eyes. Basically, using luma as a
proxy for lightness leads to great distortions for bright colors. This
is dramatically demonstrated by the “Granger chart”, which has bright
diagonal bands along the highest-chroma edges. If luma were a good
proxy for lightness, this chart would look pretty smooth.
It's also problematic to use this definition of "hue" based on RGB
primaries, because it's basically arbitrary. Much better would be to
space hue as in Munsell, CIELAB, or CIECAM02 geometries.
So anyway, again, I can't think of a good use for this "Granger
chart", and I recommend ignoring/avoiding it.
> 2) For comparison, see;
>
> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
I'm not sure what this is about. Since I've never heard of a "Granger
chart" before today, I'm not sure what a proper one looks like, but
it's not at all clear to me that the results from these other editors
(the edge of an HSL cylinder) is it. Presumably the luminous landscape
people realize the difference.
If you want to make a chart like this using photoshop, follow these
steps:
1) Make a horizontal gradient (smoothness = 0) where red, yellow,
green, cyan, blue, magenta, red are at 0%, 16%, 33%, 50%, 67%, 83%
2) Add a layer above, and make vertical gradient from bottom to top
which has colors (bottom of the gradient interface) go black, black,
white, white at 0%, 50%, 50%, 100% (the two 50%s should be as close as
you can make them, like 1 pixel apart), and which has transparency
(top of the gradient interface) opaque (100% opacity), transparent
(0%), opaque, at positions 0%, 50%, 100%. Make this gradient still
have smoothness = 0. Leave the layer in normal mode, since we just
want to interpolate linearly between red, yellow, etc. and black at
the bottom or white at the top.
Do those instructions make sense?
* * *
All of this is a completely separate issue from photoshop's non-linear
gradients. I generally turn smoothness on my gradients down to 0, to
make them linear, because I tend to use gradients for making charts/
graphics rather than for editing photos. I'm not sure quite how they
decided on the interpolation method for the 100% smoothness version. I
think it's the same as the interpolation used by the Curves tool (and
I don't understand the particular choice of math used there, either --
it's not the best for the job).
Hope that helps,
Jacob
> 1) In PS, follow the instructions at:
> http://www.luminous-landscape.com/essays/test-charts.shtmlan d generate
> the Granger chart as shown. Oddly, it has a strange distribution given
> that the gradient layer is linear top-to-bottom. What is creating those
> diagonals in the chart?
As Mike mentioned, this is because Photoshop's hue/saturation/color/
luminosity blend modes are with reference to what my Wikipedia article
about HSL & HSV [1] calls a "luma/chroma/hue" model. If you look at
the second image in that article, it's the shape at the bottom right.
What Photoshop's blend modes call “luminosity” is close to .3*R + .6*G
+ .1*B, what the blend modes call “saturation” is max(R, G, B) -
min(R, G, B) -- notice that this is different from both HSL
"saturation" and HSV "saturation" -- and what the blend modes call hue
is the same as HSL/HSV hue.
[1]: http://en.wikipedia.org/wiki/HSL_and_HSV
So anyway, that "granger chart" (I've never heard of such a thing, and
can't imagine a use for it; I wonder how the luminous landscape guys
came up with it) basically shows what would happen if you stretched
out the odd asymmetrical bicone shape of the luma/chroma/hue model
into a cylinder. In other words, for each combination of hue and luma,
it shows the color with maximum chroma.
Perhaps the purpose of this is to aid selection of as-chromatic-as-
possible colors, based on some scheme in hue/lightness? If so, this
isn't such a great tool, and really highlights the problems of using
luma as a proxy for lightness (e.g. CIELAB L* or CIECAM02 J): luma is
derived directly from the gamma-corrected R, G, B values stored in an
image in a space like Adobe RGB or sRGB, but human brightness/
lightness perception is a non-linear adjustment to the direct
luminance (Y) signal taken in by the eyes. Basically, using luma as a
proxy for lightness leads to great distortions for bright colors. This
is dramatically demonstrated by the “Granger chart”, which has bright
diagonal bands along the highest-chroma edges. If luma were a good
proxy for lightness, this chart would look pretty smooth.
It's also problematic to use this definition of "hue" based on RGB
primaries, because it's basically arbitrary. Much better would be to
space hue as in Munsell, CIELAB, or CIECAM02 geometries.
So anyway, again, I can't think of a good use for this "Granger
chart", and I recommend ignoring/avoiding it.
> 2) For comparison, see;
>
> http://farm3.static.flickr.com/2790/4337946696_8ef5e104ff_o. jpg
I'm not sure what this is about. Since I've never heard of a "Granger
chart" before today, I'm not sure what a proper one looks like, but
it's not at all clear to me that the results from these other editors
(the edge of an HSL cylinder) is it. Presumably the luminous landscape
people realize the difference.
If you want to make a chart like this using photoshop, follow these
steps:
1) Make a horizontal gradient (smoothness = 0) where red, yellow,
green, cyan, blue, magenta, red are at 0%, 16%, 33%, 50%, 67%, 83%
2) Add a layer above, and make vertical gradient from bottom to top
which has colors (bottom of the gradient interface) go black, black,
white, white at 0%, 50%, 50%, 100% (the two 50%s should be as close as
you can make them, like 1 pixel apart), and which has transparency
(top of the gradient interface) opaque (100% opacity), transparent
(0%), opaque, at positions 0%, 50%, 100%. Make this gradient still
have smoothness = 0. Leave the layer in normal mode, since we just
want to interpolate linearly between red, yellow, etc. and black at
the bottom or white at the top.
Do those instructions make sense?
* * *
All of this is a completely separate issue from photoshop's non-linear
gradients. I generally turn smoothness on my gradients down to 0, to
make them linear, because I tend to use gradients for making charts/
graphics rather than for editing photos. I'm not sure quite how they
decided on the interpolation method for the 100% smoothness version. I
think it's the same as the interpolation used by the Curves tool (and
I don't understand the particular choice of math used there, either --
it's not the best for the job).
Hope that helps,
Jacob
| |
|
Incidentally, in case anyone wants a "proper Granger rainbow" (which
is to say, the edge of an HSL cylinder) of their own, without
following the steps above, I've uploaded one here:
http://www.mediafire.com/?2mmam2mdyzt
Just resize this photoshop file to any desired dimensions.
Cheers,
Jacob
is to say, the edge of an HSL cylinder) of their own, without
following the steps above, I've uploaded one here:
http://www.mediafire.com/?2mmam2mdyzt
Just resize this photoshop file to any desired dimensions.
Cheers,
Jacob
| |
|
On Mon, 8 Mar 2010 15:42:18 -0800 (PST), Jacob Rus wrote:
> Incidentally, in case anyone wants a "proper Granger rainbow" (which
> is to say, the edge of an HSL cylinder) of their own, without
> following the steps above, I've uploaded one here:
> http://www.mediafire.com/?2mmam2mdyzt
>
> Just resize this photoshop file to any desired dimensions.
>
> Cheers,
> Jacob
May not be useful, but it sure looks pretty. Reminds me of the rainbow I
saw on the way back from work today.
Interesting that there are relatively bright vertical lines at the CMY
hues, but not at the RGB ones. I'll venture a guess that this is because
these hues have two sets of pixels contributing photons, instead of only
one.
So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
RGB(255,0,255).
--
Mike Russell - http://www.curvemeister.com
> Incidentally, in case anyone wants a "proper Granger rainbow" (which
> is to say, the edge of an HSL cylinder) of their own, without
> following the steps above, I've uploaded one here:
> http://www.mediafire.com/?2mmam2mdyzt
>
> Just resize this photoshop file to any desired dimensions.
>
> Cheers,
> Jacob
May not be useful, but it sure looks pretty. Reminds me of the rainbow I
saw on the way back from work today.
Interesting that there are relatively bright vertical lines at the CMY
hues, but not at the RGB ones. I'll venture a guess that this is because
these hues have two sets of pixels contributing photons, instead of only
one.
So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
RGB(255,0,255).
--
Mike Russell - http://www.curvemeister.com
| |
|
Mike Russell wrote:
> Interesting that there are relatively bright vertical lines at the CMY
> hues, but not at the RGB ones. I'll venture a guess that this is because
> these hues have two sets of pixels contributing photons, instead of only
> one.
>
> So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
> RGB(255,0,255).
Pretty much. If you look at the deformations that go into making the
HSL cylinder from an RGB cube – in the diagram <http://
en.wikipedia.org/wiki/File:Hsl-and-hsv.svg> look at the tilted cube in
the top middle and notice that the following step pushes red, green,
and blue *up*, while pushing cyan, yellow, and magenta *down* – these
bright vertical lines are the top three edges of the cube (stretching
between white and C, M, or Y). At red, green, and blue, there are also
vertical lines, but they're darker than the surrounding area, rather
than lighter.
Cheers,
Jacob
> Interesting that there are relatively bright vertical lines at the CMY
> hues, but not at the RGB ones. I'll venture a guess that this is because
> these hues have two sets of pixels contributing photons, instead of only
> one.
>
> So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
> RGB(255,0,255).
Pretty much. If you look at the deformations that go into making the
HSL cylinder from an RGB cube – in the diagram <http://
en.wikipedia.org/wiki/File:Hsl-and-hsv.svg> look at the tilted cube in
the top middle and notice that the following step pushes red, green,
and blue *up*, while pushing cyan, yellow, and magenta *down* – these
bright vertical lines are the top three edges of the cube (stretching
between white and C, M, or Y). At red, green, and blue, there are also
vertical lines, but they're darker than the surrounding area, rather
than lighter.
Cheers,
Jacob
| |
|
On Wed, 10 Mar 2010 02:23:48 -0800 (PST), Jacob Rus wrote:
> Mike Russell wrote:
>> Interesting that there are relatively bright vertical lines at the CMY
>> hues, but not at the RGB ones. I'll venture a guess that this is because
>> these hues have two sets of pixels contributing photons, instead of only
>> one.
>>
>> So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
>> RGB(255,0,255).
>
> Pretty much. If you look at the deformations that go into making the
> HSL cylinder from an RGB cube – in the diagram <http://
> en.wikipedia.org/wiki/File:Hsl-and-hsv.svg> look at the tilted cube in
> the top middle and notice that the following step pushes red, green,
> and blue *up*, while pushing cyan, yellow, and magenta *down* – these
> bright vertical lines are the top three edges of the cube (stretching
> between white and C, M, or Y). At red, green, and blue, there are also
> vertical lines, but they're darker than the surrounding area, rather
> than lighter.
>
> Cheers,
> Jacob
Ah - hadn't quite pieced that together. Thanks. This also explains the
varying width of the colored bands for RGB and CMY on the default "rainbow"
gradient, and the rainbow pattern on the color picker hue slider.
BTW - I just noticed that there is a mini-Granger chart along the bottom of
the color palette. I believe Kai Krause's color picker also used a
Granger-style pattern.
--
Mike Russell - http://www.curvemeister.com
> Mike Russell wrote:
>> Interesting that there are relatively bright vertical lines at the CMY
>> hues, but not at the RGB ones. I'll venture a guess that this is because
>> these hues have two sets of pixels contributing photons, instead of only
>> one.
>>
>> So, for example RGB(255,0,0) will be less bright than RGB(255,255,0) or
>> RGB(255,0,255).
>
> Pretty much. If you look at the deformations that go into making the
> HSL cylinder from an RGB cube – in the diagram <http://
> en.wikipedia.org/wiki/File:Hsl-and-hsv.svg> look at the tilted cube in
> the top middle and notice that the following step pushes red, green,
> and blue *up*, while pushing cyan, yellow, and magenta *down* – these
> bright vertical lines are the top three edges of the cube (stretching
> between white and C, M, or Y). At red, green, and blue, there are also
> vertical lines, but they're darker than the surrounding area, rather
> than lighter.
>
> Cheers,
> Jacob
Ah - hadn't quite pieced that together. Thanks. This also explains the
varying width of the colored bands for RGB and CMY on the default "rainbow"
gradient, and the rainbow pattern on the color picker hue slider.
BTW - I just noticed that there is a mini-Granger chart along the bottom of
the color palette. I believe Kai Krause's color picker also used a
Granger-style pattern.
--
Mike Russell - http://www.curvemeister.com
| |
|
| |
| Previous Topic: | enlarge/clone a region |
| Next Topic: | Ideal laptop for Photoshop |
Adobe Photoshop plug-ins, tools, tutorials and user discussions