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