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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christian Walther wrote:
> (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.)
> 
	AFAIR, old versions of POV used to do the wrong thing (i.e. not
handle gamma at all). The assumed_gamma setting was added in order
not to break old scenes when POV became gamma-aware (from the docs:
"Scenes that do not have an assumed_gamma global setting will not
have any gamma correction performed on them, for compatibility
reasons.").

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFHUy+td0kWM4JG3k8RAiGUAJ9+xagjQhftLc6mtSlMDiHkkYIuwgCgmRun
mMp1gUFKYNZj0w15m5urhmg=
=Aie+
-----END PGP SIGNATURE-----

Post a reply to this message

> > (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.)

It also says it defaults to 2.2. And it does. But that's not the point.
assumed_gamma should not be the same variable as internal gamma since it should
only affect how pov-ray enterpret colors in the script.

So in essense: the fix shouldn't work if Pov-Ray v3.6 did. Which means if it
worked then I could set assumed_gamma to 2.2 and be able to paste system_gamma
colors (samples from images f.ex.) into my script and get good quality at the
same time. Which is currently not possible (please don't post a link to the
relevant #include macro).

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

From what I can tell the setting is now only available in povray.ini in v3.7.
And hopefully it's not just still using system_gamma as default - meaning - it
doesn't just implement gamma relative to system_gamma like in graphics cards
and Linux software (small prair).

---

Someone was confused about what different terms means:

Gamma - implies: monitor gamma curve (relvative to gamma 1.0 linear).
Color profile - contains among other things the inverse gamma curve.
Gamma correction - a relative change that makes monitor = 2.2/1.8.

So "gamma handling" includes a convertion to software's internal linear.

Everything leading up to the monitor handles graphics that is stored in inverse
gamma so it turns out normal on the screen by just loading it directly.
Graphics files are never linear (ok, that varies with the odd platform).

A color profile also contains the following stuff (gamma excluded):

Gamut which is the RGB components "gamma" when blended as hues. Different tube,
different red green and blue hues and different transision curves between them.

Whitepoint is for wysiwyg; when I hold a paper next to the screen in wysiwyg it
should appear identical in color (which is not normal desktop use - whitepoint
is for specialists like graphics/printing pro's).

Blackpoint compensates f.ex. those lousy LCD screens where black is more like
graphite-blue, but rgb 1 still appears normal.

Worth noting is that even so-called "Professional" software like Photoshop which
is confusingly professional in it's price does not handle stuff 100% correct
(just try the 50% b/w pattern shrink in CIE/LAB/CMYK). That and the fact that
nearly very single default setting is the opposite to quality. One must
manually convert to gamma 1.0 (custom RGB) and then back again (16-bpp) to
force it to function in a near-professional way. And basicly anything costing
less than Photoshop doesn't even have that option (both >=16-bpp and ability to
convert to gamma 1.0).

Software that does operate correct is d-slr RAW image processors (note: RAW as
in the 16-bpp gamma 1.0 graphics format used in conjuction with cmos-CCD system
cameras). And ofcourse varius obscenely priced 48-bit apps (above and beyond
Photoshop's symbolic $2000).

Post a reply to this message

JetRacer wrote:
> Fact: I've used Pov-Ray almost daily for over 5 years

FWIW...around here, folks pretty much spell that "newby."

--Sherry Shaw

-- 
#macro T(E,N)sphere{x,.4rotate z*E*60translate y*N pigment{wrinkles scale
.3}finish{ambient 1}}#end#local I=0;#while(I<5)T(I,1)T(1-I,-1)#local I=I+
1;#end camera{location-5*z}plane{z,37 pigment{granite color_map{[.7rgb 0]
[1rgb 1]}}finish{ambient 2}}//                                   TenMoons

Post a reply to this message