On Wed, 08 Nov 2000 16:48:36 -0500, Chris Huff <chr### [at] maccom>
wrote:

>But what would the resulting vector be? Would it be a rgb vector, or a 
>hsl, etc...
>#declare Color = color red 0.6 hue 0.75;
>Is Color.x red or hue? Is Color.y green or saturation?
>"color rgb" should only accept red, green, and blue...

Color.x is just a hack used by those who have been RTTL :) If you have
Color.r and Color.hue, why use Color.x and make your life harder? Of
course, for backwards compatibility it should be kept equivalent to
Color.r

Another approach is to use rgb space and automatically convert hsb to
it. So color hsb <2/3,1,1> would make a color rgb <0,0,1>. One may
still access the hsb values of this color, though.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

GrimDude wrote in message <3a0b768a@news.povray.org>...
>Mark, did you ever post a Windows binary? Sorry, but my newsgroup time is
>limited and this thread is full of messages...


Yes.  Use the links from http://www.geocities.com/rengaw03/povray.html


--
Mark

Post a reply to this message

Thank you, sir!

Grim

Post a reply to this message

Chris Huff <chr### [at] maccom> wrote:

> In article <3A0A735E.A48E843C@tapasmail.net>, J?r?me M. Berger 
> <jbe### [at] tapasmailnet> wrote:

>>       Maybe, but OTOH you don't need to specify a color where the object is
>> fully transparent, so their patterns are related. I've never felt the
>> need to specify transparency independently from color...

> Simplest case: a multicolored transparent ball which is evenly 
> transparent and has a big color_map. You decide you want to change the 
> amount of transparency...you have to change every color in the 
> color_map. If you had it specified in a separate block, you would only 
> have to change one value. It would also make specifying transparence for 
> image_maps a lot easier.

Well, this, at least, is easy.  If you want a constant transparency that you
want to be able to change, just declare it as a variable (say, Trans) and
use that in your color map.  All you have to do is change one place.  I
often do this with variables that are used many places (the size of certain
objects in relation to one another, for instance), and are likely to be
changed while tuning the scene.

The transparency for image maps, I agree, though.

Geoff

Post a reply to this message

In article <in0n0ts7vbq5e22kq7rjlb04ib7t4od0pu@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Color.x is just a hack used by those who have been RTTL :) If you have
> Color.r and Color.hue, why use Color.x and make your life harder? Of
> course, for backwards compatibility it should be kept equivalent to
> Color.r

RTTL? Ray Tracing Too Long?
My syntax suggestion was to store all colors as 3D vectors and get rid 
of the r, g, b, red, green, blue, etc... keywords.


> Another approach is to use rgb space and automatically convert hsb to
> it. So color hsb <2/3,1,1> would make a color rgb <0,0,1>. One may
> still access the hsb values of this color, though.

I still don't like the "automatically convert to rgb" part. If I set the 
first component of a vector to 1, the first component should be 1 when I 
come back to it later. If I set a color to hsb <2/3,1,1> and try to put 
a sphere at the point in space equivalent to that point in hsb space 
(say I am making a graphical representation of the relationships between 
colors), I shouldn't get xyz < 0, 0, 1>!
On the other hand, automatic converting would probably make mixing 
colors from different systems easier...

How about this: when you specify a color in a pigment or something, it 
is converted to rgb for internal use, but color variables store the 
color space as well as the components. You could get the rgb version of 
a declared color with "rgb(COLOR)", the hsl version with "hsl(COLOR)", 
etc. These conversion functions use the extra "color space" variable.
You get a parse error if you try to use ".hue" on a rgb color, ".green" 
on a hsl color, etc.
Adding two colors or a color and a vector adds the values of their 
components, ignoring the system they are from. To add two colors of 
different systems, you would usually want something like: "rgb(COL_A) + 
rgb(COL_B)" to be safe.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <3a0bf591@news.povray.org>, Geoff Wedig 
<wed### [at] darwinepbicwruedu> wrote:

