Le Forgeron <jgr### [at] freefr> wrote:
> Did you look at my code in p.b.sf ?
> H was not linearly interpolated. There is a bit of vectors involved.
> RGB or HSV/L: red & cyan mix as a shade of grey. (null saturation)
> If one is shorter than, it is defined...
> Now, should the path be alike is another problem: at any moment you
> will have to choose between the upper path and the lower path...
> There is two ways for opposites on a circle. And no good choice.

Actually I didn't look at the actual code, I was commenting more on the
appearance of the graphic.  The main problem that stood out to me was that 2
pure colours interpolated as a pure colour (red to blue = magenta) which
indicated to me that the path was interpolating between the H values, following
the perimeter of the colour space, rather than cutting directly across which
gives a different shade, whereas the opposite colours are interpolated directly
across.

>
>
>
> >
> > A second problem I see is that this really only shows the halfway colour, and
> > not the full transition from one to the other.
>
> I did as I could in SDL. Patching lighting.cpp around line 5251 is
> an idea I'm not yet ready to perform for a continuous gradation. Not
> tonight anyway.
> May be next week... but I want more control than changing it from
> RGB to HSL/HSV hardcoded.
> So reflexion is needed before trying that.
>

I can understand the problem in getting this to work.  It took me a while to
write the SDL code to get smooth transitions.


> A problem with your picture: it only uses saturated colors. What
> about lighter, darker, white & black ?
> Mixing a lighter blue & darker blue ? Not a saturated blue in RGB model.

Here's some new mixes using different shades of red:

Top to bottom:
1. red to dark red
2. red to light red
3. dark red to light red
4. red to black
5. red to white

If there's any particular mix you want I can make an image for you, or I could
post the code.  The difficult trick in the interpolation is that you have to
convert the RGB to HSV/HSL(polar) to XYZ(cartesian) coordinates, interpolate
then convert back XYZ -> HSV/HSL -> RGB.

-tgq

Post a reply to this message

Attachments:
Download 'interp2.jpg' (58 KB)

Preview of image 'interp2.jpg'

Here's a better version of the original one without gamma f***ing it up.  (I
have to stop using PNG, it causes nothing but gamma problems for me).  You can
still see the big differences, particularly between red and green or blue.

The HSL doesn't look to bad here, but I still prefer the RGB (HSV is completely
out...)

-tgq

Post a reply to this message

Attachments:
Download 'interp3.jpg' (68 KB)

Preview of image 'interp3.jpg'

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Here's a better version of the original one without gamma f***ing it up.  (I
> have to stop using PNG, it causes nothing but gamma problems for me).  You can
> still see the big differences, particularly between red and green or blue.
>
> The HSL doesn't look to bad here, but I still prefer the RGB (HSV is completely
> out...)
>
> -tgq

Here's an intersting take on this one.  The transitions are converted to
equal-weighting grayscale (r=g=b=0.333).

Of particular note is the transition from red to blue or green, where the gray
value increases then decreases for both the HSV and HSL, however not as
drastically for the HSL.

-tgq

Post a reply to this message

Attachments:
Download 'interp4.jpg' (52 KB)

Preview of image 'interp4.jpg'

One more interesting little experiment before I pack it in for the day.

Here I interpolated between pure Blue and Red, Green, and Gray with an
equivilant intesity (0.11).  The top shows it in colour and the bottom shows it
converted to grayscale via an external converter.

Here it can be clearly seen that the RGB interpolation retains constant
intensity, whereas the other two do not.

-tgq

Post a reply to this message

Attachments:
Download 'interp5.jpg' (58 KB)

Preview of image 'interp5.jpg'

scott wrote:
> Oh I knocked up a quick program to interpolate between two colours in
> RGB space and Yuv space.  In each pair, the top version is RGB, the
> lower version is Yuv.

  The yuv interpolation doesn't look half-bad.

Post a reply to this message

>> Oh I knocked up a quick program to interpolate between two colours in
>> RGB space and Yuv space.  In each pair, the top version is RGB, the
>> lower version is Yuv.
>
>  The yuv interpolation doesn't look half-bad.

I realised an improvement though.

