I just rendered a simple image using the following code using the switches 
+fn +Q9:

camera
{
  location <1, .5, .25>
  direction <1.5,0,0>
  up z
  right <0, -(image_width/image_height), 0>
  sky z
  look_at 0
}

sphere{0, .1 pigment { colour rgb<.5, .5, .5> }}

light_source{<10, -5, 5>, 1}

The image displayed as it renders is OK, but when I look at the resultant 
file in any graphics program (even IE) it is FAR too bright. This only seems 
to happen if +Fn is selected. I tested +Fs, +Fc and +Fn. These other output 
formats don't seem to be effected.

I am using version 3.7.0.beta.18.msvc-sse2.win32, on a PentiumD 620 machine 
running WinXP Pro SP2.

Rarius

Post a reply to this message

Gamma, gamma, gamma... Each time I read something about gamma, it's
a problem with it. It seems to me that gamma only causes problems and
doesn't actually solve any. There are tons and tons of graphical
software out there which do just *fine* without any gamma at all to
worry about.

  How about if we dropped everything related to gamma from povray?
Who needs it anyways? It just fumbles things up and makes people
struggle because they can't get what they want.
  What is the most common thing people use assumed_gamma for in
povray 3.6? Trying to get rid of it! That's what.

  Ok, I apologize for the ranting.

-- 
                                                          - Warp

Post a reply to this message

I should have remembered the assumed_gamma issue before posting this... but 
on the other hand, why does this only cause a problem for the PNG output but 
not the BMP or TGA? And why does the render window look OK while the file 
doesn't?

Personally I've never understood the need for Gamma adjustment within 
POVRay... I'd second any motion for ripping it out!

Rarius


"Warp" <war### [at] tagpovrayorg> wrote in message 
news:45aab39c@news.povray.org...
>  Gamma, gamma, gamma... Each time I read something about gamma, it's
> a problem with it. It seems to me that gamma only causes problems and
> doesn't actually solve any. There are tons and tons of graphical
> software out there which do just *fine* without any gamma at all to
> worry about.
>
>  How about if we dropped everything related to gamma from povray?
> Who needs it anyways? It just fumbles things up and makes people
> struggle because they can't get what they want.
>  What is the most common thing people use assumed_gamma for in
> povray 3.6? Trying to get rid of it! That's what.
>
>  Ok, I apologize for the ranting.
>
> -- 
>                                                          - Warp

Post a reply to this message

"Rarius" <rar### [at] rariuscouk> schreef in bericht 
news:45aabf86$1@news.povray.org...
>I should have remembered the assumed_gamma issue before posting this... but 
>on the other hand, why does this only cause a problem for the PNG output 
>but not the BMP or TGA? And why does the render window look OK while the 
>file doesn't?
>
> Personally I've never understood the need for Gamma adjustment within 
> POVRay... I'd second any motion for ripping it out!
>

I agree with both of you :-)

I have/had the same problem with the png output, but only when looking at it 
in WinEx. In any other paint program it looks alright. What seems to solve 
that, is to open it in a paint program (PSP for instance) and just 
save/overwrite it.
I have not experimented with bmp or tga, though.

Thoma

Post a reply to this message

"Rarius" <rar### [at] rariuscouk> wrote:
> I should have remembered the assumed_gamma issue before posting this... but
> on the other hand, why does this only cause a problem for the PNG output but
> not the BMP or TGA? And why does the render window look OK while the file
> doesn't?
>
> Personally I've never understood the need for Gamma adjustment within
> POVRay... I'd second any motion for ripping it out!
>
> Rarius
>
>
> "Warp" <war### [at] tagpovrayorg> wrote in message
> news:45aab39c@news.povray.org...
> >  Gamma, gamma, gamma... Each time I read something about gamma, it's
> > a problem with it. It seems to me that gamma only causes problems and
> > doesn't actually solve any. There are tons and tons of graphical
> > software out there which do just *fine* without any gamma at all to
> > worry about.
> >
> >  How about if we dropped everything related to gamma from povray?
> > Who needs it anyways? It just fumbles things up and makes people
> > struggle because they can't get what they want.
> >  What is the most common thing people use assumed_gamma for in
> > povray 3.6? Trying to get rid of it! That's what.
> >
> >  Ok, I apologize for the ranting.
> >
> > --
> >                                                          - Warp

Don’t apologise it’s a valid point. Which I agree with, gamma is more
trouble than it is worth

