Bob Hughes wrote in message <36E77592.D8E028ED@aol.com>...

>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).

Actually, gamma correction is done before saving -- the output file contains
pixels corrected to Display_Gamma.

>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?

Everyone who didn't read the manual.

>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.

Because (1)you are used to that, and (2)all the textures you know and love
were designed that way.


>Anyhow, I'm going to give the defaults for my PC here a trial run for a
>while and see what comes of it.


Likewise.  I need to redo the scene to have it look right with gamma=1.0,
but the benifit will be portability of the file (specifically, to service
bureu that prints it on an IRIS), and use of tools that use ICC color
profiles.

If wose comes to worse, take the resulting file and post-process it to
Display_Gamma, and it will be just like it would have been, barring roundoff
errors (not a problem with 16 bits per sample).

I'll update my writeup as more develops.  Let me know what comes of it for
you.

--John

Post a reply to this message