Sven Geier schrieb:

>>  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?

The default values /do/ match the standard of 2.2. The problem is that 
there are some other things that don't work as a user may expect, unless 
he knows a bit about the background.

> 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?

Well, what exactly /is/ the behaviour you'd expect? And why would it 
require futzing around with ini files?

My guess would be that you're doing something wrong elsewhere.


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

Note that this would require you to virtually /always/ post-process the 
image. I don't think that is what the majority of POV-Ray users would want.

Therefore, /by default/, POV-Ray /does/ perform gamma encoding (which 
for various file formats is equivalent to gamma pre-correction). But you 
can easily disable this by setting File_Gamma=1.0.

Note however that this does not make any difference at all for file 
formats that provide meta-information about encoding gamma.


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

You know that you're exaggerating here. The betas are not released 
/that/ frequently - and gamma handling hasn't changed for a year or so.

Also keep in mind that we're talking about beta releases: They are 
positively /not/ intended for people who just want to run POV-Ray "out 
of the box" and bother about nothin'. It is instead a development 
version, released to the public for everyone willing to be a guinea pig.

This shouldn't keep you from pointing out what irritates you about it, 
and what you'd expect to be different - to the contrary, that's 
absolutely desired - but please keep it fair, bearing in mind that it 
should be /expected/ to still be in a state as to irritate you here and 
there - and also to still be subject to change.


> 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)?

Yes, the Questions & Tips section in POV-Ray's online help could be 
improved I guess.

This one is not a particularly gamma-related problem though, as there 
may be plenty of other reasons leading to similar effects; too high 
ambient is probably the most common cause.

Post a reply to this message