Stephen

Post a reply to this message

Warp wrote:
>   Gamma, gamma, gamma... Each time I read something about gamma, it's
> a problem with it. It seems to me that gamma only causes problems and
> doesn't actually solve any. There are tons and tons of graphical
> software out there which do just *fine* without any gamma at all to
> worry about.
> 
>   How about if we dropped everything related to gamma from povray?

Why? It works, it is just that people need to read the release notes stating
how to use it in 3.7 to get 3.6 results and also complain to those programs
that do not support PNG properly. The reason you hear complains it because
(surprise), M$ has, I would guess intentionally, never supported PNG
properly. But as M$ dominates the market, those not understanding how M$
handles standards it dislikes fall for the trap and blame POV-Ray. Of
course, the question then arises why the same people insist on using PNG in
the first place - my motto in this regard is: Either know what you are
doing, or don't do it :-(

In short, there is no problem at all. POV-Ray functions properly, and the
feature is trivial to turn off by reading the documentation as well.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Why?

  I will respond to that question with another question: Can you tell me
any reason why people using povray would want gamma information to be
stored in the png file (especially considering that it's *not* stored
in any other image format supported by povray)?

  By far the most common situation is that people using povray expect
exact pixel color values which correspond to the color vectors they
have used in the scene. For example, if someone makes an object of
color <.5, .5, .5> and removes all lighting/shading effects (usually
by specifying "ambient 1"), they expect to get an image where the
pixel values (assuming 8-bit color channels) are 128, 128, 128, or
perhaps 127, 127, 127, but nothing else.

  When instead they get something like 135, 135, 135, they get confused
because they are not getting what they expect nor want. If they, for
whatever reason, relied on povray giving them exactly half-bright
pixels, getting 135*3 is useless to them.

  Another issue is that getting *different* pixel results when rendering
to png as compared to rendering to another image format is going to only
cause even more confusion. Shouldn't povray give consistent results
regardless of the image format used?

  Gamma information exists in OSes so that images will look approximately
the same as in other systems. However, this is an issue if image viewer
programs (and to some extent image editors). In other words, an image
viewer gets an image with "raw" pixels, and then it gamma-corrects them
to look good on the specific platform. In other words, this correction
is a duty of the viewer program (or the OS itself).

  Povray, however, *creates* the image file. It's not an image viewer.
Putting gamma correction in povray is putting it in the wrong end of
the pipeline. The gamma correction should be at the end of the pipeline
(the viewer program), not the beginning (the program that creates the
image, in this case povray). Using gamma correction in *both* ends will
only cause an incorrect result.

  In the past (at least with pov3.5) people have abused povray's gamma
correction for something completely different than what it was really
intended for: They have used it as a kind of post-process filter to
alter the brightness of the resulting image. This is obviously the
completely wrong usage, and if post-processing of individual pixels
(for example to brighten them) is desired, there should exist a tool
in povray specialized to do exactly that. Using gamma correction as
a hack for this is not the correct way.

  If this was done, the need for gamma correction actually completely
disappears. Why would anyone need gamma correction in povray anymore?
As I already wrote, gamma correction is a duty of the viewer program
(or the OS), not the program which creates the raw image.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Gamma information exists in OSes so that images will look approximately
> the same as in other systems. However, this is an issue if image viewer
> programs (and to some extent image editors). In other words, an image
> viewer gets an image with "raw" pixels, and then it gamma-corrects them
> to look good on the specific platform. In other words, this correction
> is a duty of the viewer program (or the OS itself).

Yes, exactly! And if you refer back to the original post you will see
exactly that problem taking place - POV-Ray is a viewer of images! It shows
you the preview, and the original poster complained that his viewer program
does not handle gamma correctly. POV-Ray as viewer does. Now it writes the
image correctly, with the information needed to recreate exactly its
preview. But the outside viewer program ignores what POV-Ray included in the
image.

>   In the past (at least with pov3.5) people have abused povray's gamma
> correction for something completely different than what it was really
> intended for: They have used it as a kind of post-process filter to
> alter the brightness of the resulting image.

Yes, because one could manipulate "gamma" from within the scene. This was
the actual flaw. Gamma is something you set *once* for your system and then
forget about. Assuming all programs you use support it, everything will be
fine. That is why in 3.7 gamma changing from within the scene is deprecated,
and will be no longer possible in whatever release comes after it. Setting
in once in povray.ini/.rc will do.

	Thorsten

