Jaap Frank <jjf### [at] casemanl> wrote:
> The linearity of 3.6 looks better then that of 3.7

  As has been commented several times, that's to be expected. The 3.7
gradient shouldn't *look* linear because it doesn't use perceived
brightness. 3.6 uses direct pixel values which, in most monitors, map
almost linearly to perceived brightness.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>    pigment {
>      gradient y
>      color_map {
>        perceptual
>        [0.0 rgb 0]
>        [0.5 rgb 1]
>        [1.0 rgb 0.5]
>      }
>    }

> (The example also showcases the problem with the poly_wave workaround 
> you mention, which only works for gradients running from [0.0 rgb 0] to 
> [1.0 Some_Color].)

  Now that you mention that, it's actually quite a problem. The
'poly_wave 2.2' indeed only works if you have one single color
transition from 0.0 to 1.0 in your color map (or pigment/texture map),
but doesn't work if there is more than one, as in your example. The
poly_wave function would have to be applied to every individual
transition, rather than the entire map, and this is just not possible.

  As far as I can tell, there is no way in pov3.7 to replicate a pov3.6
color map (in terms of perceptual brightness) other than using the
'assumed_gamma 2.2' backwards compatibility trick, which then affects
*all* colors, not just the color map.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   As far as I can tell, there is no way in pov3.7 to replicate a pov3.6
> color map (in terms of perceptual brightness) other than using the
> 'assumed_gamma 2.2' backwards compatibility trick, which then affects
> *all* colors, not just the color map.

  I'm wondering if what pov3.7 is doing isn't actually backwards.

  What it currently does is, basically, "by default 'rgb 0.5' means 50%
absolute brightness; if you want 50% perceived brightness, use 'srgb 0.5'"
(or whatever will be in the final).

  Perhaps it should be the exact opposite: By default 'rgb 0.5' means 50%
perceived brightness, and if you want 50% of absolute brightness, use ...

  In other words, the "I want a gray shade that matches the black/white
pattern that gives me 50% absolute brightness" should be the special case,
not the default case. The default case should be "I want 50% perceived
brightness".

  Likewise with gradients: The default should be *perceived* linearity,
the absolute linearity being the special case which has to be specified
in a special way.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   As far as I can tell, there is no way in pov3.7 to replicate a pov3.6
> > color map (in terms of perceptual brightness) other than using the
> > 'assumed_gamma 2.2' backwards compatibility trick, which then affects
> > *all* colors, not just the color map.
>
>   I'm wondering if what pov3.7 is doing isn't actually backwards.
>
>   What it currently does is, basically, "by default 'rgb 0.5' means 50%
> absolute brightness; if you want 50% perceived brightness, use 'srgb 0.5'"
> (or whatever will be in the final).
>
>   Perhaps it should be the exact opposite: By default 'rgb 0.5' means 50%
> perceived brightness, and if you want 50% of absolute brightness, use ...
>
>   In other words, the "I want a gray shade that matches the black/white
> pattern that gives me 50% absolute brightness" should be the special case,
> not the default case. The default case should be "I want 50% perceived
> brightness".
>
>   Likewise with gradients: The default should be *perceived* linearity,
> the absolute linearity being the special case which has to be specified
> in a special way.

I sort of agree, but I think perhaps a more general solution would be even more
useful; allow the user to specify the colourspace in which the interpolation is
working. So you can specify a linear coourspace, or a sRGB colourspace, or a
specific gamma, or (actually quite usefully) HSV or L*ab or some other non-RGB
one.

>                                                           - Warp

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> >   Likewise with gradients: The default should be *perceived* linearity,
> > the absolute linearity being the special case which has to be specified
> > in a special way.
>
> I sort of agree, but I think perhaps a more general solution would be even more
> useful; allow the user to specify the colourspace in which the interpolation is
> working. So you can specify a linear coourspace, or a sRGB colourspace, or a
> specific gamma, or (actually quite usefully) HSV or L*ab or some other non-RGB
> one.
>
> >                                                           - Warp
>
> Cheers,
> Edouard.

Christ, now we're (almost) getting into the territory of how I want to implement
true "specify your spectrum" lighting/pigments...  :-D

(Granted, that _would_ pretty well obviate this whole argument because if you're
stating the spectrum, obviously you're stating it in [fake-unitized] radiant
flux at various wavelengths, but it's also enough work to try and implement that
I doubt it'd be finished before we were staring down the barrels of POV-Ray
5.0...)

Post a reply to this message

