POV-Ray : Newsgroups : povray.general : Pov-Ray internal gamma handling : Re: Pov-Ray internal gamma handling Server Time
31 Jul 2024 08:28:10 EDT (-0400)
  Re: Pov-Ray internal gamma handling  
From: JetRacer
Date: 3 Dec 2007 01:20:01
Message: <web.47539e4b4ecc714ef70f695c0@news.povray.org>
> > (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

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