 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh yeah, sorry about forgetting what you said a few months ago concerning
that. Thanks.
Does this mean only a LCD is liable to be okay for setting both display and
assumed gamma to 1.0? Or is that okay for a CRT too? I take it the answer
is no.
Bob H.
"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3BB0662D.236C2598@engineer.com...
> "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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3bb09022@news.povray.org> , "Bob H." <omn### [at] msncom> wrote:
> Does this mean only a LCD is liable to be okay for setting both display and
> assumed gamma to 1.0? Or is that okay for a CRT too? I take it the answer
> is no.
You should be able to measure your display and have software adjust the
color representation accordingly. Of course, with a CRT this is much easier
because its colors usually don't change much when viewed from a different
angle. So, if you are up for a 'realistic' color representation, calibrated
output on a CRT is preferable over any LCD. Of course, in a few years this
might change once better LCDs or other technologies are available.
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bob H." wrote:
>
> Does this mean only a LCD is liable to be okay for setting both display and
> assumed gamma to 1.0? Or is that okay for a CRT too? I take it the answer
> is no.
When assumed_gamma=Display_Gamma the samples written to the image file
are linear. Easier way to make this happen is not to use assumed_gamma
at all.
It all depends on whether you want gamma correction or not. Because
povray can't do correction for LCD displays you have to find another
way to do it and have povray output linear samples. Most of the time
it's sensible to enable gamma correction when working with CRT.
You are of course free to use any means to get the image look good on
LCD but...
Then there is the problem of publishing images designed on LCD. Because
99% of images are not viewed on LCDs the LCD correction has to be removed
and (preferably) gamma 2.2 applied before publishing. When using 8 bit
samples this means the image will be in pretty bad shape after all these
conversions.
_____________
Kari Kivisalo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
From all this discussions it's starting to seem to me that the best way
to go is just that POV-Ray would not write any gamma correction value to
the PNG. This way it works exactly like when writing to any other image
format.
As this only requires commenting out 2 lines of the source code, it should
be easy to implement. Of course it can be discussed (for an eternity) whether
this really is the correct way of doing it.
If the final version of 3.5 will behave like the current beta, I'll certainly
comment that part myself by hand when compiling the unix version. Of course
the Windows version will still have the problem as I don't have any compiler
for that...
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I insist on the png bug in beta 3 (and 4).
The png output is different from the bmp output, when I use Polyview as a
viewer program.
Beta 1, beta 2 and any other pov-ray version behaved okay and now something
has changed lately.
IIRC there was something "hacked".
Or am I too stupid to understand the whole discussion?
Norbert
"Warp" <war### [at] tagpovrayorg> schrieb im Newsbeitrag
news:3bb0b6d4@news.povray.org...
> From all this discussions it's starting to seem to me that the best way
> to go is just that POV-Ray would not write any gamma correction value to
> the PNG. This way it works exactly like when writing to any other image
> format.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can confirm the bug here (beta 4, WinNT 4). It depends on the viewer
however : I have no problem with Micrografx Publisher but Microsoft Image
Composer and Netscape 6.1 show a clear difference.
G.
--
**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery
Norbert Kern <nor### [at] t-onlinede> a écrit dans le message :
3badbff6$1@news.povray.org...
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Norbert Kern <nor### [at] t-onlinede> wrote:
: The png output is different from the bmp output
No, it isn't. It's just that POV-Ray outputs a gamma correction value to
the PNG which is not correct and the viewer program uses this gamma correction
value.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran <tra### [at] inapginrafr> wrote:
: It depends on the viewer however
This is because all programs do not support/use the gamma correction value
of the PNG file.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kari Kivisalo" <ray### [at] engineercom> wrote in message
news:3BB09F2D.EAB9E5EB@engineer.com...
> "Bob H." wrote:
> >
> > Does this mean only a LCD is liable to be okay for setting both display
and
> > assumed gamma to 1.0? Or is that okay for a CRT too? I take it the
answer
> > is no.
>
> When assumed_gamma=Display_Gamma the samples written to the image file
> are linear. Easier way to make this happen is not to use assumed_gamma
> at all.
Okay. I stumbled across this web page that might be interesting to some:
http://positron.cs.berkeley.edu/gwlarson/vrml (this is the directory
instead, I had some trouble using links there)
> It all depends on whether you want gamma correction or not. Because
> povray can't do correction for LCD displays you have to find another
> way to do it and have povray output linear samples. Most of the time
> it's sensible to enable gamma correction when working with CRT.
>
> You are of course free to use any means to get the image look good on
> LCD but...
>
> Then there is the problem of publishing images designed on LCD. Because
> 99% of images are not viewed on LCDs the LCD correction has to be removed
> and (preferably) gamma 2.2 applied before publishing. When using 8 bit
> samples this means the image will be in pretty bad shape after all these
> conversions.
Thanks for the reply as well Thorsten. However the notebook LCD I have here
is probably not worth the effort to try and correct. I sent the first one
back because of how the screen shifts in brightness from top to bottom. I
thought getting a TFT Active Matrix kind would be better than it is for this
DELL. My first experience with them and not a great one. A trade off from
somewhat fuzzy, yet evenly lit, CRT to polarized-like, yet clear as it gets,
LCD.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3bb0cd61@news.povray.org...
> I can confirm the bug here (beta 4, WinNT 4). It depends on the viewer
> however : I have no problem with Micrografx Publisher but Microsoft Image
> Composer and Netscape 6.1 show a clear difference.
Might want to have a look at the web pages I came upon authored by someone
from Silicon Graphics and IBM concerning linear gamma (?) for consistency in
VRML conversion to other renderers. At least I think that was the idea
expressed.
Bob H.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
