I thought I had the source files for 3.0 here, apparently not. Only the
2.2 version sources. No such word as gamma it seems in those, far as I
could tell. Didn't really expect to find it anyhow, but I thought just
maybe there had been a hidden gamma routine in there none-the-less.
Perhaps I've overlooked it if so.
I understand your meaning better now, the gamma being before anything
else instead of following the actual pixel writing to the image and not
when it is being written (saved).
On the subject of the gamma, wonder what the head count of people would
be that use assumed_gamma 2.2 (or any other number) as default instead
of 1.0 for the basis of corrections?
I've just done several different test renders (single light_source color
rgb 1) using Display_Gamma=1.0, assumed_gamma 2.2 and opposite of this,
also both as 1.0 or 2.2. The appearance changes drastically as you might
guess. Unfortunately to my eyes the render doesn't seem quite right when
used as suggested. Probably because I tend to think in terms of more
than one light since I seldom use only one lone light source and
combining them makes things more difficult to adjust the scene
color/brightness/contrast.
Anyhow, I'm going to give the defaults for my PC here a trial run for a
while and see what comes of it.


"John M. Dlugosz" wrote:
> 
> OK, as I read the code, it's sending out multiple rays for one pixel,
> summing as it goes.  The, it divides by the number of samples, producing the
> average which is the actual result.
> 
> It does gamma correction before summing.
> I would think it should do gamma correction after dividing.
> 
> I've not thought about the meaning of post-corrected pixels above and left
> of the current pixel and its role in adaptive supersampling.  But that might
> be part of the reason for this code.
> 
> Just do a search on "gamma".  You'll find something like 6 hits in a .C
> file, including the
> function which does it, and three places where it's called as part of a
> supersampling process.
> 
> --John
> 
> Bob Hughes wrote in message <36E6E739.D8B637EB@aol.com>...
> >Huh? ;)
> >
> >This kind of thing is what I have trouble with. It's simply a two way
> >street it seems and they always seem to turn out to be one way streets.
> >Metaphoricly typing of course...
> >
> >I think I understand your meaning here, that the gamma is getting done
> >per processed pixel and yet the following pixels are not done so until
> >after they are sampled along with the previous pixels, right? Maybe not
> >right?
> >Anyway, I am thoroughly confused now.
> >
> >
> >"John M. Dlugosz" wrote:
> >>
> >> Isn't manipulation of pixels supposed to be done on a linear scale, i.e.
> >> =before= gamma correction for the monitor?  The comments in the source
> even
> >> say "this is done exactly once per pixel displayed/saved".  But the
> >> supersampling gamma corrects each value individually before averaging
> them
> >> together.  I'm confused as to the meaning here.
> >>
> >> From the docs, it's clear that the intent is for all new scenes to have
> >> "assumed gamma" of 1 ("strongly recomended" it explains, "since that's
> the
> >> way light works in the real world", and this is adjusted for the display
> >> gamma when it is output.
> >>
> >> So shouldn't all manipulation be done on the computed values (in the
> >> assumed_gamma), and then the final pixel value be adjusted once?  Doing
> the
> >> gamma correction first will give different results for different display
> >> gamma values, which is exactly what the docs say is =not= supposed to
> >> happen.
> >>
> >> --John
> >
> >--
> > omniVERSE: beyond the universe
> >  http://members.aol.com/inversez/POVring.htm
> > mailto:inv### [at] aolcom?PoV

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message