Although the "colour" part (u and v) is supposed to be interpolated evenly, 
the Y part will not be.  Y is linear luminance, ie not gamma corrected, so 
interpolating it directly will not give a very "even" looking result (there 
will be too much "white").

So I modified the code to do this (now a black-white gradient looks 
identical in both RGB and Yuv interpolation) and it looks a bit better, 
especially when going from dark to light colours.  Again, top bar is RGB and 
lower bar is Yuv.

Also, the problem with converting from RGB to Yuv and back is that it 
assumes your display device is exactly calibrated to a standard (I used sRGB 
in the calculations).  If it's not then the results won't look as good as 
they could.

Post a reply to this message

Attachments:
Download 'interpolation comparison 2.png' (3 KB)

Preview of image 'interpolation comparison 2.png'

"scott" <sco### [at] laptopcom> wrote:
> >> Oh I knocked up a quick program to interpolate between two colours in
> >> RGB space and Yuv space.  In each pair, the top version is RGB, the
> >> lower version is Yuv.
> >
> >  The yuv interpolation doesn't look half-bad.
>
> I realised an improvement though.
>
> Although the "colour" part (u and v) is supposed to be interpolated evenly,
> the Y part will not be.  Y is linear luminance, ie not gamma corrected, so
> interpolating it directly will not give a very "even" looking result (there
> will be too much "white").
>
> So I modified the code to do this (now a black-white gradient looks
> identical in both RGB and Yuv interpolation) and it looks a bit better,
> especially when going from dark to light colours.  Again, top bar is RGB and
> lower bar is Yuv.
>
> Also, the problem with converting from RGB to Yuv and back is that it
> assumes your display device is exactly calibrated to a standard (I used sRGB
> in the calculations).  If it's not then the results won't look as good as
> they could.

I think this does present an interesting result.  Similar to the RGB gradient,
the colour luminance is constantly increasing or decreasing (unlike in HSV or
HSL where it tends to arc up or down past the final luminance and back again),
however following a different path of colour mix.

-tgq

Post a reply to this message

Having seen the differences between the different colour spaces, I think rather
than trying to figure out which is right or wrong (as opinion on this can vary
drastically)  I think it could be of use to be able to implement this in future
POV versions (likely POV4) provided efficient conversion algorithms can be made
(my HSL/HSV algorithm is SDL function based and renders quite slow compared to
the regular RGB gradient).  Anywhere a pattern gradient can be applied, be able
to specify the colour space to use (RGB being default) and have whatever colour
spaces can be properly set up (HSV,HSL,YUV, etc.)

-tgq

Post a reply to this message

Yes, the "brightness" will ramp up or down linearly in gamma-corrected 
space.

The colour will linearly interpolate between two points in the uv plane.

You can see a picture of the uv plane here:

http://content.answers.com/main/content/img/CDE/_CIE1976.JPG

The outer edge are single-wavelength colours, with the wavelengths marked 
on.  If you mix two or more wavelengths you can simply take a weighted 
average of the uv coordinates and that will give you the resulting colour. 
That is essentially what I am doing in my code, varying the % of each colour 
linearly from 0-100%.

The problem occurs when you interpolate from blue to yellow (or any other 
pair either side of white).  In real life, if you mix 50% blue and 50% 
yellow you do get white (it's how most white LEDs work).

To me though it doesn't seem right that if you want a nice colour gradient 
between a strong blue and yellow, you end up with a muddy grey in the 
middle, but then I don't know what else you could do without introducing 
other colours...

Post a reply to this message

>> I'm talking about
>> the CIE Yuv color space, revised in 1976 so that colours are spread
>> equally in the uv plane.  See:
>
> I give up on the evaluation of the spectrum... as for all CIELab,
> L*a*b* and such... it's far too much complex and removed from my
> skill with computer.
> Converting formulaes which request the performance of integration is
> a bit too much.

You actually don't need to do anything with the spectrum.  You just need to 
choose a physical colour-space to work in (sRGB or AdobeRGB are common), and 
then a 3x3 matrix is available to convert from linear RGB values to XYZ. 
Once you have the XYZ colour then it's just a simple formula to convert to 
Yuv.

Of course you can derive the 3x3 matrix from first principles using the 
primary colours' spectrums and viewer functions, but that usually isn't 
necessary.

Post a reply to this message