 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm converting a lot of colors from the Munsell Color System to sRGB.
However, the Munsell gamut seems to be bigger, meaning some of the sRGB
values are greater than 1.
What does POV-Ray do when it encounters colors greater than <1,1,1>?
Since I am more interested in the relative changes between colors than I
am in the absolute color values, would it be okay for me to normalize
all the colors so that the max values are equal to 1?
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.08.2018 um 01:24 schrieb Mike Horvath:
> I'm converting a lot of colors from the Munsell Color System to sRGB.
> However, the Munsell gamut seems to be bigger, meaning some of the sRGB
> values are greater than 1.
That is indeed the case.
> What does POV-Ray do when it encounters colors greater than <1,1,1>?
Nothing special; it just takes them and runs with them. POV-Ray may need
to deal with colour components greater than 1.0 anyway, to represent
bright light and brightly-lit surfaces.
Pretty much the only place where clipping occurs is saving the rendered
image to an actual file, and only if the file format is a classic
non-HDR format.
However, colours with components greater than 1.0 are only "semi outside
gamut", as they're just overly bright variants of in-gamut colours. Far
more problematic are colours that would have /negative/ components in sRGB.
POV-Ray's behaviour when encountering negative colour components is
poorly documented, and there may be features where things get weird.
> Since I am more interested in the relative changes between colors than I
> am in the absolute color values, would it be okay for me to normalize
> all the colors so that the max values are equal to 1?
Normalizing the colours to max values of 1 is boringly trivial, because
in the simplest case it just corresponds to dimming the image (= scaling
all channels uniformly) and/or changing the whitepoint (= scaling
individual colour channels).
As for normalizing the colours so that all values fall in the range
0..1, that's also reasonably simple, because at present, colour
management in POV-Ray is only very rudimentary anyway: If you use any
sRGB-related feature (such as the `srgb` keyword for colour literals, or
the `File_Gamma=sRGB` setting), it is presumed that the colour model is
sRGB, but otherwise you are still free to decide what primaries you want
to assign to R, G and B, including imaginary colours (i.e. colours more
saturated than reality allows), which is what you'll need to get all
components into the 0..1 range.
It must be noted however that /any/ colour computations in a
three-channel colour model is inevitably unrealistic; this is true even
for sRGB. I'm not sure whether e.g. XYZ colour space would fare better
or worse in this respect. My hunch is that the best compromise might be
a colour model where the primaries are imaginary but the gamut does not
fully encompass the entire "spectral horseshoe".
To /really/ get proper colour computations, you'd need to use spectral
rendering, i.e. a colour model where you have, say, 16 or maybe even 32
colour channels, each assigned to a specific frequency band of the
visible spectrum. And of course instead of an sRGB colour you'd have to
specify the actual spectrum of your pigments.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/23/2018 8:32 PM, clipka wrote:
> As for normalizing the colours so that all values fall in the range
> 0..1, that's also reasonably simple, because at present, colour
> management in POV-Ray is only very rudimentary anyway: If you use any
> sRGB-related feature (such as the `srgb` keyword for colour literals, or
> the `File_Gamma=sRGB` setting), it is presumed that the colour model is
> sRGB, but otherwise you are still free to decide what primaries you want
> to assign to R, G and B, including imaginary colours (i.e. colours more
> saturated than reality allows), which is what you'll need to get all
> components into the 0..1 range.
>
What I did was simply record the max values for R, G and B (I think the
max was only ~1.2 for one of the channels and ~1.1 for another) in one
pass (loop), then multiply each color by the inverse of the maximums.
Sort of:
Out_Color = <MyR * 1/MaxR, MyG * 1/MaxG, MyB * 1/MaxB>
The result looks good enough, thought the whites and grays have a slight
greenish tint.
> It must be noted however that /any/ colour computations in a
> three-channel colour model is inevitably unrealistic; this is true even
> for sRGB. I'm not sure whether e.g. XYZ colour space would fare better
> or worse in this respect. My hunch is that the best compromise might be
> a colour model where the primaries are imaginary but the gamut does not
> fully encompass the entire "spectral horseshoe".
>
> To /really/ get proper colour computations, you'd need to use spectral
> rendering, i.e. a colour model where you have, say, 16 or maybe even 32
> colour channels, each assigned to a specific frequency band of the
> visible spectrum. And of course instead of an sRGB colour you'd have to
> specify the actual spectrum of your pigments.
>
Hopefully this will be practical when someone events a single diode that
can change to any color. (I.e. so we don't need three diodes for every
pixel.)
Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.08.2018 um 04:08 schrieb Mike Horvath:
>> It must be noted however that /any/ colour computations in a
>> three-channel colour model is inevitably unrealistic; this is true even
>> for sRGB. I'm not sure whether e.g. XYZ colour space would fare better
>> or worse in this respect. My hunch is that the best compromise might be
>> a colour model where the primaries are imaginary but the gamut does not
>> fully encompass the entire "spectral horseshoe".
>>
>> To /really/ get proper colour computations, you'd need to use spectral
>> rendering, i.e. a colour model where you have, say, 16 or maybe even 32
>> colour channels, each assigned to a specific frequency band of the
>> visible spectrum. And of course instead of an sRGB colour you'd have to
>> specify the actual spectrum of your pigments.
>>
>
> Hopefully this will be practical when someone events a single diode that
> can change to any color. (I.e. so we don't need three diodes for every
> pixel.)
That's irrelevant, as spectral rendering is not about /displaying/
colours, but about /computing/ colours. The end result can still be
converted to sRGB or whatever colour space you prefer.
As an extreme example of what I'm talking about, take sodium light
shining on a red surface: In POV-Ray, the light colour would be modeled
as something around <1,1,0>, and the surface as something around
<1,0,0>. Light bouncing off a surface corresponds to a multiplication
operation, so POV-Ray computes <1,1,0>*<1,0,0> = <1,0,0>, concluding
that sodium light bouncing off a red surface must give a red apparent
colour. But real life instead gives you the ugliest greenish-brown you
can possibly imagine.
This is because unlike most light sources we're familiar with, sodium is
a monochromatic light source that's not really a continuum from red to
green, but rather a single wavelength (well, two actually, but they're
very close together), so whatever material this light is reflected from,
it cannot change in hue, only in brightness.
Using a colour model with 5 spectral bands instead - say Red, Orange,
Yellow, Green, Cyan, Blue - we could model the light as {0,0,5,0,0} and
the surface as, say, {1,.5,.1,0,0}, giving us {0,0,5,0,0}*{1,.5,.1,0,0}
= {0,0,.5,0,0}, concluding that the resulting colour is still
technically yellow, albeit a dim one that we perceive as ugly
greenish-brown.
Note that this will still give wrong results if the light is
monochromatic and, say, halfway between green and cyan. But the result
is still better than with an RGB model, and by increasing the number of
channels we can improve our results even further.
Also note that monochromatic light is just the most extreme and obvious
example; similar effects also happen with continuous spectra. Most
notably, colours will virtually always erroneously drift towards the
dominant primary (i.e. Red, Green or Blue in case of RGB-based models),
especially in volumetric effects (e.g. absorbing media or SSLT), but
also in multi-bounce scenarios (e.g. deep nooks and crannies in a
high-recursion radiosity scene), and even in single-bounce scenarios
(albeit not as pronounced).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
>
> Pretty much the only place where clipping occurs is saving the rendered
> image to an actual file, and only if the file format is a classic
> non-HDR format.
I assume that it also happens in the render preview (which is presented on a
typical low-dynamic-range monitor). For example, rgb <0.3,0.5,0.7> vs.
1.7*<0.3,0.5,0.7> for an object's color. The latter would equate to
<0.51,0.85,1.19>, with the blue being clipped to 1.0-- a shift in not only
brightness but color. (And also depending on the scene's lighting intensity and
color.)
A curious question: Is such clipping of the preview done *by* POV-Ray prior to
the scene being rendered? Or is it done strictly after-the-fact by the (LDR)
monitor and its video card?
>
> However, colours with components greater than 1.0 are only "semi outside
> gamut", as they're just overly bright variants of in-gamut colours. Far
> more problematic are colours that would have /negative/ components in sRGB.
>
> POV-Ray's behaviour when encountering negative colour components is
> poorly documented, and there may be features where things get weird.
>
Here's my own experience with negative color components (and I just re-tested
it):
[For a typical LDR render, and with no radiosity]:
For OBJECT colors:
(with NO lights in scene, and finish{ambient or emission at 1.0}):
Negative color components just 'floor out' at 0.0, no matter how negative they
go:
rgb <0,.3,.6>, <-1,.3,.6,>, <-100,.3,.6> etc. produce the same visual result.
For LIGHTING colors:
The resulting brightness/color of an OBJECT depends on the object's finish-- the
ambient/emission values, and more importantly, the diffuse value. (The diffuse
paremeter in finish decides to what degree a scene's *light* actually affects
the object.) For example:
Example 1:
light: rgb -1.0 (negative)
object's finish: ambient 0.3 emission 0 diffuse 0.2
The diffuse value here (i.e., the object's reaction to *lighting*) is only
20-percent of full 'effect'. So the 'negative' brightness of the light is
*erasing* only a small part of the the overall ambient value, which consequently
has 'more' of a visual effect on the surface brightness than the light-- the
object's surface intensity there is perhaps (1.0 - 0.2)*0.3 (?) (and also
depends on the angle of incidence of the light.) So the object's surface is
still visible, just darker. However...
Example 2:
light: rgb -1 (negative)
object's finish: ambient 0.3 emission 0 diffuse 1.0
Here, the light's effect on the surface is 100-percent-- and since the light's
color/brightness is 'negative', it now overpowers the ambient value 100-percent.
The result is that the object surface is now black-- EXCEPT in the shadows; they
are 'blocked' from the (negative) light source, and continue to show just the
ambient 0.3 value (which BTW is an interesting way to see *just* the shadowed
areas in a render.)
[Actually, my simple equation in the first example may not be truly correct: I
see that an object finish of {ambient 0.3 emission 0 diffuse 0.75} is enough
to make the surfaces appear black, at least on my own monitor. That would be
(1.0 - 0.75)*0.3, which isn't truly 0.0 but 0.075 Maybe my monitor is out of
whack? Or perhaps there are subtle gamma issues that I haven't taken into
account.]
With more complex 'negative' colors for object and light--
like rgb <-0.7,-0.3,0.7> and rgb <0.6,-1.0,0.8>, respectively--
the effect naturally get more complicated, and 'shifts' the resulting
object-surface colors (except in the true shadows!)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 26.08.2018 um 22:30 schrieb Kenneth:
>> Pretty much the only place where clipping occurs is saving the rendered
>> image to an actual file, and only if the file format is a classic
>> non-HDR format.
>
> I assume that it also happens in the render preview (which is presented on a
> typical low-dynamic-range monitor). For example, rgb <0.3,0.5,0.7> vs.
> 1.7*<0.3,0.5,0.7> for an object's color. The latter would equate to
> <0.51,0.85,1.19>, with the blue being clipped to 1.0-- a shift in not only
> brightness but color. (And also depending on the scene's lighting intensity and
> color.)
Yes, of course. I forgot about that one.
> A curious question: Is such clipping of the preview done *by* POV-Ray prior to
> the scene being rendered? Or is it done strictly after-the-fact by the (LDR)
> monitor and its video card?
The clipping of the preview is currently done by the front-end portion
of POV-Ray (specifically, the `ImageMessageHandler` class). Passing HDR
data to the video card (and ultimately to the monitor) would probably
require the use of a special API such as DirectX or some such. If
someone were to pick up the glove of implementing the use of such an API
in POV-Ray, I'm sure we could change the internal interfaces without too
much effort.
However, in that case we should also consider investing more effort into
making sure that the preview is actually close to what will end up in
the image file. So for instance if the image is rendered to an LDR file,
we should show LDR data in the preview window even if the display system
is capable of displaying HDR material.
(A similar problem exists when rendering at low bit depth; currently
we're always previewing at a bit depth of 8 bpc. But since this bit
depth is by far the most common use case, we haven't made any effort to
fix this.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
