As I work to understand the existing version handling with the idea of 
the ini / flag mechanism defaulting up front in the yuqk fork to v3.8, 
I've run across inconsistencies in how the version / gamma defaulting is 
being done in v3.8 beta 2.

The short of it is if you specify an initial version and assumed_gamma 
value things are OK I think - this the c.pov file.

With yuqk, I'm less concerned with pre-v3.8 compatibility - so I 
probably won't chase all of inconsistencies highlighted below.

Roughly, the code is is taking the ini / flag setting as most important 
setting of version with respect to non-specified gamma - until it 
doesn't. Further, the initial #version in the scene file doesn't seem to 
mean that much with respect to non-specified gamma handling - until it does.

Bill P.

================================================


Create the following four files:

// a.pov file
#version 3.7;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// b.pov file
// #version 3.7;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// c.pov file
#version 3.7;
global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

// d.pov file
#version 3.5;
// global_settings { assumed_gamma 1.0 }
//...
#version 3.7;
sphere { 0, 1 }
---


Running v3.8 beta 2 with the commands:

povray a.pov   (??? The leading version setting is 3.7)
------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.

povray b.pov
------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.

povray c.pov
------------
<No warnings>

povray d.pov   (??? We only ended at version 3.7...)
------------
Possible Parse Error: assumed_gamma not specified in this POV-Ray
v3.7 or later scene. Future versions of POV-Ray may consider this
a fatal error. To avoid this warning, explicitly specify
'assumed_gamma 1.0' in the global_settings section. See the
documentation for more details.


povray a.pov +mv.3.7
--------------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.
(And then after bounding completes, the following happens...)
-----------------------------------------------------------------
Warning: A version of 3.7 or greater was specified in an INI file
or on the command-line, but the scene finished parsing with a
#version of 3.6x or earlier and without assumed_gamma set. Output
gamma correction is being turned on as per the v3.7 default using
an assumed_gamma default of 1.0, rather than left off (which was
the v3.6.x and earlier default), because the INI file or
command-line specified version directive takes precedence.
-----------------------------------------------------------------


povray b.pov +mv.3.7
--------------------
Parse Warning: assumed_gamma not specified, so gamma_correction
is turned off for compatibility with this pre POV-Ray v3.7 scene.
See the documentation for more details.
(And then after bounding completes, the following happens...)
-----------------------------------------------------------------
Warning: A version of 3.7 or greater was specified in an INI file
or on the command-line, but the scene finished parsing with a
#version of 3.6x or earlier and without assumed_gamma set. Output
gamma correction is being turned on as per the v3.7 default using
an assumed_gamma default of 1.0, rather than left off (which was
the v3.6.x and earlier default), because the INI file or
command-line specified version directive takes precedence.
-----------------------------------------------------------------


povray c.pov +mv.3.7
--------------------
<No warnings>


povray d.pov +mv3.7  (Should do the override too, but it doesn't)
-------------------
Possible Parse Error: assumed_gamma not specified in this POV-Ray
v3.7 or later scene. Future versions of POV-Ray may consider this
a fatal error. To avoid this warning, explicitly specify
'assumed_gamma 1.0' in the global_settings section. See the
documentation for more details.

Post a reply to this message

On 2024-02-03 18:16 (-4), William F Pokorny wrote:
> As I work to understand the existing version handling with the idea of
> the ini / flag mechanism defaulting up front in the yuqk fork to v3.8,
> I've run across inconsistencies in how the version / gamma defaulting is
> being done in v3.8 beta 2.
> 
> The short of it is if you specify an initial version and assumed_gamma
> value things are OK I think - this the c.pov file.

I suppose the lesson for non-developers is to *always* set
assumed_gamma, so that the parser, whichever version it is or is trying
to be, doesn't have to guess.

Post a reply to this message

On 2/3/24 17:41, Cousin Ricky wrote:
> I suppose the lesson for non-developers is to*always*  set
> assumed_gamma, so that the parser, whichever version it is or is trying
> to be, doesn't have to guess.

Yes, I think that a good rule.


---
For yuqk / v4.0 still thinking about what to do with

#version <float> / version / version=<float> / +mv<float>

global_settings { assumed_gamma <...> } / internally defaulted gammas

and

defaults{} / (internal default switching)

Honestly, the more I look at the code the more muddled it all is. I 
think some of the 'fog' comes from really needing two forms of 'version' 
both internal to the source code and in POV-Ray as seen by users.

The first a 'version_gamma' and a second 'version_parsing'. Both would 
be set to a most current version default as part of the ini / flag 
mechanisms - otherwise there are things which break. The 
'version_gammaIssues' would not be chang-able after the ini / flag 
stage. The 'version_parsing' could be used with the scene's SDL to 
switch parsing behavior and the 'internal default' differences between 
major release versions.

It would also be good to get away from having both a #version directive 
and a version keyword in the Scene Description Language. It's ugly by 
set up and in code.

--- on 'assumed_gamma'  (change name to working_gamma ?)
This setting too really needs to always be set initially in the ini / 
flag stage for all other features to work properly. Probably defaulted 
by the ini / flag version options unless otherwise set explicitly there. 
Done this way suppose the global_settings { assumed_gamma ... } could 
become a check on the ini / flag gamma results in what is required by 
the scene.

Yep, I'm thinking aloud... I still don't completely understand how all 
the setting and defaulting is happening.

Bill P.

Post a reply to this message

Although you mentioned running 3.8 beta 2, I decided to test your examples plus
your command-line  +mv3.7 additions in 3.8 beta 1 (Windows)-- just to see if the
behavior and returned parse warnings are the same. They all are-- except for the
'extra' warnings you mentioned "after bounding completes, the following
happens..." Those do not appear. I guess that's a slight change between beta 1
and beta 2.

[BTW: I noticed that your command-line switch for #version has an extra period
or decimal point--  +mv.3.7  -- whereas the documentation says  +mv3.7. But
either one seems to work OK, which surprised me.]

Actually, the ini/command-line switches for a scene's #version (and/or
assumed_gamma) is something that I have never used; instead, I always explicitly
state those in my scenes. But from what you mentioned here and in another recent
thread, I get the feeling that the switches are the 'proper' way to do it-- to
override(?) what might already be in a scene, and to avoid any possible (or
difficult-to-track-down) problems that might crop up. Are my assumptions
correct?

