POV-Ray : Newsgroups : povray.binaries.images : texture interpolation... why rgb ? Server Time
15 Nov 2024 22:23:56 EST (-0500)
  texture interpolation... why rgb ? (Message 1 to 10 of 25)  
Goto Latest 10 Messages Next 10 Messages >>>
From: Le Forgeron
Subject: texture interpolation... why rgb ?
Date: 27 Nov 2007 15:39:09
Message: <474c806d@news.povray.org>
I'm wondering why, short of historical reason, does the
interpolation of weighted textures(pigment) is performed in the rgb
space.

Wouldn't it be possible to perform it in HSV or HSL space, even for
out of rgb <0,0,0> / rgb <1,1,1> block ?
And wouldn't the result be different and maybe more natural (or not ?)

Linear for SL/SV should be easy, but I'm still wondering about
interpolation of opposite hue: what would be the right solution ?

Could it be chosen per interpolation ?

Attached is a rgb interpolation of the polygon, with various
strength of mix.
-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius


Post a reply to this message


Attachments:
Download 'demoexpl.png' (221 KB)

Preview of image 'demoexpl.png'
demoexpl.png


 

From: Alain
Subject: Re: texture interpolation... why rgb ?
Date: 27 Nov 2007 22:55:12
Message: <474ce6a0$1@news.povray.org>
Le Forgeron nous apporta ses lumieres en ce 2007/11/27 15:38:
> I'm wondering why, short of historical reason, does the
> interpolation of weighted textures(pigment) is performed in the rgb
> space.
> 
> Wouldn't it be possible to perform it in HSV or HSL space, even for
> out of rgb <0,0,0> / rgb <1,1,1> block ?
> And wouldn't the result be different and maybe more natural (or not ?)
> 
> Linear for SL/SV should be easy, but I'm still wondering about
> interpolation of opposite hue: what would be the right solution ?
> 
> Could it be chosen per interpolation ?
> 
> Attached is a rgb interpolation of the polygon, with various
> strength of mix.
> 
> 
> ------------------------------------------------------------------------
> 
Your computer, and most image formats, use the RGB space. So, it's much simpler 
to work in RGB space.
You can work in another colour space, but it's more complex, as you need to 
translate from one to the other. There are some macros to do just that in 
colors.inc.
They are:
CH2RGB()
CRGB2H()
CHSL2RGB()
CRGB2HSL()
CHSV2RGB()
CRGB2HSV()

-- 
Alain
-------------------------------------------------
The strongest reason for the people to retain the right to keep and bear
arms is, as a last resort, to protect themselves against tyranny in
government.
Thomas Jefferson


Post a reply to this message

From: scott
Subject: Re: texture interpolation... why rgb ?
Date: 28 Nov 2007 07:58:02
Message: <474d65da$1@news.povray.org>
> I'm wondering why, short of historical reason, does the
> interpolation of weighted textures(pigment) is performed in the rgb
> space.

Because it's easiest?

> Wouldn't it be possible to perform it in HSV or HSL space, even for
> out of rgb <0,0,0> / rgb <1,1,1> block ?
> And wouldn't the result be different and maybe more natural (or not ?)

Yes, IIRC some paint/drawing program has the option to do this, but I forget 
which one.

> Linear for SL/SV should be easy, but I'm still wondering about
> interpolation of opposite hue: what would be the right solution ?

Use something like Yuv space would be best, Y is the brightness and (u,v) is 
the colour.  But they key point is that equal distances between points in 
the uv plane are perceived as equal "differences" in colour by the human 
eye.  If you interpolate linearly in uv space you should get the most 
"natural" looking gradient without any sharp bits.  You can then just 
interpolate Y separately (maybe linearly or not, gamma is involved).


Post a reply to this message

From: Warp
Subject: Re: texture interpolation... why rgb ?
Date: 28 Nov 2007 09:20:20
Message: <474d7924@news.povray.org>
Le Forgeron wrote:
> I'm wondering why, short of historical reason, does the
> interpolation of weighted textures(pigment) is performed in the rgb
> space.
> 
> Wouldn't it be possible to perform it in HSV or HSL space

  Is HSV interpolation unambiguous?

  Suppose that the two colors you are interpolating between have the
same saturation and brightness, and only differ in hue. How would you
interpolate between them?

  A naive approach would be to interpolate between the separate
components. Since the saturation and brightness are equal in both
colors, their interpolation doesn't produce any change. Thus all that is
 left is interpolating the hue value. This means that if one of the
colors has eg. a red hue and the other a cyan hue, the interpolation
would go through yellow and green (or magenta and blue) producing a
rainbow of colors, which is hardly  what the user wanted.

  Another approach would be to interpolate linearly along the surface of
the hue disc, ie. the ring of colors which have the different hue values
at its border and gray at its center: Place both colors on this disc and
interpolate linearly between the two. The brightness can be interpolated
separately. (I think this effectively makes it an interpolation inside
the hue cone.)
  While this could work, I'm not exactly sure how it's different from a
direct RGB interpolation. I haven't tested it.


Post a reply to this message

From: Le Forgeron
Subject: Re: texture interpolation... why rgb ?
Date: 28 Nov 2007 14:29:21
Message: <474dc191@news.povray.org>
Le 28.11.2007 15:19, Warp nous fit lire :
> Le Forgeron wrote:
>> I'm wondering why, short of historical reason, does the
>> interpolation of weighted textures(pigment) is performed in the rgb
>> space.
>>
>> Wouldn't it be possible to perform it in HSV or HSL space
>   While this could work, I'm not exactly sure how it's different from a
> direct RGB interpolation. I haven't tested it.

I had a try with RGB (the pov current way), HSL & HSV. (see attached
picture)

