Here's the relevant portions of the notes:

>   The way POV-Ray 3.7 handles the 'assumed_gamma' keyword has changed.
>   Previously the presence of this keyword in global_settings caused a
>   'possible error' warning and its presence was ignored. In addition
>   no gamma correction was available in previous betas. Starting with
>   beta.10 however, gamma correction is performed on both the display and
>   file output, subject to the following criteria:
> 
>     o If the scene language version is set to 3.7 (or not set at all), then
>       gamma correction will default to ON, with the value used being set by
>       the 'display_gamma' INI file setting. Note that in previous versions of
>       POV-Ray gamma correction was OFF by default but otherwise this is the
>       same.
> 
>     o If the scene language version is set to earlier than 3.7, then gamma
>       will be OFF by default.
> 
>     o Notwithstanding the above, if the keyword 'assumed_gamma' is present
>       in the scene's global_settings, then POV will take one of the following
>       actions:
> 
>         a) if "assumed_gamma 2.2" is present, gamma correction will be turned
>            OFF and a warning issued. the same thing will happen if the value
>            specified is not 2.2 but happens to be the default for the platform
>            setting given to POV-Ray when it was compiled (e.g. Windows is 2.2).
> 
>         b) if "assumed_gamma 1.0" is present, gamma correction will be turned
>            ON (if it's not already on) and in any case a warning will be issued.
> 
>         c) if a value other than the above is specified, it is ignored and a
>            'possible error' message is issued.
> 
>       You will note from the above that therefore it is no longer possible to
>       adjust the amount of gamma correction from a scene file. This is as
>       designed since scene files should be as much as possible be platform
>       independent, and the gamma of particular display hardware does not belong
>       in the scene file. If you really need to specify 'assumed_gamma' you can
>       do so in an INI file or on the command-line; however in those cases you
>       may as well just use 'display_gamma' in its place.
> 
>       When writing file formats that support gamma specification, the inverse
>       of the assumed_gamma value will be embedded in the file headers, so that
>       an appropriately equipped display program can 'undo' the gamma correction
>       if it is so desired. This is as per previous versions of POV-Ray.
> 
>   Frontend and Backend
>   --------------------
>       
>   Note that POV-Ray uses a logical separation of frontend and backend. The
>   'frontend' is that part which deals with the user-interface, locating files,
>   parsing command-line options, reading INI files, and so forth. The 'backend'
>   deals with parsing the scene file and doing the actual render. These two parts
>   of POV-Ray communicate via a message-passing interface, even when linked into
>   the one executable program.
>   
>   Whilst currently not supported, it is entirely possible to separate the front
>   and back ends via for example a network interface, and have the render done
>   on one machine while the user interface (and display) is on another. Knowing
>   this may make it easier to understand why, for example, we are moving away
>   from allowing things such as gamma correction to be specified in the scene
>   file; there is no reason to assume the scene file is on the same machine as
>   the image will be displayed upon, and as such the specification of gamma
>   should be done in the frontend via INI or command-line options.
> 
>   There will be more changes along these lines as we prepare for the future
>   transition to a fully network-capable renderer. The POV-Team will attempt
>   to ease the change to the new system by doing things such as the assumed_gamma
>   interpretation above, where it is possible to do so.

-----------

>   gamma changes, revert to beta.10 behaviour with some tweaks for more 
>   extensive version checking.
>   
>   In particular, specifying -MV3.7 or later via an INI file or the 
>   command-line is taken at higher precedence than a #version 3.6 (or 
>   lower) in the scene file when it comes to assigning the default state of 
>   gamma correction (on/off, not its actual value if on). the value used 
>   when it is on is determined by either Display_Gamma (if given) or 
>   DEFAULT_DISPLAY_GAMMA otherwise. Similar steps are taken for the new 
>   File_Gamma option.
>   
>   The actual value of assumed_gamma is not passed on; this prevents its 
>   use for anything other than turning gamma on or off (which is what the 
>   majority of scenes did with it). Those scenes that (mis)used 
>   assumed_gamma to adjust the scene appearance outside of the needs of the 
>   user's actual display gamma will need to either be altered to suit, or 
>   to be run with an adjusted Display_Gamma and File_Gamma.
>   
>   NB users are warned that assumed_gamma support will be removed entirely 
>   in a later 3.7 revision.

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:4891a171@news.povray.org...
> Jim Holsenback wrote:
>> It seems the biggest issue is going to be the assumed_gamma handling 
>> change
>> in v3.7. If I'm understanding correctly if the parser sees the inclusion 
>> of
>> that keyword it basically spits out a warning and handles gamma 
>> correction
>> based on what you have in resolution.ini. Is that correct? So there's no 
>> way
>
> It's a little more complicated than that: best to read the release notes
> regarding that (I'll paste the relevant section in a followup to this 
> message).

