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


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