 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all!
System: POV-Ray for Windows v3.5b3, Win98SE, AMD Athlon 1.4 GHz,
1024 megs SDRam
PNG output (by +fn) in beta 3 makes image output way too bright. It can only
be seen with an extern viewer, not while rendering. It seems output has a
gamma of 1.0 while it should be 2.2.
Beta 2 behavior was correct.
Norbert
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> PNG output (by +fn) in beta 3 makes image output way too bright. It can only
> be seen with an extern viewer, not while rendering.
ACDSee Classic and Photoshop 5.5 png display seems to be correct. Win98SE.
Are you sure you have configured the viewer correctly?
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have noticed this error some time ago.
The problem seems that POV-Ray outputs to the PNG file a gamma value of
1.0 while it should be 1.0/Display_Gamma, which would give the correct result.
(Another solution is to not to output any gamma value to the PNG... But
then the Display_Gamma option would not have effect on the final image; this
may even be better...)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I have noticed this error some time ago.
>
> The problem seems that POV-Ray outputs to the PNG file a gamma value of
> 1.0 while it should be 1.0/Display_Gamma, which would give the correct result.
> (Another solution is to not to output any gamma value to the PNG... But
> then the Display_Gamma option would not have effect on the final image; this
> may even be better...)
I REALLY like the idea that display gamma has no effect whatsoever on the output
file. I would assume that assumed gamma would.
--
Jon A. Cruz
http://www.geocities.com/joncruz/action.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon A. Cruz <jon### [at] geocities com> wrote:
: I REALLY like the idea that display gamma has no effect whatsoever on the output
: file.
Then POV-Ray should not write any gamma value to the PNG file (this is
easy to implement in the current source code by commenting out 2 lines).
: I would assume that assumed gamma would.
It already does. The assumed_gamma value affects the actual values of the
pixels written to the image file (regardless of the format).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon A. Cruz" wrote:
>
> I REALLY like the idea that display gamma has no effect whatsoever on the output
> file.
Then what's the the point in specifying and measuring display gamma?
The samples in the file are calculated using assumed_gamma/Display_Gamma
as the exponent. Assumed gamma is best used as a contrast control for
compensating scene lighting conditions (indoors/outdoors/night) and should
not be included in the display gamma information in the image file.
TweakPNG shows that pov sets the gamma header to 1.0 on all pngs. It
should be 1/Display_Gamma as Warp pointed out.
As usual Photoshop does it's own thing and ignores the png gamma :)
I wonder how many applications actually use the png gamma information?
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Kari Kivisalo wrote:
>
> "Jon A. Cruz" wrote:
> >
> > I REALLY like the idea that display gamma has no effect whatsoever on the output
> > file.
>
> The samples in the file are calculated using assumed_gamma/Display_Gamma
> as the exponent. Assumed gamma is best used as a contrast control for
> compensating scene lighting conditions (indoors/outdoors/night) and should
> not be included in the display gamma information in the image file.
assumed_gamma is (should be) the gamma at which the scene was
designed. Display_Gamma is (should be) the gamma of the system
on which the file is being rendered.
Of course, when rendering on the system on which the file was
created the values are (should be) the same. So the files are
written on the disk as if no gamma correction has happened,
which is the right thing to do since most format can't account
for gamma correction.
But give your PC-source to a Mac user, and the values will be
different (and well needed). So the files are written on the
disk with a gamma correction - but this gamma correction was
achieved through higher-precision internal POV math.
Finally, 1/Display_Gamma is (should be!) written into gamma-
supporting file formats, so that viewers on other platforms
can correct the image on the fly, if they have been configured
correctly. Anyway, the user on the other platform can also
rerender the file, if he has the source.
* Kari, I'm sure you know all this, but I felt the need
* to recap, if only for my own understanding of the issue.
> TweakPNG shows that pov sets the gamma header to 1.0 on all pngs. It
> should be 1/Display_Gamma as Warp pointed out.
I agree.
> As usual Photoshop does it's own thing and ignores the png gamma :)
> I wonder how many applications actually use the png gamma information?
Not many, I'm afraid. Worst of all, they don't say if they do,
and to which extend.
Actually, I find that gamma has become impossibly hard to
manage, since every application layer corrects (corrupts?)
it to some extent, now. Windows does some gamma correction
on its own through color profiles. Then, e.g. Paint Shop Pro
adds another layer of gamma correction, and I have the worst
experience: if you select a color in the palette (drawn
by Windows), your pencil draws with another color, because
it was corrected by PSP on the way. :-(
But that doesn't diminish the need for assumed_gamma and
Display_Gamma, which are independant of all this mess.
--
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:
>
> Beta 2 behavior was correct.
Not necessarily. You can only say "behavior was different".
What are your assumed_gamma and Display_Gamma settings?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Anders K." <and### [at] f2scom> 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
|
|
| |
| |
|
|
|
|
| |