If so, I am curious about your c.pov example:

// c.pov file
#version 3.7;
global_settings { assumed_gamma 1.0 }
//...
#version 3.5;
sphere { 0, 1 }

Does adding a command-line switch like +mv3.8 override BOTH of the explicit
#version settings there? I have to admit that I am rather naive about all of
this #version business and the various possible interactions.

Post a reply to this message

On 2/4/24 16:17, Kenneth wrote:
> Although you mentioned running 3.8 beta 2, I decided to test your examples plus
> your command-line  +mv3.7 additions in 3.8 beta 1 (Windows)-- just to see if the
> behavior and returned parse warnings are the same. They all are-- except for the
> 'extra' warnings you mentioned "after bounding completes, the following
> happens..." Those do not appear. I guess that's a slight change between beta 1
> and beta 2.

Hmm. The yuqk fork 'branched off' in early 2019. The v3.8 beta 2 code 
and yuqk both have this code in the common to all executable(s) in the 
source/frontend/renderfrontend.h file. So, I'd bet against a code change 
being the reason you don't see the additional warning, but?

When running in a unix / linux terminal all the output comes back to the 
terminal where it's perhaps separated in the windows interface? <-- My 
only guess is the output is going somewhere unexpected or going 'poof' 
on windows.

> 
> [BTW: I noticed that your command-line switch for #version has an extra period
> or decimal point--  +mv.3.7  -- whereas the documentation says  +mv3.7. But
> either one seems to work OK, which surprised me.]

That's me making a typo. I checked my command history and the extra '.' 
isn't there in what I ran.

Aside: Using +mv.3.7 doesn't come back with an error (neither does 
version=.3.7). It, rather, sets the version to 1.0. Probably because a 
simple atof() is being used and the value comes in at 0.3 or similar.
Looks like the upper range isn't protected either.

I tried version=999 and surprisingly things run quickly:

"AI active. Quantum computing virtual machine version 77.3.5.1.
...
All scenes you've ever written or imagined have been rendered with every 
possible advanced option on. Output images and animations have been 
saved to your google cloud drive. Please login into your google account 
for a chat with AI_LittleIcePick12. Storage charges have exceeded 
existing credit limits and an immediate payment is due."

More seriously, I'll look at at least clamping the version range to 
something more reasonable in yuqk. Maybe extend the trial c+11 regexp 
flag checker to do more - but I've not played with that code now in years...

> 
> Actually, the ini/command-line switches for a scene's #version (and/or
> assumed_gamma) is something that I have never used; instead, I always explicitly
> state those in my scenes. But from what you mentioned here and in another recent
> thread, I get the feeling that the switches are the 'proper' way to do it-- to
> override(?) what might already be in a scene, and to avoid any possible (or
> difficult-to-track-down) problems that might crop up. Are my assumptions
> correct?
> 

If things were only black and white...

It's the direction in which I'm trying to push yuqk. For v3.8 beta 2, 
probably, it's safer to specify as a command line flag or ini option 
with the same version specified as the first line #version of your scene 
file than not. I've yet to see any evidence doing it hurts and it 
sometimes helps.

Another place the +mv sort of version spec is necessary is with the 
unspecified default camera. Meaning with the following sort of set up:

//---
#version 3.7;
global_settings { assumed_gamma 1.0 }
plane { -z, -1 pigment {rgb <1,1,0>} }
//...
#version 3.5;
sphere { <0,0,1.0> , 0.1
     pigment { rgb <0,0,1> }
     finish { emission 1 } // Yes, this generates a warning.
}
// camera {} // Specified default camera grabs current version defaults
//---        // and its use is what is seen in the right three columns

Without writing a small chapter, the second and third columns of the 
attached test image show that the ini / flag version setting is used 
when there is a leading #version statement in the scene code - over the 
version specified in that #version statement (or defaulted version).

> If so, I am curious about your c.pov example:
> 
> // c.pov file
> #version 3.7;
> global_settings { assumed_gamma 1.0 }
> //...
> #version 3.5;
> sphere { 0, 1 }
> 
> Does adding a command-line switch like +mv3.8 override BOTH of the explicit
> #version settings there? 

Certainly not for most things, but for some smaller set things / 
situations, yes.

> I have to admit that I am rather naive about all of
> this #version business and the various possible interactions.
> 

Me too! :-)

Bill P.

Post a reply to this message

Attachments:
Download 'storyverflag.jpg' (36 KB)

Preview of image 'storyverflag.jpg'

On 2/5/24 02:26, William F Pokorny wrote:
> It's the direction in which I'm trying to push yuqk.

For a status update related to the yuqk fork see:

http://news.povray.org/povray.pov4.discussion.general/thread/%3C65b7935a%241%40news.povray.org%3E/

Bill P.

Post a reply to this message