 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-9-2011 11:41, clipka wrote:
> Am 12.09.2011 09:08, schrieb Thomas de Groot:
>> Remains my question: when to use the term 'srgb' in POV-Ray code?
>
> That question has a very, very simple answer in 3.7:
>
> -----------------------------------------
> Use "srgb" whenever you get a color value
> from an external application(*).
> -----------------------------------------
>
> (*unless you know what you are doing)
>
> And yes, it's really that straightforward; no caveats regarding
> assumed_gamma or #version in this context.
Yes, that is finally also the conclusion I have reached after reading
this thread. Fair enough and thanks for the info and the patience :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> But I suggest everyone to calm down a bit; There are two approaches to
> working with colors in POV-Ray: (1) Using assumed_gamma 1.0 for
> photorealism, and (2) using assumed_gamma 2.2 (or something alike) for
> more pleasant brightness gradients in color_map and the like. Warp has
> always been a proponent of the latter, while you and I are proponents of
> the former, but at present it must be conceded that both have their
> benefits.
The major problem I see with assumed_gamma 1.0 is that designing textures
becomes more complicated, because textures are usually designed by how they
should look rather than what their absolute irradiance values are.
If you are only specifying individual colors, then using 'srgb' takes
care of that. However, patterns present a problem. Usually you want
patterns to interpolate linearly from one color to another (with what
I mean that the interpolation should *look* linear).
As a simple example, one would expect
color_map { [0 srgb 0][0.5 srgb 0.5][1 srgb 1] }
to look identical to
color_map { [0 srgb 0][1 srgb 1] }
(With assumed_gamma 2.2 it does, but obviously not with assumed_gamma 1.0.)
The problem is that with assumed_gamma 1.0 the gradient will be linear
in terms of irradiance rather than in terms of perceived brightness.
I understand that some work will be done to alleviate this problem.
Optimally one should be able to define entire textures with an "assumed
gamma" other than 1.0, which would make those gradients look linear.
Until that time using assumed_gamma 2.2 is just more convenient in many
cases, even if it technically speaking produces an incorrect rendering.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> That question has a very, very simple answer in 3.7:
> -----------------------------------------
> Use "srgb" whenever you get a color value
> from an external application(*).
> -----------------------------------------
Actually I would use it otherwise as well. For example, if I want a
50% gray, I'd specify "srgb 0.5" because it's more convenient than
calculating the proper rgb with a formula.
Or is there are more "kosher" way of getting a 50% gray color?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 20:55, Warp wrote:
> The major problem I see with assumed_gamma 1.0 is that designing textures
> becomes more complicated, because textures are usually designed by how they
> should look rather than what their absolute irradiance values are.
>
> If you are only specifying individual colors, then using 'srgb' takes
> care of that. However, patterns present a problem. Usually you want
> patterns to interpolate linearly from one color to another (with what
> I mean that the interpolation should *look* linear).
Unless I completely misunderstand the workings of gamma, I believe this
macro should be able to help you:
--- START CODE ---
#declare noWrap=function(x) {max(min(x,1),0)}
#macro pigmentDegamma(Pigment,Gamma)
#local PigmentFunction=function {pigment {Pigment}}
#local Result=pigment {
function {noWrap(PigmentFunction(x,y,z).transmit)}
pigment_map {
[0
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0]
[1 red 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0]
[1 green 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0]
[1 blue 1]
}
poly_wave Gamma
]
}
]
[1
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0 transmit 1]
[1 red 1 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0 transmit 1]
[1 green 1 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0 transmit 1]
[1 blue 1 transmit 1]
}
poly_wave Gamma
]
}
]
}
}
Result
#end
--- END CODE ---
To be used as:
#local Pigment=pigment { [your pigment] }
object {YourObject pigment {pigmentDegamma(Pigment,2.2)}}
Limitations:
- only works with pigments that don't need any surface information (eg:
aoi will not work)
- "filter" isn't taken into account yet, but that should actually be
rather easy to fix.. but since I almost never use filter, I didn't
bother fixing it :)
- only works with pigments with colors in the 0-1 range. I have no idea
how easy it would be to fix that, as just dividing the original colors
before degamma'ing them, and then multiplying them again by that same
value would not give the correct colors
But still, it might be useful :)
cu!
--
ZK
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> On 12/09/2011 20:55, Warp wrote:
>> The major problem I see with assumed_gamma 1.0 is that designing textures
>> becomes more complicated, because textures are usually designed by how
>> they
>> should look rather than what their absolute irradiance values are.
>>
>> If you are only specifying individual colors, then using 'srgb' takes
>> care of that. However, patterns present a problem. Usually you want
>> patterns to interpolate linearly from one color to another (with what
>> I mean that the interpolation should *look* linear).
Fun fact: With assumed_gamma 2.2, visually pleasing /brightness/
gradients are easy to accomplish, but /color/ gradients may be
excessively difficult to get right (depending on the colors involved),
while those are a piece of cake with assumed_gamma 1.0.
As an example, try the following gradient:
[0.0 color srgb <1,0,0> ]
[0.5 color srgb <0,0.8,0> ]
[1.0 color srgb <1,0,0> ]
With assumed_gamma 2.2, the transition features a significant ditch in
brightness between the two colors. Not so with assumed_gamma 1.0, which
maintains roughly the same brightness level throughout the whole transition.
So to make it easy to achieve visually pleasing gradients for both
brightness /and/ color gradients, a new feature needs to be added to
POV-Ray anyway, to get the best of both worlds.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12/09/2011 22:15, Zeger Knaepen wrote:
> [0 red 0]
> [1 red 1]
that should of course be "red 3", and the same for green and blue...
corrected code:
--- START CODE ---
#declare noWrap=function(x) {max(min(x,1),0)}
#macro pigmentDegamma(Pigment,Gamma)
#local PigmentFunction=function {pigment {Pigment}}
#local Result=pigment {
function {noWrap(PigmentFunction(x,y,z).transmit)}
pigment_map {
[0
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0]
[1 red 3]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0]
[1 green 3]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0]
[1 blue 3]
}
poly_wave Gamma
]
}
]
[1
average
pigment_map {
[1 function {noWrap(PigmentFunction(x,y,z).red)}
color_map {
[0 red 0 transmit 1]
[1 red 3 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).green)}
color_map {
[0 green 0 transmit 1]
[1 green 3 transmit 1]
}
poly_wave Gamma
]
[1 function {noWrap(PigmentFunction(x,y,z).blue)}
color_map {
[0 blue 0 transmit 1]
[1 blue 3 transmit 1]
}
poly_wave Gamma
]
}
]
}
}
Result
#end
--- END CODE ---
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 12-9-2011 23:33, clipka wrote:
> So to make it easy to achieve visually pleasing gradients for both
> brightness /and/ color gradients, a new feature needs to be added to
> POV-Ray anyway, to get the best of both worlds.
LOL
So if only for that, this discussion has been quite useful! ;-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
> So if only for that, this discussion has been quite useful! ;-)
>
> Thomas
Found this discussion really helpfull. Been wondering for years why POVRay
output always looks so blown on the white side. Only thing, does anyone know how
to do the same to an image map? Should you save the file with a linear RGB color
profile? How would you do this?
Thanks
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Grim Reaper wrote:
> Thomas de Groot <tenDOTlnDOTretniATtoorgedDOTt> wrote:
>> So if only for that, this discussion has been quite useful! ;-)
>>
>> Thomas
>
> Found this discussion really helpfull. Been wondering for years why POVRay
> output always looks so blown on the white side. Only thing, does anyone know how
> to do the same to an image map? Should you save the file with a linear RGB color
> profile? How would you do this?
Actually, if you use a file format such as PNG that is gamma aware
the results should already be correct in 3.7. For other file formats,
or to override this behavior, you can use the gamma keyword in the
image_map.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 25.09.2011 23:59, schrieb Grim Reaper:
> Found this discussion really helpfull. Been wondering for years why POVRay
> output always looks so blown on the white side. Only thing, does anyone know how
> to do the same to an image map? Should you save the file with a linear RGB color
> profile? How would you do this?
For POV-Ray 3.6, you would indeed need to convert image maps to a linear
RGB color profile (unless you're using "assumed_gamma 2.2"), or convert
to Radiance HDR and use MegaPOV. To preserve the full dynamic range of
the original material, I'd recommend using 16 bit per color channel.
With POV-Ray 3.7, and presuming you're using a "#version 3.7" directive,
most image maps should be fine "as is". PNG files are handled
automatically (provided they have a proper gAMA and/or sRGB chunk), same
goes for OpenEXR and Radiance HDR (which are linear by definition); for
any other files, POV-Ray 3.7 will presume that they're sufficiently
close to the sRGB profile. In the rare event of POV-Ray 3.7's
automatisms failing, you can override them by using the "gamma"
statement in the image_map.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
