Am 05.05.2010 14:47, schrieb JJ:
> clipka<ano### [at] anonymousorg>  wrote:
>
>> Are you sure these are the same settings that you used with beta.36?
>>
>> To be frank, I can't imagine you used PNG output when working with
>> beta.36 - because with PNG files, it doesn't matter what encoding gamma
>> (derived from File_Gamma) is used: They will only seem to match the
>> render preview if you set the proper Display_Gamma for your system
>> (provided the image viewer does a proper job).
>>
>>
>> Anyway, a beta.37a is just about to be released that will restore
>> beta.36 gamma behavior.
>
> Hello Clipka and Alain,
> If two povman have the same problem, may be they are a problem somewhere in the
> beta 37?

Believe me, one of the primary principles I go by when assessing alleged 
software errors is that the software /is/ guilty unless evidence 
/strongly/ indicates otherwise. So typically I'd try to reproduce the 
error scenario as faithfully as possible, and see if the error does 
occur or not. If it doesn't, next assumption is that I /misunderstood/ 
the error scenario, so I start toying around within different 
interpretations of the description. If that still doesn't produce the 
reported error, I go by the assumption that the error scenario was not 
/described/ properly, so I toy around even more. Only if I run out of 
ideas what might have gone wrong with the /communication/ about the 
error (and believe me, I'm quite creative at that) - or if during the 
process I find a scenario which plausibly fits the error description but 
is definitely not a bug - do I find the software not guilty.

I did some tests here, and I did find that in the scenario you 
described, beta.36 /does/ give the very same results as you report for 
beta.37.


Also note that as of now, you are the /only/ person reporting this very 
error; Quietman's problem was obviously of different nature, as the 
proposed workaround did work for him.


So I do repeat: I cannot find anything like what you report in beta.37 
(aside from the File_Gamma=1.0 issue seen by Quietman) that hadn't been 
there in beta.36 as well.

I'm not saying you can't possibly see what you claim to be seeing - but 
I do suspect that the File_Gamma=1.0 bug in beta.37 found by Quietman 
motivated you to have a much closer look at Gamma than ever in beta.36, 
and now you're surprised about 3.7 behavior that has been there for 
quite a while already, and you just never encountered it before. To me, 
the most plausible assumption is that you never tested with PNG output 
file format in beta.36 and earlier.

>   With file gamma AND (so both) Display gamma values 0.98, 1.0, 2.0 and 2.2,  the
> picture in the povray window and the picture in the file is not the same for
> povray 3.7 beta 37 but it was OK with the previous version.

That's not what I see here:

- I /do/ see outright /broken/ behavior in beta.37 with File_Gamma=1.0. 
but not for 0.98 or 2.0 or 2.2.

- I also /do/ see gamma discrepancies between preview window and written 
file for some other combinations of File_Gamma, assumed_gamma and output 
file type, but I do see those very same effects with beta.36 as well.

So my conclusion is that yes, beta.37 does behave as you report, but 
your memory of beta.36 behavior is not as accurate as you believe.

> - So how to obtain the same gamma settings in the povray render windows and file
> and which file format you recommand for povray 3.7 beta 37 windows XP, Vista and
> 7.

I strongly recommend to:

(0) Do /not/ use assumed_gamma anymore.

(1) Set Display_Gamma to a value that does really fit your display 
subsystem - so that you see in the preview window what POV-Ray expects 
you to see.

(2) If your display subsystem gamma is significantly different from 2.2, 
make sure that your image viewing program is aware of this fact - so 
that you see in your image viewing software what that software expects 
you to see (and what POV-Ray expects you to see there).

(3) Use File_Gamma=2.2 unless you want to generate height field data 
(unless you are perfectly sure you will never want to view the images on 
any other computer or share them via internet) - so that any person 
(including you possibly) viewing the output images on any other computer 
or with any other image viewing software have the best chance of seeing 
what POV-Ray expects them to see in those images.

(4) Depending on what you intend to do with the image, use either 
OpenEXR (because it's simply the best) or PNG (because it's one of the 
two most common, and does increases the chance of being displayed 
properly on other computers) as output format, or JPEG if you don't 
intend to post-process it (because it's the other of the two most common).

(5) Design your scenes to look good with these settings right from the 
start.

For /legacy/ scenes, make sure to use the "#version 3.6;" statement (or 
whatever applies), /do/ use the "assumed_gamma" statement, and do /not/ 
use the "File_Gamma" setting. Also, do /not/ use PNG output, but rather 
BMP or some such.


> - If it is possible to find the previous version somewhere?

The POV-Ray dev team has no interest whatsoever in older betas being 
circulated freely. You may want to test the brand-new beta.37a though, 
which fixes the issue reported by Quietman; I also gave it some thorough 
testing to verify that behavior is really identical to beta.36 again 
regarding output gamma. (See http://www.povray.org/beta/)

Post a reply to this message