 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
>
> This is one of multiple reasons why I'm trying to figure out a good way
> to convert from RGB to some synthesized spectrum: It'll allow to use
> spectral math inside the render engine, but still use the RGB colour
> model in scenes.
I am not sure why there should be any requirement for spectral ray tracing in
PovRay except perhaps as a secondary specialist choice. Colour and the spectrum
are different identities. Colour does not exist in the physical world, only as
a physiological phenomenon in our eye/head, and in this respect there are only 3
colours. We can not respond to every wavelength in the light spectrum except by
relegating to one of, or a mixture of, our 3 responses. It would, no doubt, make
refraction more interesting but this is bound to be of minority interest among
those who wish to make 3D scenes in 'real' colour. But probably there is more
involved than I realise.
>
> But you're making an interesting point there: Maybe we should also
> provide for more intuitive color models to be used in scenes.
>
> I think it is obvious that one of the three parameters for such a color
> model would need to govern (1) the hue, while the other two should not
> influence it in any way.
I suspect that what you are looking for here does not exist. Among the many ways
of representing colour numerically, RGB has the advantage (if it is an
advantage) of being the closest parallel to our colour vision mechanism. It is
certainly difficult for the novice to visualise the colour represented by RGB
parameters but only to the extent that I have difficulty in visualising the
effect of many other PovRay function parameters.
>
> For easy use with light sources, it should be possible to adjust the
> brightness in the most simple manner possible, i.e. by tweaking just one
> single parameter. Therefore, for any given hue the second parameter
> should govern (2) the saturation, and for any given combination of hue
> and saturation the third parameter should govern (3) the brightness.
>
> There are two other properties that would both be desirable but can't be
> fulfilled together: It would be nice for the third parameter to directly
> specify luminance (i.e. what the .grey component returns). On the other
> hand this would make it extremely difficult to specify a pigment with
> maximum chroma for any given hue, which I'd personally consider a no-go.
>
> The above constraints rule out both chroma- and lightness-based models,
> even though they would have merits of their own. I guess in the end the
> model will inevitably have to be a variation of HSV (aka HSB).
>
> A major open question would be whether to specify the brightness in
> terms of a perceptual or physical scale.
>
The only way for anyone to be sure is to see the colour in front of you. I have
two tools which I use, a colour picker and one which facilitates comparison
with colours already entered (e.g. in an .inc colour map). I can make these
available if anyone is interested and after making them more user-friendly.
> Thinking about it, this type of parameterization might also make it
> easier to convert from user-specified colour to a synthetic spectrum.
Please don't!
I now retreat in the face of greater mathematical minds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.04.2013 14:52, schrieb Bernard:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> This is one of multiple reasons why I'm trying to figure out a good way
>> to convert from RGB to some synthesized spectrum: It'll allow to use
>> spectral math inside the render engine, but still use the RGB colour
>> model in scenes.
>
> I am not sure why there should be any requirement for spectral ray tracing in
> PovRay except perhaps as a secondary specialist choice. Colour and the spectrum
> are different identities. Colour does not exist in the physical world, only as
> a physiological phenomenon in our eye/head, and in this respect there are only 3
> colours. We can not respond to every wavelength in the light spectrum except by
> relegating to one of, or a mixture of, our 3 responses. It would, no doubt, make
> refraction more interesting but this is bound to be of minority interest among
> those who wish to make 3D scenes in 'real' colour. But probably there is more
> involved than I realise.
I do expect benefits in all areas that include colored distance-based
attenuation, such as with fog, absorbing media (including the extinction
effect of scattering media) and interior fading. With an RGB colour
model, these effects invariably exhibit a shift of hue towards the
primaries of the working colour space with increasing density and/or
distance.
That said, as a matter of fact I do plan to implement this feature in an
unofficial version first; whether it'll make its way into official
POV-Ray will depend on how much it will impact render performance, how
much it will actually improve render quality, and how many people will
actually use it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I do expect benefits in all areas that include colored distance-based
> attenuation, such as with fog, absorbing media (including the extinction
> effect of scattering media) and interior fading.
Won't it also vastly improve any scenes where the "light" is not
broadband, eg street lights, LEDs, lasers etc. Would fluorescent
materials be supported?
In theory colometrically correct renders could be produced which I
imagine would open up new markets for POV use (especially if combined
with an unbiased tracing option). We need something to keep increasing
those render times to keep up with new hardware :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 17.04.2013 11:42, schrieb scott:
>> I do expect benefits in all areas that include colored distance-based
>> attenuation, such as with fog, absorbing media (including the extinction
>> effect of scattering media) and interior fading.
>
> Won't it also vastly improve any scenes where the "light" is not
> broadband, eg street lights, LEDs, lasers etc.
I guess so. Though I suppose such scenes are rather uncommon (especially
Sodium street lamp scenes tend to look ugly ;-))
> Would fluorescent materials be supported?
Not right from the start, but it's a possible option for the future.
> In theory colometrically correct renders could be produced which I
> imagine would open up new markets for POV use (especially if combined
> with an unbiased tracing option). We need something to keep increasing
> those render times to keep up with new hardware :-)
:-) Don't worry, we'll find something :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > I do expect benefits in all areas that include colored distance-based
> > attenuation, such as with fog, absorbing media (including the extinction
> > effect of scattering media) and interior fading.
>
> Won't it also vastly improve any scenes where the "light" is not
> broadband, eg street lights, LEDs, lasers etc. Would fluorescent
> materials be supported?
Yes, it will give more physically correct render for strange lights. But the
most important aspect of spectral rendering is more "natural" color behaviour.
The problem of rgb illumination model is that the primary colors are
"orthogonal". So when you say "blue", and "red" they have absolutely nothing in
common. So a red light will give no illumination to red object, and red and blue
objects will have no radiosity effect on each other at all. This is a bit
unexpected usually - you put a primary colored object in a scene, and it seems
almost monochromatic, even if you have reflections and colored lights in a
system - it does not "take" other colors. So in essence, radiosity has too
strong contrast, colors are too sharp, and primary colors don't mix well.
I usually "fake" color overlap by having colors such as <1,0.1,0.1> for red and
so on. But it's not the same. Only spectral rendering will give you true
richness of color - you can have a pure intense color, but it can still react to
environmental illumination in a correct way. A typical example is a car in a
street.
Spectral rendering gives you subtle differences that you don't notice, but you
do notice it looks better. Just like focal blur, HDR environment mapping and
difference between flat ambient and radiosity.
> In theory colometrically correct renders could be produced which I
> imagine would open up new markets for POV use (especially if combined
> with an unbiased tracing option). We need something to keep increasing
> those render times to keep up with new hardware :-)
Sure :) But in this case, I don't even think it will affect the render time that
much. Most of the rendering cost is the raytracing (finding intersections and
normals). Color computation is only a small part of the process, so unless you
have color dispersion in refractions and reflections, you will get a small
overhead (especially if the C++ core behind it is written efficiently).
About flourescence: it seems like a very nice idea. But somehow this opens a
wide array of options (every spectral input color could potentially produce a
different output color of different intensity). It smells more like a
custom-made shader. Having a pigment that is actually a function of input light
color, direction and coordinates, would make more sense in this case, and would
allow flexibility for users to design funny materials (like angle-dependent
colors, fluorescence, anisotropic BDRF functions, color-dependent specularity
angle and possibly a nonlinear response). This is quite a lot to ask from
developers, but it would get easier, if LLVM support actually happens at some
point in the future.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Yes, it will give more physically correct render for strange lights. But the
> most important aspect of spectral rendering is more "natural" color behaviour.
> The problem of rgb illumination model is that the primary colors are
> "orthogonal". So when you say "blue", and "red" they have absolutely nothing in
> common. So a red light will give no illumination to red object, and red and blue
> objects will have no radiosity effect on each other at all.
This is what happens IRL though, isn't it? An sRGB red light source will
have a very narrow spectrum and almost no overlap at all with the
reflective spectrum of an sRGB blue surface, so it will appear black.
I always avoid zero terms in rgb colours too, not because I'm trying to
fake anything but I think it is genuinely more realistic for natural
surfaces and lights.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> This is what happens IRL though, isn't it? An sRGB red light source will
> have a very narrow spectrum and almost no overlap at all with the
> reflective spectrum of an sRGB blue surface, so it will appear black.
>
> I always avoid zero terms in rgb colours too, not because I'm trying to
> fake anything but I think it is genuinely more realistic for natural
> surfaces and lights.
Mostly, a colored light means a tinted glass, which has a broad spectrum (except
for LED). And even if you do have such a light, the material you are
illuminating will certainly not have a narrow reflective spetrum. If you
illuminate with a red light, you will usually be able to get some red component
from a blue material, especially since there is no blue reflected light to
overshadow it. I'm not saying the effect is strong, but it is enough to create
more natural lighting. You can approximate this by just having nonzero
components, but spectral response gives you more flexibility.
It's also easier to get a realistic illumination with different color
temperature light sources. For instance, a dim tungsten light looks quite
orange, but if you just use rgb, you don't notice, that the far-spectrum blue
light is extremely dim - most of the "blue" component comes from more central
wavelengths. This will affect appearance of blue surfaces.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Mostly, a colored light means a tinted glass, which has a broad spectrum (except
> for LED).
It is incorrect to model such a light as srgb <1,0,0>. It should be
modelled by something like <1,0.2,0.1> as you suggested. That isn't a
fake or a hack, that's the sort of srgb value you would get from a broad
spectrum light if you measured it with a colour meter. You'd only get
something like <1,0,0> if you measured an LED or laser.
> And even if you do have such a light, the material you are
> illuminating will certainly not have a narrow reflective spetrum.
Same as above, you shouldn't be modelling surfaces with a colour of
<0,0,1>, that corresponds to an extremely narrow reflective spectrum
that doesn't normally occur IRL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott <sco### [at] scottcom> wrote:
> > Yes, it will give more physically correct render for strange lights. But the
> > most important aspect of spectral rendering is more "natural" color behaviour.
> > The problem of rgb illumination model is that the primary colors are
> > "orthogonal". So when you say "blue", and "red" they have absolutely nothing in
> > common. So a red light will give no illumination to red object, and red and blue
> > objects will have no radiosity effect on each other at all.
> This is what happens IRL though, isn't it? An sRGB red light source will
> have a very narrow spectrum and almost no overlap at all with the
> reflective spectrum of an sRGB blue surface, so it will appear black.
OTOH if you have eg. a pure yellow light, it will look to the human eye
the same as a light with red and green frequencies in appropriate
proportions, but they will illuminate surfaces in radically different
ways. (White surfaces will look about the same under both lights, but
eg. red surfaces won't.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> This is what happens IRL though, isn't it? An sRGB red light source will
>> have a very narrow spectrum and almost no overlap at all with the
>> reflective spectrum of an sRGB blue surface, so it will appear black.
>
> OTOH if you have eg. a pure yellow light, it will look to the human eye
> the same as a light with red and green frequencies in appropriate
> proportions, but they will illuminate surfaces in radically different
> ways. (White surfaces will look about the same under both lights, but
> eg. red surfaces won't.)
The difference with yellow (or any colour other than pure red, green or
blue) in the current RGB system is that it needs at least two non-zero
components (R and G in this case). This means it will illuminate any
surface with a non-zero component in R *or* G in this case. The effect
of this is to simulate a relatively broadband spectrum - only surfaces
with R *and* G zero (ie a pure blue) would appear black.
Obviously this is a limitation (that no colour other than the sRGB
primaries can be simulated as a narrow-band spectrum) - which is what I
meant when I suggested that spectral rendering would improves scenes
with narrowband lights (or even lights with an "interesting" spectrum).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