> Well, this, at least, is easy.  If you want a constant transparency 
> that you want to be able to change, just declare it as a variable 
> (say, Trans) and use that in your color map.

That is what you have to do now...
And what about blur and other transparency effects? Things like 
fade_color, dispersion, ior, etc. would also fit better in a block 
dedicated to simulating transparency. Transparency just isn't a color 
attribute, and has no business being there.


> The transparency for image maps, I agree, though.

And why not for all textures?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Fri, 10 Nov 2000 17:25:04 -0500, Chris Huff <chr### [at] maccom>
wrote:

>How about this: when you specify a color in a pigment or something, it 
>is converted to rgb for internal use, but color variables store the 
>color space as well as the components.

This seems overkill.

<snip>

I think it should be enough if colors are kept the way they are and
there are introduced parser functions to convert a 3D vector to and
from hsb and rgb. This will keep backwards compatibility and will
offer the user more power. I am not sure how useful this will be,
though, as everything here mentioned can be done with simple macros.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] usanet
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Peter Popov wrote:
> 
> On Fri, 10 Nov 2000 17:25:04 -0500, Chris Huff <chr### [at] maccom>
> wrote:
> 
> >How about this: when you specify a color in a pigment or something, it
> >is converted to rgb for internal use, but color variables store the
> >color space as well as the components.
> 
> This seems overkill.
> 
> <snip>
> 
> I think it should be enough if colors are kept the way they are and
> there are introduced parser functions to convert a 3D vector to and
> from hsb and rgb. This will keep backwards compatibility and will
> offer the user more power. I am not sure how useful this will be,
> though, as everything here mentioned can be done with simple macros.
> 
Seems reasonable. RenderMan Shading Language supports various color
spaces and conversion functions between them, but it is totally up to
coder to ensure, that correct color space is used. If this solution is
usable in "real CGI" world, then it could be used in "amateur league" as
well?
As Einstein said:
Keep it as simple as possible, but no simpler.

Post a reply to this message

In article <kn8v0tkg6h7ddc5j1q81ehvclvanuq06v1@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> I think it should be enough if colors are kept the way they are and
> there are introduced parser functions to convert a 3D vector to and
> from hsb and rgb. This will keep backwards compatibility and will
> offer the user more power. I am not sure how useful this will be,
> though, as everything here mentioned can be done with simple macros.

It would be very simple to do once you have the code for converting 
between the color systems. I can think of two possible ways of doing the 
syntax:
1: Separate rgb_to_hls(), rgb_to_cmy(), rgb_to_hsv() functions.
2: Three functions: rgb_to(COLOR_SYS, COLOR), to_rgb(COLOR_SYS, COLOR), 
convert_color(COLOR_SYS_SRC, COLOR_SYS_DEST, COLOR). This has the 
advantage of being simpler when there are a lot of color systems.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> It would be very simple to do once you have the code for converting
> between the color systems. I can think of two possible ways of doing the
> syntax:
> 1: Separate rgb_to_hls(), rgb_to_cmy(), rgb_to_hsv() functions.
> 2: Three functions: rgb_to(COLOR_SYS, COLOR), to_rgb(COLOR_SYS, COLOR),
> convert_color(COLOR_SYS_SRC, COLOR_SYS_DEST, COLOR). This has the
> advantage of being simpler when there are a lot of color systems.

Actually, this kind of function could be usefull for users, but if in
addition you want to improve the final quality of rendering, Spectral
Color Space has to be implemented into PoV. There's a BIG difference of
quality between an image rendered using spectral space and the same one
rendered in RGB...

S.M.

Post a reply to this message

In article <3A10777B.294FE50F@videotron.ca>, Stephane Marty 
<alb### [at] videotronca> wrote:

