 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Image_maps using png images are gamma corrected, which is bad, because the
entire image of the scene is also gamma corrected, so the image_maps are
gamma corrected twice. Image_maps should never be gamma corrected. This was
discussed years ago IIRC, but I can't find the thread right now.
The scene below should illustrate the problem. When rendered as an animation
it places itself in its own image, and the gamma issue becomes obvious. Can
anyone confirm?
// save the code in a file "pnggamma.pov"
// command line settings:
// +kff4 +kc +fn
background {rgb 0.7}
#default {finish {ambient 1}}
plane {y, -5 pigment {rgb 0.5}}
#declare Frame = ceil(clock*4-0.5);
sphere {<-1.1,0,3>,0.5 pigment {red 0.7}}
#if (Frame>0)
box {0,1
#local Img =
concat("pnggamma",str(Frame,1,0),".png")
pigment{image_map{png Img}}
scale <2,1.5,1.5> translate <-0.5,-0.75,3>
}
#end
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can confirm this. What's even stranger is that if you add an assumed_gamma
statement to the scene file, it works fine -- no matter what the
assumed_gamma is! Why does it behave differently without an assumed_gamma?
Anders
--
light_source{6#local D#macro B(E)#macro A(D)#declare#declare C=mod(E
D);E=(E-C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(C<3)
}cylinder{0(C=<1 2>).2translate<D+C*A(2)A(4)#else}intersection{torus
{1 .2}box{-2y}rotate<1 0C>*90translate<D+1A(2)*2+1#end-2 13>pigment{
rgb x}finish{specular 1}#end#end#end=-8;1B(445000298)B(519053970)B(
483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3c817af3@news.povray.org Rune wrote:
> Image_maps using png images are gamma corrected, which is bad,
> because the entire image of the scene is also gamma corrected, so the
> image_maps are gamma corrected twice. Image_maps should never be
> gamma corrected.
Shouldn't they always be corrected to gamma=1 ?
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" wrote:
> Shouldn't they always be corrected to gamma=1 ?
That might be the issue. I'm no expert on the field, I just know that it
currently doesn't work the right way...
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> Image_maps should never be gamma corrected.
This would really be the best situation. There are so many broken
programs when it comes to png gamma. Adding another layer of confusion
in povray is asking for trouble.
In an ideal world povray could could do nothing for images tagged as
gamma 1 and reverse gamma other images. Then if someone wants as-is images
he tags it as gamma 1 in an image editor. But this doesn't really work
because of so many broken image editors.
I was going to test with povray generated png but it still writes
the wrong gamma in the png. I will use TweakPNG to manually set gamma 1
to the linear test image. (I would expect not using assumed_gamma or
using assumed_gamma=Display_Gamma would produce gamma 1 png.)
This is what happens now to the _image_map_:
map gamma no assumed_gamma assumed_gamma 1 assumed_gamma 2.2
1 no correction no correction gamma 2.2
2.2 gamma 1/2.2 gamma 1/2.2 no correction
So if you put gamma 1 in the png and use assumed_gamma 1 or don't use
assumed_gamma the map is used as-is. Or you set:
map gamma=assumed_gamma=Display_Gamma.
Maybe it's easiest not use pngs as image maps :)
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo <ray### [at] engineer com> wrote in
news:3C8220B6.36773D3D@engineer.com:
> Rune wrote:
>> Image_maps should never be gamma corrected.
> This would really be the best situation. There are so many broken
> programs when it comes to png gamma.
I realize this is a probably feature request, but what might be best here
is to provide a means to manually specify the gamma of an image map (e.g.
image_map {... assumed_gamma X}). This would be exceptionally useful for
dealing with image formats which don't store gamma values and for using the
same image maps in scenes with different assumed_gamma values without
keeping copies of the same map at different gamma values.
This is something to keep in mind for 4.0, I think.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
