I have a humble suggestion to expand the colors present in colors.inc.

The table below provides a list of the X11 colors supported by popular browsers:

http://www.w3.org/TR/css3-color/#svg-color

Would not it be useful to include it?

And the wonderful macro HTML2RGB, by Warp? :

http://news.povray.org/povray.newusers/message/%3C418699ac%40news.povray.org%3E/#%3C418699ac%40news.povray.org%3E

Thanks for your attention.

Regards

Post a reply to this message

"Carlo C." <nomail@nomail> wrote:
> I have a humble suggestion to expand the colors present in colors.inc.
>
> The table below provides a list of the X11 colors supported by popular browsers:
>
> http://www.w3.org/TR/css3-color/#svg-color
>
> Would not it be useful to include it?
>

Yes, it would!
And - GOOD NEWS - it has been done years before, see HERE:
http://home.pacbell.net/tylereng/index.html
and look for KOLORS.INC and KOLORS2.inc

I haven't checked for ALL of the colors mentioned in your first link,
but a few random samples are all present, and much more...

Happy raytracing and a nice weekend

Karl

Post a reply to this message

I'm working on colors.inc to propose it as a new include for POV-Ray 3.7,
despite the fact that I am still quite ignorant, especially as regards POV-Ray.

Some colors of the "old" include have the same name but not the same parameters
of the colors recommended by the W3c consortium.
How can we solve the problem?

Perhaps in this way? :

#if (version=3.7) #declare Coral = rgb <1,127/255,80/255>;
#else #declare             Coral = rgb <1,0.498039,0>; #end

Thank you for your feedback.

Regards

Post a reply to this message

Le Wed, 08 Oct 2008 11:00:40 -0400, Carlo C. a modifié des petits morceaux
de l'univers pour nous faire lire :


> Perhaps in this way? :
> 
> #if (version=3.7) #declare Coral = rgb <1,127/255,80/255>; #else
> #declare             Coral = rgb <1,0.498039,0>; #end
> 
> Thank you for your feedback.

Beware of gamma... W3C probably has not the same gamma as povray now.
Things are fine for <1,0,0> / #FF0000, but #C00000 might be only 
<0.5,0,0>, while #7F7F7F being only <0.25,0.25,0.25>
(fictional numbers here, check your gamma curves!)

To sum up, conversion from W3C colorspace might not be linear for a 
povray include.

Getting colour which change from version is also a bad idea: you are not 
parsing it each time you need it, but usually only once... what about 
scenes with some parts in 3.6 and other parts in 3.7 ? How would you 
handle that ?

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
>
> Beware of gamma... W3C probably has not the same gamma as povray now.
> Things are fine for <1,0,0> / #FF0000, but #C00000 might be only
> <0.5,0,0>, while #7F7F7F being only <0.25,0.25,0.25>
> (fictional numbers here, check your gamma curves!)
>
> To sum up, conversion from W3C colorspace might not be linear for a
> povray include.
>
> Getting colour which change from version is also a bad idea: you are not
> parsing it each time you need it, but usually only once... what about
> scenes with some parts in 3.6 and other parts in 3.7 ? How would you
> handle that ?

Thank you for your comments.
Gamma correction: Alas, I am not sufficiently prepared on this subject.

However ...
I have a Windows system, and my assumed_gamma is 2.2 by default.
If I want with POV-Ray a background Coral, and I put my picture in a HTML file
with the background of CSS set to Coral, I know with certainty that the two are
the same background.

Sure, maybe it's not correct to change the colors of the old colors.inc.
Perhaps a better solution would be then to add, for example:

X11_Coral = ... ?

I would be happy to your further clarification.

Greetings

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Beware of gamma... W3C probably has not the same gamma as povray now.

  I thought the whole idea of gamma correction was that you *don't* have
to worry about whether <.75, .75, .75> "looks right". In other words,
<.75, .75, .75> should always look the same in all systems, assuming those
systems have a proper gamma correction set up. In other words, you don't
have to be modifying that value depending on which "gamma" is being used
but you are able to always use the same absolute value and let the target
system do the necessary corrections. Which is the whole idea of gamma
correction.

  You are reversing the situation completely and basically saying that
because of gamma correction you *must* always fine-tune that color value
by hand. I think that would completely nullify the whole idea of gamma
correction.

  Besides, if you want to change the gamma of the colors used in POV-Ray,
the correct place is not the color definitions themselves, but the assumed
gamma setting of POV-Ray ('assumed_gamma' global setting in pov3.6).

-- 
                                                          - Warp

Post a reply to this message

>  I thought the whole idea of gamma correction was that you *don't* have
> to worry about whether <.75, .75, .75> "looks right". In other words,
> <.75, .75, .75> should always look the same in all systems, assuming those
> systems have a proper gamma correction set up.

POV works in linear colour space though, not gamma corrected.  So when you 
supply colours or textures to POV, you need to inverse gamma correct them 
first, to get correct results.

IMO POV should have an option to do this automatically, as people are used 
to knowing what <0.75,0.75,0.75> looks like on their desktop (eg by using 
Paint or HTML).  <0.75,0.75,0.75> in a POV colour statement or a texture 
used by POV means something different currently.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> IMO POV should have an option to do this automatically

  It has had that for a long time: assumed_gamma.

-- 
                                                          - Warp

Post a reply to this message

>> IMO POV should have an option to do this automatically
>
>  It has had that for a long time: assumed_gamma.

That only works at the output of the rendering engine though, it needs to 
also apply the inverse to any colours/textures at the input of the rendering 
engine.  Otherwise you need to do the inverse-gamma hack to images and 
colours to make things look right.

eg try rendering background{ color rgb <255,128,64>/255}

If the user has chosen that colour to match something else outside of POV, 
it's not going to work unless you turn off gamma correction in POV, which 
would then mean any lighting in your scene will be wrong.

The point is, most users expect that entering a colour value or supplying an 
image_map to be in their desktop colour space (ie already gamma corrected), 
but POV treats these things as being in linear colour space.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> IMO POV should have an option to do this automatically
> >
> >  It has had that for a long time: assumed_gamma.

> That only works at the output of the rendering engine though

  No, assumed_gamma is used for all the input values. To modify the
output image, the display gamma command-line option is for that (this
is, AFAIK, what gets written to the PNG file when outputting to one).

-- 
                                                          - Warp

Post a reply to this message