Post a reply to this message

"Rarius" <rar### [at] rariuscouk> wrote:
> I should have remembered the assumed_gamma issue before posting this... but
> on the other hand, why does this only cause a problem for the PNG output but
> not the BMP or TGA? And why does the render window look OK while the file
> doesn't?

Because PNG stores a gamma setting and certain viewers use it.  I usually
render in PNG and convert to JPG.  When I open the PNG in the basic Windows
Picture and Fax Viewer or Picasa, it is bright (ie uses the internal gamma
setting), but in Microsoft Photo Editor, it isn't (doesn't use the
setting).  I would suspect that the POV preview displays without the gamma.
 And remember, there are 2 gamma settings, Display_gamma in the ini and
assumed_gamma in the scene file.

Personally, I can never get it to work right (or at least the way I want it
to work)

-tgq

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Yes, exactly! And if you refer back to the original post you will see
> exactly that problem taking place - POV-Ray is a viewer of images! It shows
> you the preview, and the original poster complained that his viewer program
> does not handle gamma correctly. POV-Ray as viewer does. Now it writes the
> image correctly, with the information needed to recreate exactly its
> preview. But the outside viewer program ignores what POV-Ray included in the
> image.

  Then why do all other image formats look the same with the viewer
programs as how povray shows them? Why is PNG the only format that
makes a difference? Why can't povray create the PNG in the same way
as it creates the other, non-problematic image formats (IOW. without
gamma info stored in it)?

  Why does the PNG need the gamma info? The other formats don't, and
they work just ok. PNG is the only one which presents problems when
the gamma info *is* included. How about not including it at all?

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   Then why do all other image formats look the same with the viewer
> programs as how povray shows them?

For TIFF it is a missing feature (in POV-Ray) that gamma settings are not
written to file. The other formats are just so old they don't support it.

	Thorsten

Post a reply to this message

Warp wrote:
> 
>   Then why do all other image formats look the same with the viewer
> programs as how povray shows them? Why is PNG the only format that
> makes a difference? Why can't povray create the PNG in the same way
> as it creates the other, non-problematic image formats (IOW. without
> gamma info stored in it)?
> 
>   Why does the PNG need the gamma info? The other formats don't, and
> they work just ok. PNG is the only one which presents problems when
> the gamma info *is* included. How about not including it at all?
> 

After reading a fair bit about gamma on the web during the years I think 
I have a good grasp of it and can answer some questions.

First answering Warp:

If you create an image in windows (gamma 2.2) and save it as JPEG and 
PNG and send whose to your friend who owns a mac (gamma 1.8) the JPEG 
will look wrong while the PNG will look exactly as you intended (thanks 
to the stored gamma info). This assumes that both systems use programs 
that use gamma information as they should and that both system are 
configured correctly.

More general discussion about gamma:

Gamma is a way to compensate for the non-linearity of the monitor (due 
to the properties of the phosphor and electron gun). To get black you 
output the value 0.0 (0) and to get white you output 1.0 (255), so far 
so good. But to get something which look like 50% gray you don't output 
0.5 (128), you output 0.73 (187) which is 0.5^(1/2.2), that is the gamma 
correction. The non-linear transfer function of the monitor is
  brightness = value ^ 2.2
and that takes the value 0.73 back to 50% gray as expected.
The above paragraph assumes gamma 2.2.

