First off; my apologies to moderators (you know why). Please don't hit me, I'm
just poor little house elf...

Have the subject of enforcing internal use of gamma 1.0 (linear) come up here
before?

-I searched the site but found nothing that wasn't related to PC/Mac issues
(which has nothing to do with the above). If not, then here goes:

Images are saved as inverse gamma 2.2 and are not linear as many people assume.
The screen is gamma 2.2 and together with the graphics the end result is
linear. The point is that computer math can't handle unlinear data (like
computer images); such must be converted to linear, processed and then
converted back to the unlinear format.

No current graphics application does this since loss-less convertion requires
32-bpp or float storage. Which means graphics history buffers grow by four
times (or more) and effectively makes realtime editing impossible. Since no-one
can fix the bug and since it's an advanced subject the traditional solution have
been to simply let ignorance reign (among both users and developers).

The simplest example of this common bug is when shrinking a 50% b/w raster. The
result is always level 127 (8-bpp) when it really should be level 186/174
(PC/Mac). Likewize, blending color <1,0,0> with <1,1,0> in povray results in
<1,0.5,0> when it really should be <1,0.73,0>/<1,0.68,0> (PC/Mac).

Unlike 99.999% of the graphics software out there Pov-Ray doesn't have history
buffers and already use floats everywhere. It also features an 8-bpp specific
bug...

The quick and dirty workaround is to use assumed_gamma = 1.0 and system_gamma
2.2. This will cause Pov-Ray to use gamma 1.0 internally. The problem is just
that all script colors are enterpreted as gamma 1.0 aswell and therefore must
be converted manually (no fun) and the Pov-Ray color includes are made useless.
Images behaves correct - aslong as they feature a color profile. So there's
severe drawbacks to this "fix".

If nothing else I've repeated the issue in a concise way so the post can be used
as reference in the future...

Post a reply to this message

JetRacer wrote:
> If nothing else I've repeated the issue in a concise way so the post can be used
> as reference in the future...

You seem rather confused about the subject of gamma correction. Why did you
think you are an authority on the subject? - A long post such as yours, with
lots of confusing and unfounded statements, is the best way to destroy your
credibility upfront...

	Thorsten

Post a reply to this message

> You seem rather confused about the subject of gamma correction.

This has ZERO relevance to gamma CORRECTION; I wrote the exact phrase "gamma
HANDLING" specificly to reflect that.

Read the post carefully: loads of graphics software ignores the fact that
graphics is not stored in a linear format(!!!). Standard addition and
multiplication cannot handle unlinear data. Such data must be converted
back/fourth to give accurate results. It's the equivalent of adding two log
graphs together _after_ the log function is applied to both; the result is
inevitably wrong:

Log(X)+Log(X) != Log(X+X)

Likewize:

pow(0.5,1/2.2)+pow(0.5,1/2.2) != pow(0.5+0.5,1/2.2)

In all CCD hardware (digital cameras, scanners, etc) the hardware format is
16-bpp gamma 1.0 (to support accurate image processing) which is then converted
to 8-bpp gamma 2.2 (IEC sRGB). This is also how the RAW format for dslr cameras
works in order to support loss-less and accurate image processing.

Programmers do this common error repeatedly:

Pixel = sin(variable)* 127.5+127.5

Which is TOTALLY WRONG!!! This is the way to do it (assuming gamma 2.2):

Pixel = pow(sin(variable)*0.5+0.5,1/2.2)*255

If anyone have a problem with my statement that graphics is not stored linear
format then please read the sRGB documentation which clearly states this fact.
....Scrap that. I searched the web and unfortunatley found out that the IEC
standards is only available as paperback copy (sigh). No wonder knowledge is
scarse. What red tape eating.. ..gibbons!

The second one admits that image data is not linear one must also accept the
fact that image processing requires import/export convertion.

Post a reply to this message

Le 02.12.2007 13:41, JetRacer nous fit lire :
>> You seem rather confused about the subject of gamma correction.
> 
> This has ZERO relevance to gamma CORRECTION; I wrote the exact phrase "gamma
> HANDLING" specificly to reflect that.