>> OOC did you decide already which algorithm to use for this? Will it give
>> more linear looking gradients between different colours too?
>
> I expect so.
>
> When interpolating between two colors, POV-Ray currently computes
> something along the lines of:
>
> q = 1-p;
> result = p * color1 + q * color2;
>
> For a "perceptually linear" gradient, the formula would be changed to:
>
> q = 1-p;
> temp1 = pow(color1, 1/gamma);
> temp2 = pow(color2, 1/gamma);
> tempR = p * color1 + q * color2;
> result = pow(tempR, gamma);
>
> where gamma would be a value around 2.5.

OOC why 2.5?  CIELAB uses a value of 3 to computer the "lightness".

Whilst that will be great for greys, it might not work so well for 
colours.  For example if you take a gradient between dark green and dark 
blue, or between purple and orange, I actually think the 3.7 "physically 
linear" method gives a more perceptually linear result currently.

Post a reply to this message

Le 04/01/2011 14:19, scott a écrit :
>>> OOC did you decide already which algorithm to use for this? Will it give
>>> more linear looking gradients between different colours too?
>>
>> I expect so.
>>
>> When interpolating between two colors, POV-Ray currently computes
>> something along the lines of:
>>
>> q = 1-p;
>> result = p * color1 + q * color2;
>>
>> For a "perceptually linear" gradient, the formula would be changed to:
>>
>> q = 1-p;
>> temp1 = pow(color1, 1/gamma);
>> temp2 = pow(color2, 1/gamma);
>> tempR = p * color1 + q * color2;
>> result = pow(tempR, gamma);
>>
>> where gamma would be a value around 2.5.
> 
> OOC why 2.5?  CIELAB uses a value of 3 to computer the "lightness".

Just asking a question now:
Why should the interpolation be done in rgb colour space ?
(whatever the gamma used, it would still be a line in a rgb(gamma) space).

Well, may be the word "always" is missing from the question.

(I have been playing a bit with interpolated colors in blobs: rgb, xyv,
xyl, hsv & hsl... not always the same results, but I'm lacking a good
showcase so far).

Interpolating between "red 1" and "green 1", should it always go via a
"yellow 0.5" ? Tuning the gamma in previous formula allow to shift that
a bit, but wouldn't a different color space be simpler and better
instead ? (as an option of the map)

How do you expect to interpolate between "green 1" & "magenta 1"
(opposite rgb value, but both fully saturated : should interpolated be
not saturated ?) ?

Post a reply to this message

> Interpolating between "red 1" and "green 1", should it always go via a
> "yellow 0.5" ? Tuning the gamma in previous formula allow to shift that
> a bit, but wouldn't a different color space be simpler and better
> instead ? (as an option of the map)

The problem is if you tune the gamma for that, you'll end up needing a 
different gamma value for every pair of colours to give the perceptually 
linear result you want.

There are colour spaces designed specifically so that equal distances 
equate to equal difference perceptions, one of these could be used 
instead of rgb (just for the interpolations, if some keyword like 
"perceptual" is specified) and it would give correct results for any 
possible input colours.

 > How do you expect to interpolate between "green 1"&  "magenta 1"
 > (opposite rgb value, but both fully saturated : should interpolated be
 > not saturated ?) ?

Green and magenta is a good example of a gradient that looks much better 
in 3.7 compared to 3.6 IMO.

Post a reply to this message

Am 04.01.2011 16:25, schrieb scott:

> There are colour spaces designed specifically so that equal distances
> equate to equal difference perceptions, one of these could be used
> instead of rgb (just for the interpolations, if some keyword like
> "perceptual" is specified) and it would give correct results for any
> possible input colours.

I guess you're making a good point there, for why the way I'm aiming for 
is the right way to go: Making linear color space the default and fixing 
the places where it leads to noticeably unpleasant results. Because 
after all, I'm convinced that those places have always been problematic, 
but haven't been recognized as such because it wasn't that obvious as 
with a linear color space.

So yes, you've convinced me that we need to leave RGB space there. Maybe 
color map interpolation is a good place to start introducing color space 
handling into the POV-Ray code.

Post a reply to this message

Am 04.01.2011 14:19, schrieb scott:

>> For a "perceptually linear" gradient, the formula would be changed to:
>>
>> q = 1-p;
>> temp1 = pow(color1, 1/gamma);
>> temp2 = pow(color2, 1/gamma);
>> tempR = p * color1 + q * color2;
>> result = pow(tempR, gamma);
>>
>> where gamma would be a value around 2.5.
>
> OOC why 2.5? CIELAB uses a value of 3 to computer the "lightness".

Maybe this is just CIE's way of avoiding potential trouble if someone 
tries to feed negative values into the formula for converting from CIE 
XYZ to L*a*b*.

Note that for instance Hunter Lab uses a gamma of 2.0.

Post a reply to this message