thanks .... I'm squared away on that now.

>> I've reread through this thread and it still seems that there is no
>> consensus on image file format and size. Whats the best approach here?
>> Produce a full sized image and just scale for the thumbnails, or two
>> separate runs.
>
> Scaling to thumbnails is fairly easy, so I'd recommend that. For full-size
> images you could render at a width of, say, 768, with the height being
> whatever that scales to with the aspect ratio taken into account.

ok that answers size .... what about format? png?

> One other suggestion: when leaving a #version in the scene file, it might
> be good to add a comment above it that says e.g. "minimum POV-Ray version
> needed to render this scene", or something like that.
>
> thanks,
> -- Chris

I've seen what I think perhaps catches all the cases we are likley to 
encounter that involve gamma correction and they are:
version <= 3.5 with  assumed_gamma = 2.2, 1.8, 1, or 0.8 in 244 of the 365 
scene files, or no version set at all for the rest.
It seems then that the 244 files with some mention of gamma correction have 
the version reference removed, so that by default gamma correction is on. 
the test file I was using sourced a couple of includes that had #version 3.5 
keyword. Does the pov source file inherent the version from a sourced 
include? If so I would be in favor of setting #version = 3.7 in those pov 
files. Maybe we need to up version the includes as well. The remaining files 
that have no mention of assumed_gamma should be set to 3.5 so to have gamma 
correction off.

here's the header of the test file i've been using and a pretty free form of 
what I'm thinking we ought to be doing:

// Persistence Of Vision raytracer version "what ever we decide" sample 
file.
//
// -w320 -h240
// -w800 -h600 +a0.3

#include "stdinc.inc"
#include "arrays.inc"

/* The following has been obsoleted due to the way gamma correction is now 
being handled.
Please refer to the release notes for additional information. Any version 
references should
be considered as a minimum requirement to render this scene. */

//#version 3.5;

global_settings {
 //assumed_gamma 1
}

Cheers
Jim

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.488b08c815676239270b39b0@news.povray.org...
> "Jim Holsenback" <jho### [at] hotmailcom> wrote:
> ....
>>if there are
>> no objections i'll use the manifest list to evenly divide up those scenes
>> into managable chunks...
> Good idea. Use more chunks than people so new people can easly join, or 
> another
> chunk can be taken if one is easy(or time permits).

i think we are getting close to starting to work, however there are some 
pending issues to be nailed down yet.
here's a proposed breakdown:

advanced/animations (71)
camera/incdemo (74)
interior/language/lights/objectmods/qtvr/radiosity (69)
objects/portfolio (78)
textures (73)

Jim

Post a reply to this message

Jim Holsenback wrote:
> ok that answers size .... what about format? png?

Yes, I think so: it's lossless and easy to convert from that to another
format if it's needed.

> the version reference removed, so that by default gamma correction is on

> Does the pov source file inherent the version from a sourced 
> include? 

I think you'll find that the includes set it back to the old value at the
end (please check to make sure).

> Maybe we need to up version the includes as well.

There's probably no harm in doing so, and might even be a good idea overall.

> /* The following has been obsoleted due to the way gamma correction is now 
> being handled.
> Please refer to the release notes for additional information. Any version 
> references should
> be considered as a minimum requirement to render this scene. */
> 
> //#version 3.5;
> 
> global_settings {
>  //assumed_gamma 1
> }

In the above example I'd rather have the assumed_gamma removed, along with
the #version; thus the comment isn't necessary.

OTOH if there is no #version at all, and the scene doesn't render "right"
(i.e. gamma turns out wrong) when rendered in version 3.6 due to the
removal of the assumed_gamma, then we probably ought to place a #version
3.7 in the scene.

if you wanted to get fancy, you could leave the #version out and put a #if
around the assumed_gamma statement, where you check the version and only
apply the assumed_gamma for version 3.6 and earlier.

regards,

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> Jim Holsenback wrote:
....
> > /* The following has been obsoleted due to the way gamma correction is now
> > being handled.
> > Please refer to the release notes for additional information. Any version
> > references should
> > be considered as a minimum requirement to render this scene. */
> >
> > //#version 3.5;
> >
> > global_settings {
> >  //assumed_gamma 1
> > }
>
> In the above example I'd rather have the assumed_gamma removed, along with
> the #version; thus the comment isn't necessary.
....
If we go this route, then I would also use:
// Persistence Of Vision raytracer sample file.
in the top comments, with no mention of version.

