POV-Ray : Newsgroups : povray.general : Pov-Ray internal gamma handling : Re: Pov-Ray internal gamma handling Server Time
31 Jul 2024 02:26:38 EDT (-0400)
  Re: Pov-Ray internal gamma handling  
From: JetRacer
Date: 2 Dec 2007 11:30:01
Message: <web.4752c3f94ecc714e2a5d3f2a0@news.povray.org>
> Strong voice will not give you anything here.

Sorry, i was emphasizing. Not intended as screaming.

> > The second one admits that image data is not linear one must also accept the
> > fact that image processing requires import/export convertion.
>
> First, go looking at the code, and learn about PNG file format.

Again, this is unrelated to image en/decoding. The result of a test is identical
in PNG BMP and TGA:

global_settings{assumed_gamma 2.2 ambient_light 1}
background{rgb 0.5}
camera{orthographic location <0,0,-4> up<0,2,0> right<8/3,0,0> look_at <0,0,2>}
#declare My_Texture=texture{pigment{gradient x color_map{[0 rgb 0][1 rgb 1]}}
finish{ambient 1 diffuse 0}}
box{-1,1 texture{My_Texture}}

Note: my system_gamma also set to 2.2.

Lets take this real slow one more time. If I create a b/w raster by hand
directly in any image processor on the planet and shrink it to 50% and
investigate the result (still not saving/loading) will be solid 127 gray.
This is wrong; the result should be level 186 on a gamma 2.2 system. This is
the conventional "we pretend the problem doesn't exist" approach (this is thread
is NOT about following the lemming convention). Pov-Ray also function in this
flawed tradition (level 127 is in center in the example above regardless of
image format) and my point is that it's wrong and it doesn't have to work this
way because Pov-Ray (being an excellent piece of code) have what it takes to do
things right.

Replace assumed_gamma 2.2 with 1.0 in the example above (only works in <=v3.6)
and exchange white with colors like <1,0.5,0> or <0,0.5,1> and you'll notice
that the gradients actually looks natural (like in ads created by
professionals) for a change. And they do that because pov-ray (unintentionally)
handles graphics the correct way. Also note that system_gamma (left unchanged)
is what desides output image gamma, not assumed_gamma which handles script
colors.

Fact: I've used Pov-Ray almost daily for over 5 years and I'm a graphics pro
that does photography on the side which means I know the inner workings of
color profiles including the finer details of gamma/gamut and whitepoint
compensation. I'm also experienced with programming. I know what I'm doing so
stop posting about PC/Mac gamma convertion and PNG decoders bad habit of
falling back on gamma 2.0 related blaha. Water under the bridge, etc.

I know that programmers generally wouldn't be able to give an answer to what
Gamut or d-slr is even at gunpoint (no offence intended). And just knowing the
answer doesn't necessarely mean that you know what the answer means. If this
seems like a fitting description then this discussion is way, way over your
head and you should really take the time to read the above and assume that I
refer to true facts.

Feel free to shoot holes in my argumentation that ieee addition / multiplication
cannot process unlinear math as-is with a correct result. And as a consequence
it's not possible to load a gamma 2.2 image texture into pov-ray using gamma
2.2 mode, let it produce some cool gamma 2.2 output and expect a correct
result.

This is old new in the graphics dept when working with a 48-bpp reproduction
chain.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.