To make the whole thing more complicated, calculations on color values 
(such as ray-tracing, filtering, image transformation with 
anti-aliasing) should be done in linear color space (gamma 1.0) or 
errors such as hue shifts will occur. That is why povray uses gamma 1.0 
in all calculation and does the correction when it saves the image to a 
file (or rather, I hope that's what 3.7 does, I does right?).

To see why calculations should be done in gamma 1.0 consider the task of 
averaging two pixels, one black and one white, in a gamma 2.2 color space:
  (0.0 + 1.0) / 2 = 0.5
If you just send this to the monitor you get a pixel that looks 22% gray 
(0.5^2.2) and not 50% gray as you would expect. If the pixels are 
colored it gets even worse, say one medium red (50% red) and one yellow 
(100% red and green):
  50% red in gamma 2.2 is 0.73
  red:   (0.73 + 1.0) / 2 = 0.86
  green: (0.0 + 1.0) / 2 = 0.5
  blue:  (0.0 + 0.0) / 2 = 0.0
If you send that to the monitor it will look like 73% red, 22% green, 0% 
blue. The expected values are 75% red, 50% green, 0% blue. The gamma 2.2 
calculation yields a too dark color with a hue that is too much red.

In short:
For correctly configured systems, do calculation in gamma 1.0 and save 
with any gamma in a file format that store the gamma (such as PNG). This 
will always look as intended as long as the viewing program uses the 
gamma information (this is how it should be in a perfect world).
For systems that may have programs that don't do gamma right, do 
calculation in gamma 1.0 and save with the gamma of your target audience 
in a format that *don't* store gamma. This will look right only if the 
user viewing the image has a system with the gamma you used else it will 
look wrong.

I hope this was understandable and that it answered a few question 
people have about gamma.

-- 
Daniel Nilsson

Post a reply to this message

Daniel Nilsson <pov### [at] daniel-nilssoncom> wrote:
> If you create an image in windows (gamma 2.2) and save it as JPEG and 
> PNG and send whose to your friend who owns a mac (gamma 1.8) the JPEG 
> will look wrong while the PNG will look exactly as you intended (thanks 
> to the stored gamma info). This assumes that both systems use programs 
> that use gamma information as they should and that both system are 
> configured correctly.

  I know the theory. The problem is that in practice gamma correction
only causes more problems than it's worth.

  There's only one thing for which PNG is criticized by the industry
as a whole, and it's related to... surprise surprise, gamma correction.

  Gamma correction in PNG causes lots of problems. For instance, if
you want to make a web page with a certain backtround color and add
a PNG image which uses that exact same color, you can blame gamma
correction for the fact that often you won't. While you can do that
with any other image format, and the image will match the background
color in the web page perfect, with PNG it often won't. It depends on
the browser. Some browsers read the gamma correction, others don't.
If there's no gamma correction, some browsers will guess a gamma
correction (screwing up the colors) while others will take the pixels
unmodified.
  Other image formats simply don't have these problems. If you use
a certain color in a gif or jpg or whatever, you will get that certain
color, and it will perfectly match the same color used in the background
of the web page. With png you might or might not get the color you want.
In one browser it may look good, in another it may not.

  The PNG standardization organization screwed up. They gave unwise
rules on what to do when a png file has no gamma information. Some
programs follow this rule, others don't. What is worse, if there *is*
gamma info, some programs will read it, others won't. Thus you might
get even 4 different results depending on the gamma info and the
program.

  In my personal experience the least problematic course of action is
to not to include any gamma info in the png file. While that will not
guarantee anything (some programs may start "guessing" a gamma info
for it even if you don't want it to), I think most programs will then
just take the pixels as they are, in the same way is with any other
image format.

-- 
                                                          - Warp

Post a reply to this message

[Followup-To set to povray.general as this isn't really about the 3.7 
beta anymore]

Take this as my vision of a future, prefect, gamma corrected world and 
not so much of a solution for today's gamma problems ;)

Warp wrote:
>   Gamma correction in PNG causes lots of problems. For instance, if
> you want to make a web page with a certain backtround color and add
> a PNG image which uses that exact same color, you can blame gamma
> correction for the fact that often you won't. While you can do that
> with any other image format, and the image will match the background
> color in the web page perfect, with PNG it often won't. It depends on
> the browser. Some browsers read the gamma correction, others don't.
> If there's no gamma correction, some browsers will guess a gamma
> correction (screwing up the colors) while others will take the pixels
> unmodified.

This may be true, I have not experienced it myself, though. In theory I 
don't think it should be a problem if browsers implemented gamma 
correction correctly. What I mean by that is that they should correct 
both images and colors specified in css (assuming they are specified in 
sRBG I guess, which seem to be the de facto standard). In practice 
browsers don't do this of course and and I doubt that css (or any other 
w3 standard) defines any gamma correction, so they probably never will.
You still need embedded gamma information (or standardized gamma) if you 
want an image to look the same regardless of the target system's gamma. 
I believe that is an important thing for CG-art.

>   Other image formats simply don't have these problems. If you use
> a certain color in a gif or jpg or whatever, you will get that certain
> color, and it will perfectly match the same color used in the background
> of the web page. With png you might or might not get the color you want.
> In one browser it may look good, in another it may not.

With gif (or others) you get the pixel value you want, with png (with 
embedded gamma) you get the perceived color you want. In web pages the 
former is more important (because browsers don't gamma correct css 
colors) and when showing the image to others the way it's supposed to 
look the latter is more important. It all depends on what the image's 
purpose is.

>   The PNG standardization organization screwed up. They gave unwise
> rules on what to do when a png file has no gamma information. Some
> programs follow this rule, others don't. What is worse, if there *is*
> gamma info, some programs will read it, others won't. Thus you might
> get even 4 different results depending on the gamma info and the
> program.

(I have not studied the PNG-standard closely so IIUC...)
Fact remains that if all programs followed the standard's rules 
regarding gamma (unwise or not), any given png-image would look the same 
regardless of the target system. As I see it the problem is that 
programs don't follow the standard. In practice you can't (easily, if at 
all) fix the programs so you have to find some workaround. I don't have 
any solution but it is not a good idea to remove gamma support from 
programs that have it (e.g. povray).

>   In my personal experience the least problematic course of action is
> to not to include any gamma info in the png file. While that will not
> guarantee anything (some programs may start "guessing" a gamma info
> for it even if you don't want it to), I think most programs will then
> just take the pixels as they are, in the same way is with any other
> image format.

As you can see from my posts I am sort of a fan of gamma correction, but 
I'm more of a theoretical guy, not doing much raytracing and image 
related work right now. I once started writing my own raytracer and that 
was when I encountered gamma first. After reading many articles on the 
web I understand how it works and why it is needed. I think it's a 
necessary evil, in a perfect world we would only use gamma 1.0 with 
floating point values. It's non-linear hardware and the limited dynamic 
range of 8-bit values that force us to use gamma correction and the fact 
that different manufacturers chose different factors that make it a 
PITA, IMHO.

--
Daniel Nilsson

Post a reply to this message

[Followed Daniel, by setting follow-ups to .general]

Warp wrote:
>   Gamma correction in PNG causes lots of problems. For instance, if
> you want to make a web page with a certain backtround color and add
> a PNG image which uses that exact same color, you can blame gamma
> correction for the fact that often you won't. 

Possibly surprisingly that's handness of the web developer. PNG supports
transparency, so there actually should be no real need to get the same
background color as at the page.

Fortunately for you JPG's are usually far more practical on the web,
while they take up less space.

> If there's no gamma correction, some browsers will guess a gamma
> correction (screwing up the colors) while others will take the pixels
> unmodified.

I quickly checked the PNG specs and seems the specified way is to guess
the gamma. I'm not sure if it's a good idea.

> In one browser it may look good, in another it may not.

That's pretty common on webpages these days. :(

>   The PNG standardization organization screwed up. They gave unwise
> rules on what to do when a png file has no gamma information. 

Yes, but...

> Some programs follow this rule, others don't. 

...it's still specsed, so every program should follow the rule. The
final colors would vary less.

> What is worse, if there *is* gamma info, some programs will read it, others won't. 

This certainly is no PNG standardization group's fault, some programs
just act wrong.

> Thus you might
> get even 4 different results depending on the gamma info and the
> program.

No, there's 3 choices, since not reading the gamma info and missing the
gamma info should result the same:

1) Gamma is correct (gamma is presented and used)
2) Gamma is guessed (gamma is missing or hasn't been checked)
3) Gamma is forgotten (gamma is missing or hasn't been checked)

-- 
Eero "Aero" Ahonen
   http://www.zbxt.net
      aer### [at] removethiszbxtnetinvalid

Post a reply to this message

In article <45abea7f@news.povray.org>, war### [at] tagpovrayorg says...
>   In my personal experience the least problematic course of action is
> to not to include any gamma info in the png file. While that will not
> guarantee anything (some programs may start "guessing" a gamma info
> for it even if you don't want it to), I think most programs will then
> just take the pixels as they are, in the same way is with any other
> image format.
> 
Actually.. A real good, if only slightly related, issue that can 
demonstrate the problem is games like Myst. This is where the, "looks as 
it should, not the color I said", issue becomes a *major* issue. Myst 
was originally made on the Mac, it was then ported to Windows. Due to 
the way the displays handled color, the only way to **see** every detail 
was to either increase the graphics card gamma (not available at the 
time) **or** increase the brightness of the display. Its even part of 
the standard install for some such games that you have a "settings" 
page, where you adjust the brightness up to compensate for the fact that 
the displays default, which looks good for ***Everything else***, will 
show all the color detail for the game. Gamma on the card works to, but 
can be useless, depending on how the card does it, because some cards 
don't increase the outputs, they just bleach the images by increasing 
the color values.

Nearly all games use Gamma now *period*, generally through the card, 
because the system they "started on" didn't use the same display gamma 
as the final machine they end up on. That can be due to everything from 
the type of display, the OS, the graphics card, or just how someone had 
to compensate for a game that didn't use it, do that *that* game would 
appear as intended. And for some like the Myst series, just seeing a 
switch or a critical object in a dark tunnel **requires** that the 
display is accurate to what the production machine used to make them 
are. Now.. For 90% of us, still images are not a problem. We don't do 
dark rooms with lots of subtle details. If a tiny bit gets blured into 
the background, we don't care. But.. There have been cases in 
*professional* business where someone has sent an image in the wrong 
Gamma, only to have the client reject it, because they couldn't *see* 
the details on their system. Gamma is supposed to correct this. If done 
right, its supposed to correct it via hardware, so that colors don't 
bleach in the high end, or blur into the dark areas, for lower intensity 
colors. Unfortunately... Most application don't use hardware gamma, 
so... And the ones that do use Gamma at all get people mad, because they 
don't bother getting the settings right on their end in the first place, 
so the image comes out wrong in the first place.

Imho, two things are really needed to correct this. 1. Proper use of 
Gamma in all applications. 2. Displays that can ID their "current" 
gamma, so that the software can correct for what the display is actually 
showing, not what some tech either a) failed to set correctly, or b) set 
wrong. The closest they have right now is color correction data, like 
for mine, which "assume" that you are using the display in its factory 
defaults for color intensity and that the software is *asking* the OS 
what the color profile is for that display, so that corrections can be 
made, in theory, for not just the brightness, but also for difference in 
actual color values. I have yet to see any example of that happening 
though.

