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


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