Robert McGregor schrieb:

> One thing I forgot to mention that I struggled with is differences in display
> gamma, which can really yield a HUGE difference in the *perceived* image output.
> 
> I'm told it affects antialiasing too somehow, but...

It does indeed - somehow. POV-Ray does antialiasing in the same color 
space it uses for rendering, that is linear color space in POV-Ray 3.7 
(unless you use assumed_gamma, which you shouldn't anyway), which has 
the effect that the color difference at which AA kicks in /appears/ much 
higher for dark colors than for bright colors.

Not ideal, but that's how it is at present. Applying output gamma 
adjustment /before/ antialiasing would cause color distortions, depend 
on file type and/or File_Gamma setting, and wouldn't fit in the general 
architecture of 3.7 anyway, so it's no option either.


 > well I must admit that all

> good for compositing" and "Windows is 2.2" and "Mac is 1.6" (or something like
> that). Whatever. I've seen Warp and Clipka going back and forth about it over
> the last few months...

Just let it suffice to say that you really should set Display_Gamma to a 
suitable value as described in the documentation, as from the next beta 
on there really should be no reason left to tamper with the setting.


> Here are three renders of the exact same scene file but with, respectively,
> default gamma (i.e., no command line gamma), Display_Gamma=1.6, and
> Display_Gamma=1.0. I'm not sure why a command line Display_Gamma of 1.0 looks
> *completely* different than the supposed default 1.0 gamma for POV-Ray 3.7
> [i.e., without any Display_Gamma in the command line])?

That's because 1.0 is /not/ the default Display_Gamma; depending on your 
system, it should be 2.2 (PC and Unix), or... well, don't know, maybe 
1.6 for the Mac version.


> I guess I really just

> file images are identical, but this "display" thing really throws me off, since
> all are quite different.

That's because for file output, gamma is now governed by a separate 
File_Gamma keyword.


> This is one area where I can truly appreciate Jaime Vives Piqueres' ignorancia
> mindset... I know what looks good to me, so I adjust according to what I think
> looks right (and if it looks right, it *is* right!)

The thing is that gamma is not an "artistic" screw to tweak, but a 
purely technical one, intended to make sure that what /you/ see is as 
close as possible to what /others/ will see.

If you think your image looks too washed-out, but you are sure that you 
set Display_Gamma to the proper value (not according to what you think 
looks cool, but as explained in the documentation), then what you really 
should do is to fix your scene.

If you try to misuse this technical screw for artistic purposes, don't 
be surprised if the technical side starts getting in your way.


There's currently still one caveat to this principle, and that's input 
image files, which /will/ be rendered too washed-out depending on file 
type. Next beta will do a better job there.


(Readers please note that this all pertains to the current POV-Ray 3.7 
beta; older versions - including the latest "proper" release, 3.6.2 - 
are quite different beasts regarding gamma handling.)

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> schreef in bericht 
news:web.4aee3b76b57c8bb34726e92b0@news.povray.org...
> And for those of you that haven't yet tried modeling with Silo 2.1, I 
> highly
> recommend trying the free download, and for $99 US it's really amazing; It 
> also
> nice UV editing; and POV-Ray export built in (although I prefer OBJ to 
> PoseRay
> to Mesh2). I haven't touched Wings3d for months now.
>

I cannot agree more. Silo 2 changed my life :-)

Thomas

Post a reply to this message

"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> Ugh, nice typo... actually, that middle shot is supposed to read
> "Display_Gamma=1.6"

Thanks for the detailed explanation Rob, I too have never understood exactly how
gamma correction works.. (and I wish that was the only thing I didn't understand
about POV).

BTW I think the 1.6 image is best and now I am wondering what differnce this
would make to some/most/all of my images... Yet another lot of test renders to
perform before I submit my next image.

