Sven Geier <.sven.at.sgeier.dot.net.nospamplease> wrote:
> >  1) A simple and clear explanation behind the reasoning and motivation behind
> > the new gamma correction approach, why it makes sense and why it's better
> > than what POV-Ray 3.6 did.

> That's good information to have but it should definitely not be number 1) on the
> list. I would put this into some appendix somewhere ("If you were
> wondering ... see section ...").

  Except that its purpose it to explain why the feature has changed in
POV-Ray 3.7 compared to 3.6.

> >  2) Why "Display_Gamma" and "File_Gamma" should always have the correct
> >values for the user's system (ie. usually 2.2, or in some Macs 1.8) and
> >why they shouldn't be abused for visual effects (because that's not their
> >purpose).

> I still don't understand this, to be honest. If PCs "usually" have a gamma
> of 2.2, why do I still have to tell the PC version of POVray these things? Why
> can the *default* behaviour on a PC not be the one that the majority of
> users will expect?

  Because not everyone's system has a gamma correction of 2.2?

> Why do I have to futz around with ini files (and make the same change every
> single time a new beta comes out because the old ini files get replaced with
> the new ones every time) just to get the behaviour that one would expect for
> a run-of-the-mill PC?

  How is that related to this thread?

> >  5) How to pre-gamma-correct input images [...]

> Kinda specialized.

  You won't find it "kinda specialized" if you try to use image maps with
POV-Ray 3.7.

> >  6) If the user needs to do it, how to create an image which has no gamma
> > correction at all, only non-corrected raw pixels. The example of rendering
> > an image to be used for creating a heightfield could be mentioned.

> Quite frankly I'd put this very high on the list. If I cannot get POVray to
> do what I want, I want it to do nothing. Just keep your hands off gamma and
> similar things. If I want gamma correction, I'll do it myself in a paint program
> after the fact.

  You are thinking of gamma correction in the wrong end of the process.
Gamma correction is not an image post-processing filter like brightness,
contrast or gaussian blurring. (Yes, some people abuse post-processing
gamma correction to adjust brightness and contrast, but that's not what
gamma correction is for.)

  Gamma correction is about how your *input* values are mapped to the
output values. In other words, when in the *input* you say "I want 50%
gray", gamma correction tells the program what it should write to the
output image in order to get 50% gray.

  Gamma correction is also about telling in the image data that "this
should be interpreted as 50% gray" so that if you view the image in a
different system with a different display hardware with different gamma,
that color will look like 50% gray there as well, and not eg. 40% or 60%
gray.

  Skipping gamma correction altogether has its own uses, but those are
seldom related to regular images. (One example is when using an image file
as a storage format for heightfield data.)

> That's a lot easier for me than reading up online for every minor revision how
> gamma is supposed to work this week and doing render after render to get to
> something that actually looks the way I wanted it (because this week the preview
> doesn't actually show what I get in my file).

  If you specify "50% gray" in your scene file, and the end result is not
50% gray on your screen, is that how you wanted it to work? Because that's
how POV-Ray 3.6 works.

  Basically in POV-Ray 3.6 if you want a 50% gray color, you just can't
use "rgb 0.5". You have to manually find some value which will look like
what you want.  POV-Ray 3.7 wants to change that: It wants that "rgb 0.5"
means "50% gray".

> I can think of a hundred possible scenarios where an image gets rendered on a
> different computer than where it is viewed and what not, but I'd be willing
> to bet dollars to donuts that the vast majority of POVray users render and view
> on the same machine and have no real need for for anything beyond "I want this
> to look as it does in the preview".

  As I said, it's not only a question of whether the image will look the same
in another computer, but also about more consistent interpretation of colors
in the scene file. "rgb 0.5" should mean "50% gray", not something else,
because that's the most logical interpretation.

  In order to achieve that goal, gamma correction is needed.

  Currently in POV-Ray 3.6 the only way to get exactly what you want is to
try manually rgb values until you end up with something that looks like what
you want.

> Notably absent from your list is what I would put on the list as number one.

> You need to acknowledge that most users will read documentation NOT preemptively
> to understand the subtleties of the programming, but because they're trying to
> do something and it doesn't work. Number 1 on the list would be

> 1) My image looks (over- / under-) exposed. What should I do to make
> it (darker/brighter)?

  Gamma correction is precisely the wrong tool for that problem. Gamma
correction is *not* a post-processing filter to adjust brightness and
contrast. It has been extensively abused for that purpose, but it's not
what it exists for, and never has been.

  Gamma correction is used to map linear rgb values to colors which will
look on your screen equivalently linear (because your screen does *not*
show pixel values with a linear brightness). Gamma correction is not a
brightness/contrast knob for your rendered image.

-- 
                                                          - Warp

Post a reply to this message