Will W wrote:
...
>>The way I understand it is you set assumed_gamma to 1 and leave it
>>alone, as others have said, it may be less confusing if it were a
>>boolean option to select whether gamma correction is applied to the
>>output. You develop your scene using display_gamma set to 1.8, and do
>>any renders designed to be viewed on similar systems the same way. When
>>you do a render designed to be viewed on systems with display systems
>>having a gamma value nearer 2.2, you change the display_gamma value to
>>2.2 for the final render. It looks bright on your monitor, but you send
>>it off to a PC user and it looks spot on when they view it on their
>>gamma 2.2 system.
> 
> 
> That sounds like an alternate approach that could work. However it isn't the
>  one that's implemented in POV-Ray.

I maintain that it is.

Take this concrete example: You have a setup that delivers a display 
gamma of 1.8, so you set display_gamma = 1.8 in POV. You create a new 
scene with assumed_gamma = 1 and you render yourself some nice 
wallpaper. You send this wallpaper to a friend with a system that 
delivers a display gamma of 2.2, and she complains that it is too dark. 
You remedy this situation by re-rendering it with assumed_gamma changed 
from 1 to 2.2. Only trouble is, going from an assumed_gamma of 1 to an 
assumed_gamma of 2.2 makes the image *darker*. Try it and see.

Now my method: Same up to where the friend complains, then you remedy 
the situation leaving assumed_gamma alone and changing display_gamma 
from 1.8 to 2.2. This creates a brighter image and your friend can see 
the wallpaper just fine.

Post a reply to this message

On Tue, 15 Apr 2003 20:07:14 +1000
Edward Coffey <eco### [at] alphalinkcomau> wrote:

> Now my method: Same up to where the friend complains, then you remedy 
> the situation leaving assumed_gamma alone and changing display_gamma 
> from 1.8 to 2.2. This creates a brighter image and your friend can see
> the wallpaper just fine.

  Yes, but you can also set assumed_gamma to 1.8/2.2 to achieve the same
effect without having to alter your povray.ini, if I read well the
manual.

-- 
Jaime Vives Piqueres
		
La Persistencia de la Ignorancia
http://www.ignorancia.org

Post a reply to this message

Jaime Vives Piqueres wrote:
> On Tue, 15 Apr 2003 20:07:14 +1000
> Edward Coffey <eco### [at] alphalinkcomau> wrote:
> 
> 
>>Now my method: Same up to where the friend complains, then you remedy 
>>the situation leaving assumed_gamma alone and changing display_gamma 
>>from 1.8 to 2.2. This creates a brighter image and your friend can see
>>the wallpaper just fine.
> 
> 
>   Yes, but you can also set assumed_gamma to 1.8/2.2 to achieve the same
> effect without having to alter your povray.ini, if I read well the
> manual.

Starting from an assumed_gamma value of 1 and a display_gamma of 1.8 on 
a system with gamma of 1.8 you could change assumed_gamma to 1.8/2.2 
(approximately 0.82) to have the image display correctly on a gamma 2.2 
machine if you were dead set against altering your display_gamma, but 
why bother? The POV-Ray gamma features allow you to do it all easily - 
set assumed_gamma to 1, set display_gamma to whatever your system's 
gamma is. When rendering for display on a different system, set 
display_gamma to whatever that system's gamma is, then set it back again 
when the render is finished. What could be simpler?

Post a reply to this message

"Jaime Vives Piqueres" <jai### [at] ignoranciaorg> wrote in message
news:200### [at] ignoranciaorg...
> On Tue, 15 Apr 2003 00:38:37 -0700
> "Will W" <wil### [at] NOSPAMwizzardsnet> wrote:
>
> > [note] It occurred to me as I was rereading this that if I'm using POV
> > to prepare an image for a heightfield, I probably need to set
> > assumed_gamma at zero or the heightfield will be distorted.
>
>   This will give you a blank image! :)

Yes, pure white!  I just tried it. It's one of those "raise to the zeroeth
power" things.

The proper way to do what I intended would be to comment out the
assumed_gamma. I was getting confused in my late night thinking. OTOH,
setting  "HF_Gray_16 on" probably does something like this... I'll have to
check that out when I next go back to messing around in heightfields.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

"Edward Coffey" <eco### [at] alphalinkcomau> wrote in message
news:3E9### [at] alphalinkcomau...
> Will W wrote:
>
> > That sounds like an alternate approach that could work. However it isn't
the
> >  one that's implemented in POV-Ray.
>
> I maintain that it is.
>
<snip good example>

Yes, you can force POV to do it this way. But it is not the way the gamma
tools were desigend to work.

Here's a counter example: Roll the clock forward about two years. In 2005
you do up some wallpaper on your trusty old Mac with its gamma of 1.8 and
send it tou your friend who is still using her trusty old PC with its gamma
of 2.2. She emails you an immediate response saying that she's delighted,
the colors are so vibrant! Neither of you think about gamma.

Why is this? Where has the gamma problem gone to?