Sean

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Just let it suffice to say that you really should set Display_Gamma to a
> suitable value as described in the documentation, as from the next beta
> on there really should be no reason left to tamper with the setting.
>
> That's because 1.0 is /not/ the default Display_Gamma; depending on your
> system, it should be 2.2 (PC and Unix), or... well, don't know, maybe
> 1.6 for the Mac version.
> The thing is that gamma is not an "artistic" screw to tweak, but a
> purely technical one, intended to make sure that what /you/ see is as
> close as possible to what /others/ will see.
>
> If you think your image looks too washed-out, but you are sure that you
> set Display_Gamma to the proper value (not according to what you think
> looks cool, but as explained in the documentation), then what you really
> should do is to fix your scene.
>
> If you try to misuse this technical screw for artistic purposes, don't
> be surprised if the technical side starts getting in your way.
>
> There's currently still one caveat to this principle, and that's input
> image files, which /will/ be rendered too washed-out depending on file
> type. Next beta will do a better job there.

Thanks Christoph, I understand a *little* better now... I've gotten used to
"misusing" assumed_gamma over the last several years (with good results I think)
and v3.7 just ignores it.

So if using File_Gamma=2.2 on Windows, does v3.7 actually render in the linear
1.0 gamma space and then gamma correct to 2.2 for file output *after* the
antialiasing?

Post a reply to this message

Robert McGregor schrieb:

> So if using File_Gamma=2.2 on Windows, does v3.7 actually render in the linear
> 1.0 gamma space and then gamma correct to 2.2 for file output *after* the
> antialiasing?

Yes. POV-Ray 3.7 will always render in the linear 1.0 gamma space 
(unless using the now-deprecatedd "assumed_gamma" keyword).

Note that File_Gamma does not necessarily change the /look/ of the 
output file; this depends on whether the output file format is 
"gamma-aware" or not.

Post a reply to this message

> "Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
>> Ugh, nice typo... actually, that middle shot is supposed to read
>> "Display_Gamma=1.6"
> 
> Thanks for the detailed explanation Rob, I too have never understood exactly how
> gamma correction works.. (and I wish that was the only thing I didn't understand
> about POV).
> 
> BTW I think the 1.6 image is best and now I am wondering what differnce this
> would make to some/most/all of my images... Yet another lot of test renders to
> perform before I submit my next image.
> 
> Sean
> 
> 
Display_gamma should be set once only. It's value should be that of your 
display.
If your display HAVE a gamma of 1.6, you must set display_gama to 1.6.
It it's gamma is 2.2, you must set display_gamma to 2.2.

If you set display_gamma wrong, your preview will be wrong, your colour 
balance will be skewed, and your real image will look different when 
viewed with any viewer, and by others on different display.

assumed_gamma will affect the file, but NOT the display. It, to, must be 
correctly set. It MUST NOT be set specificaly for a given scene.

You should not need to gamma correct your image in any post process step.


Alain

Post a reply to this message

Hi
I search a Nixietube to make a visitor Counter.
please can you help me?
how can i download a nixie tube pov.ray set?

Your code i have tried but is not working, missing files.

Thank you for help.

cheers
Andrew



"Robert McGregor" <rob### [at] mcgregorfineartcom> wrote:
> Hi all, here's a test render of one of the tubes used in my "Time (Steampunked)"
> IRTC entry. My final shot doesn't reveal all the detail so I wanted to show a
> close up :)
>
> Sad Fact: I've been pretty bad lately about not posting my competition entries
> until the VERY end - in fact, three out of four of my most recent entries have
> been literally posted with only minute(s) to spare (tonight being no exception),
> so as a personal joke I set my alarm clock digits to read 23:59. It wasn't so
> funny tonight though when, with only a couple of minutes left befre deadline,
> the IRTC server was repeatedly giving me a "Too Busy" error code.
>
> Happy Fact: Luckily I finally did get my shot posted just before the round
> closed :)
>
> Cheers,
> Rob

Post a reply to this message

You need to contact Robert McGregor.

Thomas

Post a reply to this message