First row is RGB interpolation
Second HSL
Third HSV.

There is no point in trying YUV/YIQ/Secam/Pal/NTSC... colorspace as
they are matrix transformation of RGB, and as such keep the same result.

First column is Pure colours (<1,0,0>),
Second column is Light colours (<1,0.5,0.5>)
Third column is dark colours (0.5,0,0),
Fourth column is Green & Cyan, with dark & light.

The original colours are in full-disc.
The interpolated colours are in opened-disc, at mid-way between the
used colours. The center open-disc is the interpolation of the three
original colours. The opened-disc on the side is the interpolation
of the three first-level interpolation.

There is differences!
For the management of Shades, I prefer HSL: mixing dark & light
gives normal, which does not happen for HSV nor RGB!

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius


Post a reply to this message


Attachments:
Download 'melange.png' (199 KB)

Preview of image 'melange.png'
melange.png


 

From: scott
Subject: Re: texture interpolation... why rgb ?
Date: 29 Nov 2007 09:10:53
Message: <474ec86d$1@news.povray.org>
> There is no point in trying YUV/YIQ/Secam/Pal/NTSC... colorspace as
> they are matrix transformation of RGB, and as such keep the same result.

Yuv certainly isn't a simple matrix transform, which is why I mentioned it 
earlier.

FYI to convert from RGB to Yuv do the following (via XYZ):

XYZ = [some_matrix] * RGB
(the matrix depends on which colour space your RGB is in, choose sRGB, PAL, 
NTSC whatever)

x = X/(X+Y+Z)
y = Y/(Y+Y+Z)

u = 2*x/(6*y-1.5*x)
v = 4.5*y/(6*y-1.5*x)

Y will give you the "brightness" and uv will give you the colour. 
Interpolating uv linearly will give the smoothest change in colour, as each 
distance in your "picture" will correspond to an equal change in "colour" as 
the eye sees it.


Post a reply to this message

From: scott
Subject: Re: texture interpolation... why rgb ?
Date: 29 Nov 2007 11:14:44
Message: <474ee574$1@news.povray.org>
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.

Actually, I just realised, you were probably thinking of the YUV signals 
used in TV, that are just linear combinations of RGB.  I'm talking about the 
CIE Yuv color space, revised in 1976 so that colours are spread equally in 
the uv plane.  See:

http://hyperphysics.phy-astr.gsu.edu/hbase/vision/cie1976.html


Post a reply to this message


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

Preview of image 'interpolation comparison.png'
interpolation comparison.png


 

From: Le Forgeron
Subject: Re: texture interpolation... why rgb ?
Date: 29 Nov 2007 13:04:48
Message: <474eff40$1@news.povray.org>
Le 29.11.2007 17:14, scott nous fit lire :

> Actually, I just realised, you were probably thinking of the YUV signals
> used in TV, that are just linear combinations of RGB. 
Yes, right.

> 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.


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius


Post a reply to this message

From: Trevor G Quayle
Subject: Re: texture interpolation... why rgb ?
Date: 29 Nov 2007 15:30:01
Message: <web.474f21112088bdecc150d4c10@news.povray.org>
Le Forgeron <jgr### [at] freefr> wrote:
> I had a try with RGB (the pov current way), HSL & HSV. (see attached
> picture)
>

I've been having a look at this.  One problem in your graphic is the
interpolation of opposite colours in HSV and HSL.
You are basically interpolating linearly between individual H,S and V/L values.
The interpolation of H is done in the shortest direction around the
circumference. This poses a problem because there is no logical way to choose
the direction to interpolate H around the circumference, as both directions are
equal in length, so you have chosen to interpolate directly across the colour
space, which creates a discontinuity (eg: check the interpolation of
<1,0,0><0,1,1> compared to <1,0,0><0.001,1,1>, they should be virtually
indistinguishable, but the slight value added to the R value tips the shortest
route from being undefined to defined).  It would be far better to interploate
all colours directly across the colour space to remove this discontinuity.

A second problem I see is that this really only shows the halfway colour, and
not the full transition from one to the other.

The attached image shows interpolation between pure red and the other 5 pure
colours using interpolation across the colour space as described above.

top band: HSV
middle band: RGB
bottom band: HSL

Looking at this, RGB interpolation seems to give the most pleasing transition to
the eye (my eye at least).

-tgq


Post a reply to this message


Attachments:
Download 'interp.jpg' (72 KB)

Preview of image 'interp.jpg'
interp.jpg


 

From: Le Forgeron
Subject: Re: texture interpolation... why rgb ?
Date: 29 Nov 2007 15:52:44
Message: <474f269c$1@news.povray.org>
Le 29.11.2007 21:29, Trevor G Quayle nous fit lire :
> Le Forgeron <jgr### [at] freefr> wrote:
>> I had a try with RGB (the pov current way), HSL & HSV. (see attached
>> picture)
>>
> 
> I've been having a look at this.  One problem in your graphic is the
> interpolation of opposite colours in HSV and HSL.
> You are basically interpolating linearly between individual H,S and V/L values.
> The interpolation of H is done in the shortest direction around the
> circumference. This poses a problem because there is no logical way to choose
> the direction to interpolate H around the circumference, as both directions are
> equal in length, so you have chosen to interpolate directly across the colour
> space, which creates a discontinuity (eg: check the interpolation of
> <1,0,0><0,1,1> compared to <1,0,0><0.001,1,1>, they should be virtually
> indistinguishable, but the slight value added to the R value tips the shortest
> route from being undefined to defined).  It would be far better to interploate
> all colours directly across the colour space to remove this discontinuity.

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.



> 
> 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.

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.

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius


Post a reply to this message

Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.