Stephen S

Post a reply to this message

"StephenS" <nomail@nomail> wrote in message 
news:web.48948ff5156762395d26830d0@news.povray.org...
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> Jim Holsenback wrote:
> ....
>> > /* The following has been obsoleted due to the way gamma correction is 
>> > now
>> > being handled.
>> > Please refer to the release notes for additional information. Any 
>> > version
>> > references should
>> > be considered as a minimum requirement to render this scene. */
>> >
>> > //#version 3.5;
>> >
>> > global_settings {
>> >  //assumed_gamma 1
>> > }
>>
>> In the above example I'd rather have the assumed_gamma removed, along 
>> with
>> the #version; thus the comment isn't necessary.
> ....
> If we go this route, then I would also use:
> // Persistence Of Vision raytracer sample file.
> in the top comments, with no mention of version.
>
> Stephen S

good eye .... i noticed this but forgot to mention. In other words agreed!!

Jim

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48948066@news.povray.org...
>> Does the pov source file inherent the version from a sourced
>> include?
>
> I think you'll find that the includes set it back to the old value at the
> end (please check to make sure).

ok ... i'll look to make sure.

>> Maybe we need to up version the includes as well.
>
> There's probably no harm in doing so, and might even be a good idea 
> overall.

good ... i'll have a look and see what's involved before I pull the trigger 
and do it.

>> /* The following has been obsoleted due to the way gamma correction is 
>> now
>> being handled.
>> Please refer to the release notes for additional information. Any version
>> references should
>> be considered as a minimum requirement to render this scene. */
>>
>> //#version 3.5;
>>
>> global_settings {
>>  //assumed_gamma 1
>> }
>
> In the above example I'd rather have the assumed_gamma removed, along with
> the #version; thus the comment isn't necessary.

i threw that in just to see if i could get any outside ideas .....

> OTOH if there is no #version at all, and the scene doesn't render "right"
> (i.e. gamma turns out wrong) when rendered in version 3.6 due to the
> removal of the assumed_gamma, then we probably ought to place a #version
> 3.7 in the scene.

another overlooked possibility ..... thanks!

> if you wanted to get fancy, you could leave the #version out and put a #if
> around the assumed_gamma statement, where you check the version and only
> apply the assumed_gamma for version 3.6 and earlier.

this is way more elegant and easy enough to do.

Cheers

Post a reply to this message

"Chris Cason" <del### [at] deletethistoopovrayorg> wrote in 
message news:48948066@news.povray.org...
> Jim Holsenback wrote:
>> Does the pov source file inherent the version from a sourced
>> include?
>
> I think you'll find that the includes set it back to the old value at the
> end (please check to make sure).

yes they do that ..... all but two of them

>
>> Maybe we need to up version the includes as well.
>
> There's probably no harm in doing so, and might even be a good idea 
> overall.

with the code frag in the includes this could be considered a moot point. In 
the name of housekeeping this may not be a bad idea to do this anyway. there 
are only 35 include files .... 33 are branded version 3.5 and have the 
switching mechinism, two files (stdcam.inc and stage1.inc) have 3.1 mention 
in header comments and no switching code. easy enough to version them as 3.7 
and housekeeping seems like a good reason to proceed, but won't do that 
unless you (Chris) think I should do this.

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote:
....
> i think we are getting close to starting to work, however there are some
> pending issues to be nailed down yet.
> here's a proposed breakdown:
>
> advanced/animations (71)
> camera/incdemo (74)
> interior/language/lights/objectmods/qtvr/radiosity (69)
> objects/portfolio (78)
> textures (73)
>
> Jim

If there are no objections I'll start to familiarise myself with the
'camera/incdemo' group.
When we seem to have agreed upon the requested changes, I'll start a new thread
for this group of files, so I can list my progress or problems.

Stephen S

Post a reply to this message

while having a look at the include files i think i may have come up with one 
more housekeeping issue that may be worthy of consideration.

the issue of the I_Glass warning .....

there are 14 scenes that call glass.inc (which calls glass_old.inc). my 
cleanup proposal involves making the textures in glass_old materials which 
would have the required inclusion of interior {I_Glass} and removing the 
I_Glass warning message in glass.inc .... oh and making a comment in 
glass_old header to call materials instead of textures.

I found at least one scene that calls the texture {T_Glass1} which is a 
glass_old texture, so it would appear there would be some changes to scene 
files as well.

comments welcome!

Jim

Post a reply to this message