 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." <and### [at] f2s com> wrote in message
news:3baf6ad6$1@news.povray.org...
> > assumed_gamma is (should be) the gamma at which the scene was
> > designed.
>
> Not necessarily -- according to the docs:
>
> "For new scenes, you should use an assumed gamma value of 1.0 as this
models
> how light appears in the real world more realistically."
Yeah, I can't follow that line of reasoning even if it is only because of
what I see when rendering the images.
If you read there about how the MacIntosh or Apple computers Display_Gamma=
should be around 1.8 and PC's around 2.2 I wonder even more about the
statement you quoted.
In the paragraph above that one you brought up:
For PC systems, the most common display gamma is 2.2, while for scenes
created on Macintosh systems should use a scene gamma of 1.8. Another gamma
value that sometimes occurs in scenes is 1.0.
Makes me more confused than ever. As you can see, it actually is suggestive
of assumed gamma when speaking of the Mac. Wrong wording?
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I followed the diskussion and you are surely right, in an academic sense.
I reported the bug, because the BMP and the PNG output were different on
Polyview.
Polyview had shown no problem with earlier beta and other pov-ray versions.
My assumed_gamma value is 1 since some months, so there should be no
difference anyway.
I don`t know, where I can see my Display_Gamma, but it should be normal.
Norbert
> What are your assumed_gamma and Display_Gamma settings?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo <ray### [at] engineercom> wrote:
: I wonder how many applications actually use the png gamma information?
At least xv, Image Magick and Netscape 6.x in unix. All of them use the
gamma correction value and show the same result.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Norbert Kern" <nor### [at] t-onlinede> wrote in message
news:3baf7331$1@news.povray.org...
> I followed the diskussion and you are surely right, in an academic sense.
> I reported the bug, because the BMP and the PNG output were different on
> Polyview.
> Polyview had shown no problem with earlier beta and other pov-ray
versions.
> My assumed_gamma value is 1 since some months, so there should be no
> difference anyway.
> I don`t know, where I can see my Display_Gamma, but it should be normal.
POV directory\renderer\povray.ini holds the Display_Gamma= if you have one.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3baf6e49$1@news.povray.org Bob H. wrote:
> For PC systems, the most common display gamma is 2.2, while for
> scenes created on Macintosh systems should use a scene gamma of
> 1.8. Another gamma value that sometimes occurs in scenes is 1.0.
>
Guessing (as I used a pre 3.1 versions only for a week or two): going
from version 2.2/3.0/3.1 a few things changed. In older versions you
had to set the resulting gamma in the scene file. When a scene was
designed on a Mac and renderd on a PC there had changes to be made to
the scene file.
In the current situation this is not needed anymore as display_gamma
is set in the INI file, or defaults to the right value (at least
for PC). assumed_gamma 1 just tells the system to use that
display_gamma. final gamma = display_gamma/assumed_gamma, so
assumed_gamma can be used to make small changes to the illumination of
the scene, but in general it would be better to do it with the
lightning sceme to prevent cross platform problems.
As to the value to be written to the PNG file, shouldn't it be
1/final_gamma instead of 1/display_gamma? Or is that one correction too
much?
Ingo
--
Photography: http://members.home.nl/ingoogni/
Pov-Ray : http://members.home.nl/seed7/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <ing### [at] homenl> wrote in message
news:Xns### [at] povrayorg...
> in news:3baf6e49$1@news.povray.org Bob H. wrote:
>
> > For PC systems, the most common display gamma is 2.2, while for
> > scenes created on Macintosh systems should use a scene gamma of
> > 1.8. Another gamma value that sometimes occurs in scenes is 1.0.
> >
>
> Guessing (as I used a pre 3.1 versions only for a week or two): going
> from version 2.2/3.0/3.1 a few things changed. In older versions you
> had to set the resulting gamma in the scene file. When a scene was
> designed on a Mac and renderd on a PC there had changes to be made to
> the scene file.
>
> In the current situation this is not needed anymore as display_gamma
> is set in the INI file, or defaults to the right value (at least
> for PC). assumed_gamma 1 just tells the system to use that
> display_gamma. final gamma = display_gamma/assumed_gamma, so
> assumed_gamma can be used to make small changes to the illumination of
> the scene, but in general it would be better to do it with the
> lightning sceme to prevent cross platform problems.
>
> As to the value to be written to the PNG file, shouldn't it be
> 1/final_gamma instead of 1/display_gamma? Or is that one correction too
> much?
Don't know, but looking at the last line of the last paragraph of section
5.2.2.2 in the doc I see it says newer hardware could use Display_Gamma 1.0.
Having tried that just now since I have the ATI mobility 128, which must
certainly have gamma correction of some sort, and putting assumed_gamma 1.0
as recommended I get a perfectly good rendering. So it was the visually
adjusted display gamma I had always set before which messed that idea up. I
kept thinking display gamma had to be set manually by using the graphic
supplied in the doc.
Anyway, I'll be checking into this once again to find how the images end up.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob H." wrote:
>
> Don't know, but looking at the last line of the last paragraph of section
> 5.2.2.2 in the doc I see it says newer hardware could use Display_Gamma 1.0.
Most card drivers allow you to change the gamma to any
value you want. So you can work at gamma 1.0. OTOH, lots
of people will then complain about your images. IIRC,
Fabien Mosen told me he worked at a gamma around 1.7.
> Having tried that just now since I have the ATI mobility 128, which must
> certainly have gamma correction of some sort, and putting assumed_gamma 1.0
> as recommended I get a perfectly good rendering.
But what was your Display_Gamma?
> I
> kept thinking display gamma had to be set manually by using the graphic
> supplied in the doc.
Definitely yes.
--
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
Mes propos n'engagent que moi et en aucun cas mes employeurs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Norbert Kern wrote:
>
> I reported the bug, because the BMP and the PNG output were different on
> Polyview.
That's interessant! I don't think this is a correct behaviour.
Can anybody else test it? I'm at work and I can't.
> Polyview had shown no problem with earlier beta and other pov-ray versions.
Have you tried other programs?
E.g. http://www.irfanview.com is not a very big download (~600KB)
--
Adrien Beau - adr### [at] freefr - http://adrien.beau.free.fr
Mes propos n'engagent que moi et en aucun cas mes employeurs
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Adrien Beau" <adr### [at] sycomorefr> wrote in message
news:3BB041E4.76733B14@sycomore.fr...
> "Bob H." wrote:
> >
> > Don't know, but looking at the last line of the last paragraph of
section
> > 5.2.2.2 in the doc I see it says newer hardware could use Display_Gamma
1.0.
>
> Most card drivers allow you to change the gamma to any
> value you want. So you can work at gamma 1.0. OTOH, lots
> of people will then complain about your images. IIRC,
> Fabien Mosen told me he worked at a gamma around 1.7.
>
> > Having tried that just now since I have the ATI mobility 128, which must
> > certainly have gamma correction of some sort, and putting assumed_gamma
1.0
> > as recommended I get a perfectly good rendering.
>
> But what was your Display_Gamma?
1.0 also, as was suggested for newer (about post-1995 do you think? :-))
video hardware in the doc.
> > kept thinking display gamma had to be set manually by using the graphic
> > supplied in the doc.
>
> Definitely yes.
If I set that to 2.3 though, which is what I get for the LCD screen near as
I can tell, then I must use assumed_gamma 2.3 also or none at all. Using
1.0 for both settings is the exact same thing. This is what I wonder about
then, whether it makes any difference once rendering on another machine.
This of course depends on whether or not assumed gamma is applied at all or
not.
Apparently the concept of using 1.0 for both isn't expressed in no uncertain
terms, that's why I always set display gamma to a visual appearance and then
expected assumed gamma would compensate from there. Sorry about being so
inept about this but it's one of those things that leads me in circles.
I'm posting (yet another) gamma comparative image to p.b.i. in a minute just
to see if anyone has some more ideas on this cross-platform stuff which I
have no idea about.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob H." wrote:
>
> If I set that to 2.3 though, which is what I get for the LCD screen
LCD and gamma don't mix. Gamma correction is for CRT only.
The response curve of non compensated LCD displays is totally
different from CRT response and trying to measure or apply
gamma with that hardware won't do much good.
I know there are TFT displays that emulate sRGB CRT and those
are hard wired to gamma 2.2. They can be used for graphics work
but the LCD displays I have seen have been non compensated
and unsuitable for editing graphics.
So, if the manual that came with the hardware doesn't mention
anything about sRGB, CRT or gamma emulation forget gamma.
Quick search produced this review about LCD projectors. What is
said here applies also to LCD displays. In short, LCD displays
are problematic.
From http://www.zdnet.co.uk/pcmag/labs/2000/04/projectors/21.html
----
Gamma is a critical parameter for any display product because it
determines how accurately tonal values are reproduced. Although
this might not be so important for high-contrast business
graphics, it's important for the reproduction of natural
images--high-quality images of fine art, for example. Displays
with response curves that follow a power curve
(but with the 'wrong' exponent) can be corrected to the desired
curve. However, some display products exhibit black and white
compression, resulting in an S-shaped curve. Unless this can be
removed by manipulation of the brightness and contrast controls,
images displayed by these products can't be improved purely by
simple gamma correction.
The gamma characteristics for many of these projectors show large
deviations from the ideal, and the controls that relate to gamma
contrast and brightness were difficult to set. In this review, the
Philips Hopper XG10 and, to a lesser extent, the Toshiba TLP651E
both have S-shaped gamma curves.
----
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
