 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Holsenback" <jho### [at] hotmail com> wrote:
....
> I'm sure there are one or two more issues that I've not hit upon.
> Stephen/Sabrina .... you guys have been mostly silent. What kind of initial
> issues have you seen? I really think it's important to get as many of the
> issues as we can out in the open before formulating a test plan. If I'm off
> base on this please speak up. I'm flexible and have no problem being pointed
> in the right direction.
My current understanding is:
~Stage one: Identify included content that no longer produces the same result in
3.7 as the version it was made for. Update files to reflect; removal of #version
if possible, and removal of version 3.5/3.6 in comments.
~Stage two: Update/remove/new content and the way it's presented to the end
user.
Stage one is the level I signed up for, Stage two is interesting but only as an
observer.
If you could group the files into managable chunks, I'll start reporting back my
findings;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"StephenS" <nomail@nomail> wrote in message
news:web.4890749415676239b586e7830@news.povray.org...
> My current understanding is:
> ~Stage one: Identify included content that no longer produces the same
> result in
> 3.7 as the version it was made for. Update files to reflect; removal of
> #version
> if possible, and removal of version 3.5/3.6 in comments.
> ~Stage two: Update/remove/new content and the way it's presented to the
> end
> user.
> Stage one is the level I signed up for, Stage two is interesting but only
> as an
> observer.
> If you could group the files into managable chunks, I'll start reporting
> back my
> findings;)
Last evening I reviewed about two dozen files from various locations.
Without fail assumed_gamma was the prevailing issue. Several files had
version 3.1 brands. There was one or two files that had noticeable blocks of
code commented out. I also noticed that some but not all source files had
ini files. I think this a great feature that we might use in the process of
producing the final quality images for the distribution. Stephens comments
and one other limiting factor for me (dial-up) leads me to believe that
there may be a better way to approach this project. The whole thing depends
on Chris having a machine that has enough free cycles to crank out the final
product, so I will be brief.
Divide the source files into four chunks. Three for the review team, one
left over for whoever gets done first. While that's going on there needs to
be a decision made about final image quality, size, and format. Every source
final gets an ini file with the agreed upon render options. See if we might
be able to leverage off what Christoph did with the MegaPov examples. The
testing on our end will just involve branding a version if necessary, making
sure any parser warnings are resolved, and seeing that the image does indeed
render. No worries about quality and size as the images will just be
discarded. Upload the cleaned up source and ini files, and batch them up for
processing.
Cheers
Jim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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).
> Another thing I looked at was some of the animation examples. Some examples
> had ini files and started clocking through and produced a series of images.
> Do we want to run through the entire animation, and produce a mov. I have QT
I don't think this is necessary, just a single still would do.
> 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.
> What kind of timeframe are we working against here ..... by the end of the
> beta cycle and before v3.7 final release?
No specific time other than that obviously we have to get it done before we
release :). It would be nice to have the updated scenes in the betas sooner
than later.
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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
