 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> Mike Raiford wrote:
>
>> One question: b9 seems to complain about the assumed_gamma setting in
>> the scene files. I know to look write a lot of scenes requre their own
>> assumed_gamma setting, now it needs to be on the command line?
>
>
> Yes, and if you really need to play with assumed_gamma, you are actually
> using it for something it isn't supposed to be used for (adjusting the
> brightness of a scene). There will be other mechanisms for doing that
> eventually (also on the command-line though).
Wow. Glad you made sense of what I wrote (I think I was short on
caffiene at the time ;). Yes, this is what I was using it for, mainly in
radiosity scenes it seems to bring out the shadows a bit more. A better
alternative to this might be something like the tone-mapping patch in
MegaPOV (I don't know if it is technically feasable, given your
explanations of the assumed_gamma issue)
Anyway, I was wondering, becuase it seemed like the assumed_gamma
commandline option wasn't having an effect.
> In case you are wondering why this (and a few other) changes are
> necessary, it has to do with the division of work between the various
> parts inside POV-Ray. Now that we have a clear structure (in POV-Ray
> 3.7) various logic problems surface that simply did not matter before
> (where everybody was just getting their data where they wanted).
> Essentially this setting and a few others should never have been in the
> scene file for this reason, but nobody noticed back when it was added.
> Over time more patches added things to the global settings that they
> should have been command-line settings as well. So now we clean it us.
> The upside is, this will make developing newer versions of POV-Ray a lot
> easier and faster because the chance to cause a bug by some minor change
> that some other end of the code depends on its a whole lot smaller.
>
In the end, I think this will be very positive for the program, this
seems to be what is making this such a long beta cycle and breaking so
many things.
--
~Mike
Things! Billions of them!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> Anyway, I was wondering, becuase it seemed like the assumed_gamma
> commandline option wasn't having an effect.
It won't yet, that part isn't implemented yet. With gamma the only thing
that changed was the warning message between beta 8 and beta 9, the frontend
doesn't make any use of gamma yet.
> In the end, I think this will be very positive for the program, this
> seems to be what is making this such a long beta cycle and breaking so
> many things.
Well, the beta cycle for POV-Ray 3.5 was well over half a year with iirc 18
public releases. So we are within the usual timeframe I suppose :-)
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
One thing I neglected to mention is that radiosity save/load isn't
implemented at the moment, so please don't be surprised if it doesn't
work ...
-- Chris
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Moving assumed_gamma out of the scene file is going to be a very good thing.
I was glad to read that in changes.txt.
I thought, right away, that the idea is to make it less of an image tweak
and more of a display adjustment like it was intended for. In other words,
it probably got overused or abused where it was. Prior to version 3.6 I was
often unconcerned with what affect I was doing to the scene file and its
render as to any global sense. Global meaning other computers not just
global to a rendered scene.
I must be thinking of MegaPOV about some sort of contrast adjustments on the
scene renders. Seemed like someone here mentioned replacing assumed_gamma
with a way to do that instead, but I don't find anything said of it.
Of course, I realize now, this official change is likely to be only a gamma
code remake and not a feature addition at the same time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Essentially this setting and a few
> others should never have been in the scene file for this reason
I don't understand this (for assumed_gamma only).
I do understand that assumed_gamma was never meant to be used for adjusting
the brightness of a scene.
However, I thought its purpose was to let the artist say, "when I made this
image, I assumed the viewer had a gamma of x." That's an important
assumption that affects the appearance of the colors the artist chose. In
that way, it is strongly linked to the scene (and so should be stored in the
scene file).
The only thing that should be able to change when the image is rendered on a
different computer is the display gamma, so that when POV-Ray does its gamma
correction, the render displayed on the screen appears the same as it did to
the artist on his own screen. Allowing the renderer to change the
assumed_gamma - that is, to change an assumption the artist based his colors
off of - will cause the final image to look different.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>>Essentially this setting and a few
>>others should never have been in the scene file for this reason
>
> I don't understand this (for assumed_gamma only).
>
> I do understand that assumed_gamma was never meant to be used for adjusting
> the brightness of a scene.
>
> However, I thought its purpose was to let the artist say, "when I made this
> image, I assumed the viewer had a gamma of x." That's an important
> assumption that affects the appearance of the colors the artist chose. In
> that way, it is strongly linked to the scene (and so should be stored in the
> scene file).
Well, yes and no. You might know, the gamma factor POV-Ray uses internally
is simply assumed-gamma divided by display-gamma. So what assumed-gamma is
really good for is tweaking display-gamma. Of course, as you argue, that is
specifically what it is designed for. The main problem is that it is not
what it gets used for. To make proper use of it, you first need a proper
display-gamma. The chance that you have to tools (an external measurement
device or a pre-calibrated screen) is extremely unlikely. So you cannot get
a truly accurate display-gamma. Consequently, what do you do? You tweak
assumed-gamma because that is what you can easily change on a scene by scene
basis.
So assumed-gamma makes sense, right? Wrong! ;-) What you did with this use
of assumed-gamma is exactly what it is not for because all you do is alter
the brightness on a scene by scene basis, while still using the exact same
display and display-gamma. So, what you get is indeed some kind of
brightness adjustment, but that isn't what assumed-gamma is for. Yet, that
is what you effectively used it for, without really doing so consciously.
So, if you think about it, what good is assumed-gamma for once you adjusted
display-gamma to your screen? Basically, nothing that has to do with gamma!
:-)
Thus, while we still provide it mainly for backward compatibility as far as
possible (you can render old scenes without changing your display-gamma), to
adjust brightness we will provide a more flexible and more suitable mechanism.
I realise this is a huge change. Still, it is one we had to make for a
"better future".
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich <tho### [at] trf de> wrote:
> I realise this is a huge change. Still, it is one we had to make for a
> "better future".
Will POV-Ray include a way to modify the rendered pixels in the scene file
with eg. a user-defined function?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> You tweak
> assumed-gamma because that is what you can easily change on a scene by
scene
> basis.
I'm sure a lot of people do this, but I wouldn't be surprised to hear of
someone who had used assumed_gamma properly. For instance, if I had
discovered assumed_gamma one day and decided I should use it, I would have
set assumed_gamma 1.8 (for instance) in all my old scenes (since I had
developed them assuming the viewer had the same gamma my screen did), and
then used assumed_gamma 1 in all my new scenes. If I also set
display_gamma=1.8 in povray.ini, my old scenes wouldn't change, and my new
scenes would be rendered properly for anyone else who had their
display_gamma set.
So what if there are people out there who have done just this? I'm worried
you're removing an important feature because some people use it wrong.
Given the purpose of the feature, and how its meaning is linked to the
scene, I think it would make more sense to remove it entirely than make it a
command-line option. If it's still available, people might still abuse it,
so the only people who suffer are the ones who used it properly in the first
place.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rendering scenes\advanced\abyss.pov gives, once again, an image with
a black background, not light cyan as should be.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bob Hughes wrote:
>
> I must be thinking of MegaPOV about some sort of contrast adjustments on the
> scene renders. Seemed like someone here mentioned replacing assumed_gamma
> with a way to do that instead, but I don't find anything said of it.
Since the MegaPOV tone mapping has been brought up in this context i
like to point out a few things.
The tone mapping patch primarily allows to apply color adjustments prior
to antialiasing (although it allows to specify them for post-aa as well)
which can be useful for high quality results with more-than-subtle
nonlinear adjustments. This has been discussed in depth and no need to
bring this up again. The patch can be used to do exactly what
assumed_gamma does (both before and after aa at your decision) and there
is a macro in tone_mapping.inc (Gamma_Correct()) that does exactly this.
The display_gamma/assumed_gamma distinction does only make sense if
assumed_gamma can be set in the scene file (and in this case there is no
real point to restrict it to a gamma factor). Without this two distinct
gamma factors are confusing and should be replaced by a single one (for
which both display_gamma and assumed_gamma would be misleading names).
Christoph
--
POV-Ray tutorials, include files, Landscape of the week:
http://www.tu-bs.de/~y0013390/ (Last updated 24 Jul. 2005)
MegaPOV with mechanics simulation: http://megapov.inetart.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
