 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(see thread "using assumed_gamma of 1.0... a discussion", located here:
http://news.povray.org/povray.general/thread/%3Cweb.439a1b692d1f46002a1c213f0%40news.povray.org%3E/)
Anyways. My experience is this: I have a nice image_map, I follow the docs
and supply assumed_gamma of 1.0 and have Display_Gamma properly set to 2.2,
and what happens? The image_maps turn out brighter than their source. Why?
Due to the internal gamma correction of POV-Ray.
Personally, I'd like an image-map to look like it's source when its lit with
100% white light (e.g. by applying finish{ambient 1 diffuse 0}), but the
gamma-correction prevents that. The image shows this. The upper-left corner
is the pure image-map in POV-Ray. The lower-left shows the original source.
What's on the right side you ask? Well, the upper right is the image_map
"uncorrected", but passed through my gamma-correction macro using a gamma of
1.0 (to show that it doesn't "harm" the image to pass through the macro).
The lower right is the uncorrected PNG version of the image. PNG comes with
internal gamma values, and POV-Ray makes proper use of them. The problem
lies within the usual floating point (in-)accuracy. If you take a closer
look at the ocean's horizon, you'll notice color-banding and
color-clipping-like effects. That's why I'd rather not use PNGs, at least
not if they're as dark as this source.
Here's the macro:
#macro Gamma_Corrected(Image_Pigment,Gamma)
#local Image_Function =
function{
pigment{Image_Pigment}
}
#declare Gamma_Corrected_Return=
pigment{
average pigment_map{
[1 function{Image_Function(x,y,z).x} poly_wave Gamma color_map{[0 rgb
0][1 rgb 3*x]}]
[1 function{Image_Function(x,y,z).y} poly_wave Gamma color_map{[0 rgb
0][1 rgb 3*y]}]
[1 function{Image_Function(x,y,z).z} poly_wave Gamma color_map{[0 rgb
0][1 rgb 3*z]}]
}
}
//Return value
Gamma_Corrected_Return
#end
All you do is #declare your image_map as a pigment and instead of applying
it directly onto your object, you pass it through the macro, like so:
#declare Image_Map = pigment{image_map{sys "test.bmp"}}
box{-.5,.5 pigment{Gamma_Corrected(Image_Map,1.0)}
finish{ambient 1 diffuse 0}
}
I'll probably add this to my website some time soon, but wanted to get this
on the web for the ones joining the above-mentioned thread and wondering how
to do what they want to do. :-)
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
Attachments:
Download 'gamma_test.jpg' (196 KB)
Preview of image 'gamma_test.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
PS: I should have mentioned that the all but the upper left image have been
passed through the gamma-correction macro. I checked with an image-program
to see if the lower left (so-called "source") is actually as bright as the
source, and it is, and thus I named it "source", even though it's already
been through the macro. Just to clarify.
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been adjusting my textures using a different trick: I filter the
texture over itself and over an opaque white surface, effectively raising
the colour to a power of 2, which isn't perfect gamma correction but it
suits my needs (the texture had to be filtered anyway for some effects I'm
doing).
I was going to do it with functions like you have, but the pigment
definitions came out of poseray and I was too lazy to retype them all :)
--
Tek
http://evilsuperbrain.com
"Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote in
message news:439b2aa2@news.povray.org...
> (see thread "using assumed_gamma of 1.0... a discussion", located here:
>
http://news.povray.org/povray.general/thread/%3Cweb.439a1b692d1f46002a1c213f0%40news.povray.org%3E/)
>
> Anyways. My experience is this: I have a nice image_map, I follow the docs
> and supply assumed_gamma of 1.0 and have Display_Gamma properly set to
> 2.2,
> and what happens? The image_maps turn out brighter than their source. Why?
> Due to the internal gamma correction of POV-Ray.
>
> Personally, I'd like an image-map to look like it's source when its lit
> with
> 100% white light (e.g. by applying finish{ambient 1 diffuse 0}), but the
> gamma-correction prevents that. The image shows this. The upper-left
> corner
> is the pure image-map in POV-Ray. The lower-left shows the original
> source.
>
> What's on the right side you ask? Well, the upper right is the image_map
> "uncorrected", but passed through my gamma-correction macro using a gamma
> of
> 1.0 (to show that it doesn't "harm" the image to pass through the macro).
> The lower right is the uncorrected PNG version of the image. PNG comes
> with
> internal gamma values, and POV-Ray makes proper use of them. The problem
> lies within the usual floating point (in-)accuracy. If you take a closer
> look at the ocean's horizon, you'll notice color-banding and
> color-clipping-like effects. That's why I'd rather not use PNGs, at least
> not if they're as dark as this source.
>
> Here's the macro:
> #macro Gamma_Corrected(Image_Pigment,Gamma)
> #local Image_Function =
> function{
> pigment{Image_Pigment}
> }
> #declare Gamma_Corrected_Return=
> pigment{
> average pigment_map{
> [1 function{Image_Function(x,y,z).x} poly_wave Gamma color_map{[0 rgb
> 0][1 rgb 3*x]}]
> [1 function{Image_Function(x,y,z).y} poly_wave Gamma color_map{[0 rgb
> 0][1 rgb 3*y]}]
> [1 function{Image_Function(x,y,z).z} poly_wave Gamma color_map{[0 rgb
> 0][1 rgb 3*z]}]
> }
> }
> //Return value
> Gamma_Corrected_Return
> #end
>
> All you do is #declare your image_map as a pigment and instead of applying
> it directly onto your object, you pass it through the macro, like so:
>
> #declare Image_Map = pigment{image_map{sys "test.bmp"}}
> box{-.5,.5 pigment{Gamma_Corrected(Image_Map,1.0)}
> finish{ambient 1 diffuse 0}
> }
>
> I'll probably add this to my website some time soon, but wanted to get
> this
> on the web for the ones joining the above-mentioned thread and wondering
> how
> to do what they want to do. :-)
>
> Regards,
> Tim
>
> --
> aka "Tim Nikias v2.0"
> Homepage: <http://www.nolights.de>
>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops, forgot to say: "Good job!" I'll steal your code next time I need to
gamma correct :)
--
Tek
http://evilsuperbrain.com
"Tek" <tek### [at] evilsuperbrain com> wrote in message
news:439b6a95$1@news.povray.org...
> I've been adjusting my textures using a different trick: I filter the
> texture over itself and over an opaque white surface, effectively raising
> the colour to a power of 2, which isn't perfect gamma correction but it
> suits my needs (the texture had to be filtered anyway for some effects I'm
> doing).
>
> I was going to do it with functions like you have, but the pigment
> definitions came out of poseray and I was too lazy to retype them all :)
>
> --
> Tek
> http://evilsuperbrain.com
>
> "Tim Nikias" <JUSTTHELOWERCASE:timISNOTnikias(at)gmx.netWARE> wrote in
> message news:439b2aa2@news.povray.org...
>> (see thread "using assumed_gamma of 1.0... a discussion", located here:
>>
http://news.povray.org/povray.general/thread/%3Cweb.439a1b692d1f46002a1c213f0%40news.povray.org%3E/)
>>
>> Anyways. My experience is this: I have a nice image_map, I follow the
>> docs
>> and supply assumed_gamma of 1.0 and have Display_Gamma properly set to
>> 2.2,
>> and what happens? The image_maps turn out brighter than their source.
>> Why?
>> Due to the internal gamma correction of POV-Ray.
>>
>> Personally, I'd like an image-map to look like it's source when its lit
>> with
>> 100% white light (e.g. by applying finish{ambient 1 diffuse 0}), but the
>> gamma-correction prevents that. The image shows this. The upper-left
>> corner
>> is the pure image-map in POV-Ray. The lower-left shows the original
>> source.
>>
>> What's on the right side you ask? Well, the upper right is the image_map
>> "uncorrected", but passed through my gamma-correction macro using a gamma
>> of
>> 1.0 (to show that it doesn't "harm" the image to pass through the macro).
>> The lower right is the uncorrected PNG version of the image. PNG comes
>> with
>> internal gamma values, and POV-Ray makes proper use of them. The problem
>> lies within the usual floating point (in-)accuracy. If you take a closer
>> look at the ocean's horizon, you'll notice color-banding and
>> color-clipping-like effects. That's why I'd rather not use PNGs, at least
>> not if they're as dark as this source.
>>
>> Here's the macro:
>> #macro Gamma_Corrected(Image_Pigment,Gamma)
>> #local Image_Function =
>> function{
>> pigment{Image_Pigment}
>> }
>> #declare Gamma_Corrected_Return=
>> pigment{
>> average pigment_map{
>> [1 function{Image_Function(x,y,z).x} poly_wave Gamma color_map{[0
>> rgb
>> 0][1 rgb 3*x]}]
>> [1 function{Image_Function(x,y,z).y} poly_wave Gamma color_map{[0
>> rgb
>> 0][1 rgb 3*y]}]
>> [1 function{Image_Function(x,y,z).z} poly_wave Gamma color_map{[0
>> rgb
>> 0][1 rgb 3*z]}]
>> }
>> }
>> //Return value
>> Gamma_Corrected_Return
>> #end
>>
>> All you do is #declare your image_map as a pigment and instead of
>> applying
>> it directly onto your object, you pass it through the macro, like so:
>>
>> #declare Image_Map = pigment{image_map{sys "test.bmp"}}
>> box{-.5,.5 pigment{Gamma_Corrected(Image_Map,1.0)}
>> finish{ambient 1 diffuse 0}
>> }
>>
>> I'll probably add this to my website some time soon, but wanted to get
>> this
>> on the web for the ones joining the above-mentioned thread and wondering
>> how
>> to do what they want to do. :-)
>>
>> Regards,
>> Tim
>>
>> --
>> aka "Tim Nikias v2.0"
>> Homepage: <http://www.nolights.de>
>>
>>
>>
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This looks quite similar to what I did here:
http://news.povray.org/povray.text.scene-files/thread/%3Ce9e0e19dor0jq2boh8l45o73e8ulm1upjq@4ax.com%3E/
Kyle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This looks quite similar to what I did here:
>
>
http://news.povray.org/povray.text.scene-files/thread/%3Ce9e0e19dor0jq2boh8l45o73e8ulm1upjq@4ax.com%3E/
Hm, yeah. Looks much like it, with some changes... Another reason why
patenting software seems quite stupid to some extent: similiar needs will
raise similiar algorithms. I didn't know of your macro, I just went along
with what I found in the docs...
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Oops, forgot to say: "Good job!" I'll steal your code next time I need to
> gamma correct :)
It's not stealing if I allow it. Posting it here doesn't make me appear to
be unwilling to share the code, right? :-)
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Great minds think alike. ;-)
<* ducks and runs before someone has a chance to throw something *>
Kyle
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello POV-folks!
My understanding about gamma is now the following (I made an unforgivable
mistake in my entry for last IRTC entry ... shame on me): if your monitor
is calibrated (ie the operating system compensates your monitor's weakness
on low grays by applying color correction using an appropritate color
profile, typically the most used sRGB color profile) then your system can
be considered as linear, with an overall gamma of 1.0. IS THIS TRUE? If so,
this means that if a pixel has 10% gray value, then your monitor displays
10% of brightness, whatever the file format used.
I guess that ALL not-too-old systems perform this correction. So, according
to me, I would rather agree with Tim, and POV scenes should be designed for
linear display and linear values in output files. This means, if I am not
too wrong, that either both assumed_gamma and Display_Gamma should have the
same value (typically 2.2) or no "assumed_gamma" directive should be in the
code.
The POV documentation recommends a value of 1.0 for assumed_gamma: So I
would say that Display_Gamma should also be set to 1.0. Otherwise the
images would appear too bright (for example the shadowed area (defaulted to
10% of brightness).
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I guess that ALL not-too-old systems perform this correction. So,
according
> to me, I would rather agree with Tim, and POV scenes should be designed
for
> linear display and linear values in output files. This means, if I am not
> too wrong, that either both assumed_gamma and Display_Gamma should have
the
> same value (typically 2.2) or no "assumed_gamma" directive should be in
the
> code.
I think you misunderstood me, I don't think that Display_Gamma and
assumed_gamma should be the same, it's just that when they are the same, the
input images look like I expect them: no gamma correction applied.
I'm not too sure about how displays handle gamma, if they adjust the input
etc. I don't think mine does, but I've yet to read a little about this
mentioned "sRGB"...
What I've done in the past, because that's what POV-Ray's docs say, is to
set assumed_gamma to 1.0. Then, Display_Gamma 2.2 is used to adjust the
final image for the display (which has a gamma of 2.2 in my case, tested
with the image supplied in the docs as well). That's what's in the docs.
Of course, if your monitor "calibrates colors to linear space", you'd have
to set Display_Gamma to 1.0, not 2.2.
My macro simply applies the inverse gamma correction, so that after
POV-Ray's gamma correction, the image input looks like the output. To
achieve that, the gamma given to the macro has to be the same as
Display_Gamma and assumed_gamma should be 1.0. Of course the macro can be
used for other gamma-corrections as well.
(I'm actually thinking about doing some more stuff with functions and
images, to create some sort of simple compositing-script. I tend to be a
little geeky and nerdy about creating my animations/images with pure POV-Ray
(or at least, with some sort of script), cause I like to be sure that I can
reproduce it *exactly* at a later date. :-) )
Regards,
Tim
--
aka "Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