Basically, its a great idea, if people @$$@#$ used it right, the 
hardware was smarter and you could find some way to take idi... people 
out of the equation. lol


-- 
void main () {
  If Schrödingers_cat is alive  
    call functional_code()
  else
    call crash_windows();
}

<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
 
3D Content, and 3D Software at DAZ3D!</A>

Post a reply to this message

Patrick Elliott <sel### [at] rraznet> wrote:
> 2. Displays that can ID their "current" 
> gamma, so that the software can correct for what the display is actually 
> showing

  That's actually a good point. Given that different displays will have
different brightness curves, it seems really odd that the displays don't
tell the computer what this curve is so that the computer can act
accordingly. At most you get a floppy with the monitor which contains
this info and it might, just might, get used by the OS for *something*.
It usually doesn't seem enough, though.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   That's actually a good point. Given that different displays will have
> different brightness curves, it seems really odd that the displays don't
> tell the computer what this curve is so that the computer can act
> accordingly.

Many cheap ones won't, but they actually could, via DDC, which by far most
displays do support. Slightly more expensive displays do offer gamma control
in conjunction with graphics cards this way.

	Thorsten

Post a reply to this message

I'd just like to add my input to this discussion and say that POV-Ray, 
in correctly following the spec, is doing what it should.  Rather than 
make POV adjust for bad programs, we should complain to the authors of 
those other programs...

...Chambers

Post a reply to this message

Ben Chambers <ben### [at] pacificwebguycom> wrote:
> I'd just like to add my input to this discussion and say that POV-Ray, 
> in correctly following the spec, is doing what it should.  Rather than 
> make POV adjust for bad programs, we should complain to the authors of 
> those other programs...

  But that doesn't help too much, does it?

  IMO there should be at least a way to turn gamma correction completely
off in POV-Ray.
  After all, sometimes people might want *exact* pixel values in the
resulting image file. Not everything people do with POV-Ray is photographic
in nature.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Ben Chambers <ben### [at] pacificwebguycom> wrote:
>> I'd just like to add my input to this discussion and say that POV-Ray, 
>> in correctly following the spec, is doing what it should.  Rather than 
>> make POV adjust for bad programs, we should complain to the authors of 
>> those other programs...
> 
>   But that doesn't help too much, does it?
> 
>   IMO there should be at least a way to turn gamma correction completely
> off in POV-Ray.

There is, and has been for a long time. RTFM!

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> There is, and has been for a long time. RTFM!

  Will it make POV-Ray not to write any gamma info in the PNG file?

-- 
                                                          - Warp

Post a reply to this message