It went into history. Although neither you nor your friend have updated your
hardware in quite a while, you are both staying current with software and
recent trends. So naturally you sent her the image in a lossless compression
.png file, which is so much better than the lossy old jpg files everybody
used to use. The png file also carries the gamma information so it can tell
whatever machine it ends up on how to best display itself. No problems.

*That* is what POV's gamma system is designed for. Eternal universality--
what a concept.

If you want the image files you develop in POV to still look good a couple
of years from now, a good thing to do would be to use POV's gamma controls
as documented, and use the .png format for your images. Currently that is
the only one that carries its own gamma correction information. It is the
most likely format to still look good when we are all using newfangled
roll-up organochromatic monitors with their wierd sub-one gammas (or
whatever they will have).


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

Will W wrote:
> 
> [...]
> 
> It went into history. Although neither you nor your friend have updated your
> hardware in quite a while, you are both staying current with software and
> recent trends. So naturally you sent her the image in a lossless compression
> .png file, which is so much better than the lossy old jpg files everybody
> used to use. The png file also carries the gamma information so it can tell
> whatever machine it ends up on how to best display itself. No problems.

Except the 'small' problem of very low quality results.  Applying gamma
correction to a 8 bit image will lead to immense quality losses (and the
known effects like color stripes in the skies etc.).  

This whole discussion is not any different than a lot of other ones that
have been made before in these groups.  There are always the same two
points:

a) what gamma settings one should one use in ini and scene file?
b) how one does achieve the image looking right on all computers?

Both questions have a technically satisfying answer:

a) adjust display_gamma according to the characteristic of your output
device, use 'assumed_gamma 1' if you want POV-Ray to adjust gamma for you,
don't use any assumed_gamma if you don't.
b) render the image with linear colors (no assumed_gamma) to 16bit output
and apply gamma correction individually on the system where the image is
displayed.

This solution of course has its practical problems:

- people who are used to graphics programs which don't apply a gamma
correction afterwards (like most paint programs) are not used to defining
colors in this way - they will intuitively use wrong colors.
- most image displaying programs are neither able to deal with more than 8
bit color depth nor to automatically apply the appropriate gamma
correction before showing the images.
- 16 bit images tend to be somewhat larger.

And i guess this situation will be the same in 2005 except one can hope
that the abilities of image display programs are somewhat better by
then...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Your premise that .png color depth is limited is wrong. The format supports
variable depths up to 48 bit/pixel, which is more than adequate. Browsers
and image editors that handle these greater color depths are beginning to
show up now.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net

Post a reply to this message

Will W wrote:
> 
> [...] Browsers
> and image editors that handle these greater color depths are beginning to
> show up now.

Show me any browser that does apply gamma correction automatically and
reads more than 8 bit color depth images.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Jaime Vives Piqueres wrote:

>   Yes, but you can also set assumed_gamma to 1.8/2.2 to achieve the same
> effect without having to alter your povray.ini, if I read well the
> manual.

That works fine when only you work on the scene. But it doesn't work in
collaborative project. Every time you download new files you override
your settings. The advantage of tuning only Display_Gamma is that it's not
placed in the source file. You can change it either in INI or type it in
that
text field for parameters.

Gena.

Post a reply to this message

Wait for them. They will show up.

Here's some info on what's going on:
http://www.libpng.org/pub/png/pngstatus.html#browsers

Part of the problem is that the MS web server, IIS, was written to serve
.png files as the wrong MIME type-- there is a post-installation fix but
there has not been much effort made by MS to get IIS users to install it. Of
course with Apache making steady inroads into the MS/IIS market, this issue
is going away (people with minimal tech skills are now using Apache for
their web server in preference to IIS-- partly because in doing so they
don't have to learn the arts of managing IIS patches).

As you can see, Amaya has had some limited support for png from day one, and
continues to improve it (since Amaya is used as a validator of W3C standards
by much of the web industry, this is more important than their small
installed base would make it seem). Mozilla has been steadily improving png
support and I see that it now has gamma correction support (Yippee! Note to
self: check browser configuration since last upgrade). Since the
Mozilla/Gecko engine is at the core of most non-MS browsers, this is
significant. Opera has some png support, I'm not sure how much. Since less
than half of one percent of my web site visitors use Opera, I've not been
tracking it. Rumors are that MSIE will provide good png support in the next
major release, probably next year.

I think this disucssion has wandered about as far off topic as is
reasonable. The original concern was what to do about gamma settings in a
joint project where several different people would be writing textures on
different machines with different system gammas. I think that discussion has
been satisfactorily concluded. There was an interesting sidebar about using
gamma settings to target a specific audience, and that developed into a
brief discussion about using gamma settings and file format choices to
assure that a future audience will see an image as the artist intended. I
really don't think there is much more useful ground to cover in this
direction.


--
Will Woodhull
Thornhenge, SW Oregon, USA
willl.at.thornhenge.net


"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3E9C37BE.3E1A9C17@gmx.de...
>
>
> Will W wrote:
> >
> > [...] Browsers
> > and image editors that handle these greater color depths are beginning
to
> > show up now.
>
> Show me any browser that does apply gamma correction automatically and
> reads more than 8 bit color depth images.
>
> Christoph

Post a reply to this message