> Actually, this kind of function could be usefull for users, but if in
> addition you want to improve the final quality of rendering, Spectral
> Color Space has to be implemented into PoV.

I suspect that in addition to having to rewrite the renderer, you would 
also have to redesign a lot of stuff...you wouldn't be able to use many 
of the old algorithms. Not a small job...even bigger than the planned 
C++ rewrite for POV 4.0. However, it would make some things easier and 
far more accurate...(dispersion, iridescence...)
Maybe 4.0 will be done so some areas could do calculations in spectral 
space and others in RGB, so it would be possible to switch to spectral 
space a bit at a time, and having a working renderer in the meantime.


> There's a BIG difference of quality between an image rendered using 
> spectral space and the same one rendered in RGB...

Do you have any examples? Any links to information on using spectral 
color spaces?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> > Actually, this kind of function could be usefull for users, but if in
> > addition you want to improve the final quality of rendering, Spectral
> > Color Space has to be implemented into PoV.
> 
> I suspect that in addition to having to rewrite the renderer, you would
> also have to redesign a lot of stuff...you wouldn't be able to use many
> of the old algorithms. Not a small job...even bigger than the planned
> C++ rewrite for POV 4.0. However, it would make some things easier and
> far more accurate...(dispersion, iridescence...)
> Maybe 4.0 will be done so some areas could do calculations in spectral
> space and others in RGB, so it would be possible to switch to spectral
> space a bit at a time, and having a working renderer in the meantime.

Yes, I know... :)
I wrote a small (commercial) monte carlo ray-tracing program 3 years ago
able to work *exclusively* in spectral space. It was a bit limited in
texture models, but gave quite good lighting and rendering results.
However, the first version worked in RGB space and my client asked me to
improve it because he suddenly needed to use only spectral colors in his
applications. So, I had to rewrite several functions, actually, every
color and shading manipulation routines...
But you're right, to implement spectral color space rendering in
(mega)PoV from now, every color, light, shading and texture manipulation
functions have to be completly redesigned ; and at this level of
evolution, it won't be an easy task, or at least, it'll take a certain
time...

> > There's a BIG difference of quality between an image rendered using
> > spectral space and the same one rendered in RGB...
> 
> Do you have any examples? Any links to information on using spectral
> color spaces?

I have to find again my links and notes. They should be somewhere in my
archives. I will send an email in this news group when I can put my
hands on it...

S.M.

Post a reply to this message

Stephane Marty wrote in message <3A10A387.872C4863@videotron.ca>...
>But you're right, to implement spectral color space rendering in
>(mega)PoV from now, every color, light, shading and texture manipulation
>functions have to be completly redesigned ; and at this level of
>evolution, it won't be an easy task, or at least, it'll take a certain
>time...


Actually, POV does do a little bit of spectral color space rendering.
Photon mapping with dispersion uses spectral color space, and
wavelength-dependant Rayleigh scattering also has support for spectral color
space.

--
Mark

Post a reply to this message

Chris Huff wrote in message ...
>In article <3A10777B.294FE50F@videotron.ca>, Stephane Marty
><alb### [at] videotronca> wrote:
>> There's a BIG difference of quality between an image rendered using
>> spectral space and the same one rendered in RGB...
>Do you have any examples? Any links to information on using spectral
>color spaces?


I think I have two books about this problem but unfortunatelly in polish
but one of it is translation from english: James D. Foley, Andries van
Dam, Steven K. Feiner, John F. Huges, Richard L. Phillips "Introduction
to computer graphics" (c) 1994, 1990 by Addison Wesley Publishing
Company
as title said this is introduction but with over 300 positions in
bibliography
if anybody want I can scan some parts of chapter about space (but
polish!!!) or scan bibliography

ABX

Post a reply to this message

Wlodzimierz ABX Skiba wrote in message <3a10fb4f@news.povray.org>...
>if anybody want I can scan some parts of chapter about space

of course about color space :-)

ABX

Post a reply to this message