Strong voice will not give you anything here.

> 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.
Next, before exposing your great universal purpose on our dumb heads,
take the time to ask real questions and check the opinions of others
on the subject.

Last... here a trouser and a shirt for you.

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

JetRacer wrote:
> This has ZERO relevance to gamma CORRECTION; I wrote the exact phrase
> "gamma HANDLING" specificly to reflect that.

The two are the exact same thing. What you are actually talking about (well,
want to talk about) are color spaces. -- So to answer your question: POV-Ray
uses a (practically) unlimited linear RGB color space internally.

> If anyone have a problem with my statement that graphics is not stored
> linear format then please read the sRGB documentation which clearly states
> this fact.

Do you even understand what you are claiming??? - It should be obvious that
such a statement cannot and would not be in any standard because a standard
is the formal definition of an agreement between several parties, not the
description of an absolute truth.

I won't even go into details of your claims about CCDs, which demonstrate a
complete lack of understanding of the functioning of a CCD (hint: the "bits"
come from an A/D conversion). Or the implementation detail of most digital
camera "raw" formats.

Either way, this has nothing to do in any way with how POV-Ray internally
handled colors. It has (a little bit) to do with reading and writing image
formats supported by POV-Ray. I think it is sufficient to say that the
handling of image formats by POV-Ray is (mostly) correct within the scope of
the libraries that it uses to read those formats, which does include gamma
correction and color space conversions (for HDR formats).

	Thorsten

Post a reply to this message

> 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

To Thorsten (you posted while I was replying to the above post):

> So to answer your question: POV-Ray uses a (practically) unlimited linear RGB >
color space internally.

Ofcourse it does. That my whole point. But when you enter a color you enter a
gamma 2.2 color and Pov.Ray just thinks "what the hell" and treats it as if it
was it's internal linear format (doing nothing if system_gamma and
assumed_gamma is 2.2).

Likewize it mangles images this way. It converts f.ex. a Mac image to PC gamma
(system_gamma says so), but it does not convert the image to it's own internal
linear (= gamma 1.0) format.

Please, please (on my knees begging) tell me that you understand the
implications of this and why this is the wrong thing to do.


"I'M NOT AN ANIMAL!!!"

Post a reply to this message

JetRacer wrote:
> To Thorsten (you posted while I was replying to the above post):
> 
>> So to answer your question: POV-Ray uses a (practically) unlimited linear RGB >
color space internally.
> 
> Ofcourse it does. That my whole point. But when you enter a color you enter a
> gamma 2.2 color and Pov.Ray just thinks "what the hell" and treats it as if it
> was it's internal linear format (doing nothing if system_gamma and
> assumed_gamma is 2.2).
> 
> Likewize it mangles images this way. It converts f.ex. a Mac image to PC gamma
> (system_gamma says so), but it does not convert the image to it's own internal
> linear (= gamma 1.0) format.
> 
> Please, please (on my knees begging) tell me that you understand the
> implications of this and why this is the wrong thing to do.

*plonk*

Post a reply to this message

JetRacer wrote:
> But when you enter a color you enter a gamma 2.2 color

No. What makes you think that? You enter a linear (gamma 1.0) color.

> The quick and dirty workaround is to use assumed_gamma = 1.0

That's not a quick and dirty workaround, that's the correct solution. 
See <http://www.povray.org/documentation/view/3.6.1/260/> ("For new 
scenes, you should use an assumed gamma value of 1.0 as this models how 
light appears in the real world more realistically.").

(I've never completely understood why this setting exists at all, given 
that it only has one correct value (1.0), but that's another topic.)

See also <http://news.povray.org/439af61d%241%40news.povray.org> and the 
whole thread it's in.

  -Christian

Post a reply to this message

Christian Walther escribió:
> (I've never completely understood why this setting exists at all, given 
> that it only has one correct value (1.0), but that's another topic.)
> 

There were changes to gamma handling in 3.7, among which (IIRC) that 
setting was removed.

Post a reply to this message