|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
POV-Ray 3.7 gives this warning if you try to trace a scene without assumed_gamma
set:
> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.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.
My question is: Why will this become a fatal error, instead of just defaulting
to 1.0? It seems like most people would *want* there to be some sensible
default, instead of breaking and having to add additional keywords to their
scenes. I know I would, anyway.
-Greg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 03/11/2019 à 07:07, Greg Kennedy a écrit :
> POV-Ray 3.7 gives this warning if you try to trace a scene without assumed_gamma
> set:
>
>> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.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.
>
> My question is: Why will this become a fatal error, instead of just defaulting
> to 1.0? It seems like most people would *want* there to be some sensible
> default, instead of breaking and having to add additional keywords to their
> scenes. I know I would, anyway.
>
Because... IIRC, scenes before modern era where rather with CRT gamma,
varying from 1.8 to 2.7; And it was wrong, physically, but it was the
usage and the design used that. So you cannot fix them automatically by
applying a 1.0 instead, or even a 2.4 everywhere.
And there is no way to guess the correct value.
What the message states is: for version 3.7 or greater, you should have
an assumed_gamma (and hopefully 1.0). Ulterior version of software might
consider that a 3.7 file without assumed_gamma is faulty. That's all.
Nothing more, nothing less.
It does not stop you from parsing 3.6, 3.5 or smaller version of a
scene. And then gamma handling is historical (and painful).
So, for 3.7+ scenes, take right now the habit of having an explicit
assumed_gamma, always.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > My question is: Why will this become a fatal error, instead of just defaulting
> > to 1.0? It seems like most people would *want* there to be some sensible
> > default, instead of breaking and having to add additional keywords to their
> > scenes. I know I would, anyway.
http://wiki.povray.org/content/User:Clipka/Gamma
I doubt that it would be assigned to fatal error status, and instead have a
default, and just issue a warning.
As it is, you can have scenes with no light and no camera, and they still
"render"...
I think that after all of the hair-yanking, brain-hurting effort that's been put
in over the years to get the gamma handling of POV-Ray onto solid footing, that
clipka simply wants people to be cognizant that working with an assumed_gamma of
1.0 is the way to go, and all other scene "fixes" can be addressed by some other
mechanism.
I couldn't find the particular thread where he explains the many pitfalls of
improperly using gamma != 1.0, but I can assure you that he has expostulated
passionately and extensively on the topic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2019-11-03 à 06:14, Le_Forgeron a écrit :
> Le 03/11/2019 à 07:07, Greg Kennedy a écrit :
>> POV-Ray 3.7 gives this warning if you try to trace a scene without assumed_gamma
>> set:
>>
>>> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.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.
>>
>> My question is: Why will this become a fatal error, instead of just defaulting
>> to 1.0? It seems like most people would *want* there to be some sensible
>> default, instead of breaking and having to add additional keywords to their
>> scenes. I know I would, anyway.
>>
>
> Because... IIRC, scenes before modern era where rather with CRT gamma,
> varying from 1.8 to 2.7; And it was wrong, physically, but it was the
> usage and the design used that. So you cannot fix them automatically by
> applying a 1.0 instead, or even a 2.4 everywhere.
>
> And there is no way to guess the correct value.
>
> What the message states is: for version 3.7 or greater, you should have
> an assumed_gamma (and hopefully 1.0). Ulterior version of software might
> consider that a 3.7 file without assumed_gamma is faulty. That's all.
> Nothing more, nothing less.
>
> It does not stop you from parsing 3.6, 3.5 or smaller version of a
> scene. And then gamma handling is historical (and painful).
>
> So, for 3.7+ scenes, take right now the habit of having an explicit
> assumed_gamma, always.
>
When rendering older scenes with gamma other than 1, setting it to 1
don't detract, and often gives better results anyway.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
> Le 2019-11-03 à 06:14, Le_Forgeron a écrit :
> > Le 03/11/2019 à 07:07, Greg Kennedy a écrit :
> >> POV-Ray 3.7 gives this warning if you try to trace a scene without assumed_gamma
> >> set:
> >>
> >>> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.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.
> >>
..
..
..
> When rendering older scenes with gamma other than 1, setting it to 1
> don't detract, and often gives better results anyway.
CRTs used respond non-linearly to electron beam intensity with, IIRC, low
electron beam intensities stimulating the phosphors too little. Old operating
systems/graphics display cards didn't add any correction factor so the only way
to view images (on a CRT) in true colour was to increase the RGB values of dark
colours using a gamma value of something like 2.4, when they were rendered. But
the precise value depended on your monitor. Rendering an image to send to a
printer might use a different gamma, maybe 1.0 (no correction). Though back
then, colour printers were rather poor quality.
For a short while, you could set a gamma value in Windows to suit your CRT
monitor, then all images displayed on the monitor would display correctly -
UNLESS they had already been gamma corrected, when dark colours would appear too
bright.
Thus, if you have old images that you rendered with a non-unit gamma, you should
expect them to have dark colours that don't look dark enough on modern monitors,
and if you re-render them with gamma = 1.0, they SHOULD appear more realistic.
In other words, using old files, even if you specify an old POV-Ray version, you
should probably re-set gamma to 1.0. I think this is why Clipka will give you a
warning if you don't specify an assumed gamma.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"JimT" <nomail@nomail> wrote:
> Alain Martel <kua### [at] videotronca> wrote:
> > Le 2019-11-03 à 06:14, Le_Forgeron a écrit :
> > > Le 03/11/2019 à 07:07, Greg Kennedy a écrit :
> > >> POV-Ray 3.7 gives this warning if you try to trace a scene without
assumed_gamma
> > >> set:
> > >>
> > >>> Possible Parse Error: assumed_gamma not specified in this POV-Ray 3.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.
> > >>
> ..
> ..
> ..
> > When rendering older scenes with gamma other than 1, setting it to 1
> > don't detract, and often gives better results anyway.
>
> CRTs used respond non-linearly to electron beam intensity with, IIRC, low
> electron beam intensities stimulating the phosphors too little. Old operating
> systems/graphics display cards didn't add any correction factor so the only way
> to view images (on a CRT) in true colour was to increase the RGB values of dark
> colours using a gamma value of something like 2.4, when they were rendered. But
> the precise value depended on your monitor. Rendering an image to send to a
> printer might use a different gamma, maybe 1.0 (no correction). Though back
> then, colour printers were rather poor quality.
>
> For a short while, you could set a gamma value in Windows to suit your CRT
> monitor, then all images displayed on the monitor would display correctly -
> UNLESS they had already been gamma corrected, when dark colours would appear too
> bright.
>
> Thus, if you have old images that you rendered with a non-unit gamma, you should
> expect them to have dark colours that don't look dark enough on modern monitors,
> and if you re-render them with gamma = 1.0, they SHOULD appear more realistic.
> In other words, using old files, even if you specify an old POV-Ray version, you
> should probably re-set gamma to 1.0. I think this is why Clipka will give you a
> warning if you don't specify an assumed gamma.
See, I understand the reasoning behind having the assumed_gamma parameter, at
least for older scenes. But what I don't get is, why is POV-Ray 3.7+ warn that
it will be a "Fatal error" in the future?
It seems to me that if you have
#version 3.7
(or higher)... then you should *by default* get assumed_gamma 1.0, and the
*only* reason POV-Ray should require this statement is if the user wants
something non-1.0 - for porting old pre-3.7 scenes, or special uses or whatever.
In my testing 1.0 does seem to be the default anyway, so, why force people to
include a command that sets the value to the default?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> I doubt that it would be assigned to fatal error status, and instead have a
> default, and just issue a warning.
> As it is, you can have scenes with no light and no camera, and they still
> "render"...
>
> I think that after all of the hair-yanking, brain-hurting effort that's been put
> in over the years to get the gamma handling of POV-Ray onto solid footing, that
> clipka simply wants people to be cognizant that working with an assumed_gamma of
> 1.0 is the way to go, and all other scene "fixes" can be addressed by some other
> mechanism.
I apologize for the double-post but I just spotted this reply, and it makes
sense to me. A scary warning will force people to notice the change in behavior
from 3.6 to 3.7, even if it never actually becomes fatal. It got my attention
anyway :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Greg Kennedy" <ken### [at] gmailcom> wrote:
> I apologize for the double-post but I just spotted this reply, and it makes
> sense to me. A scary warning will force people to notice the change in behavior
> from 3.6 to 3.7, even if it never actually becomes fatal. It got my attention
> anyway :)
No worries. These things need to get hammered out somehow over time.
Here's a thread where clipka shows some of the issues with gamma != 1.0
settings.
http://news.povray.org/povray.binaries.images/thread/%3C585abdb8%40news.povray.org%3E/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2019-11-03 à 10:00, Bald Eagle a écrit :
>
>
>>> My question is: Why will this become a fatal error, instead of just defaulting
>>> to 1.0? It seems like most people would *want* there to be some sensible
>>> default, instead of breaking and having to add additional keywords to their
>>> scenes. I know I would, anyway.
>
> http://wiki.povray.org/content/User:Clipka/Gamma
>
> I doubt that it would be assigned to fatal error status, and instead have a
> default, and just issue a warning.
> As it is, you can have scenes with no light and no camera, and they still
> "render"...
>
> I think that after all of the hair-yanking, brain-hurting effort that's been put
> in over the years to get the gamma handling of POV-Ray onto solid footing, that
> clipka simply wants people to be cognizant that working with an assumed_gamma of
> 1.0 is the way to go, and all other scene "fixes" can be addressed by some other
> mechanism.
>
> I couldn't find the particular thread where he explains the many pitfalls of
> improperly using gamma != 1.0, but I can assure you that he has expostulated
> passionately and extensively on the topic.
>
>
>
>
It's impossible to not have a camera as there is a default one :
camera{location 0
direction z
up y
sky y
right x*image_width/image_height // was x*1.3 before 3.7
look_at z
}
A gamma different than 1 break any additive features : Partial
reflection, partial transparency, highlights, area illuminated by more
than one light, ...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 11/4/19 6:30 PM, Greg Kennedy wrote:
>
> It seems to me that if you have
> #version 3.7
>
> (or higher)... then you should *by default* get assumed_gamma 1.0, and the
> *only* reason POV-Ray should require this statement is if the user wants
> something non-1.0 - for porting old pre-3.7 scenes, or special uses or whatever.
>
> In my testing 1.0 does seem to be the default anyway, so, why force people to
> include a command that sets the value to the default?
This makes sense.
--
dik
Rendered 22,077,619,200 of 40,928,716,800 pixels (53%)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|