BMRT..GAMMA

BMRT..GAMMA

Post by Sam Jorgense » Mon, 21 Oct 1996 04:00:00



Does anyone know where I can adjust the gamma settings in BMRT??
My renders always appear dark at best and black at worst. I would ask
Larry Gritz but I already ask him too many questions :).
My RC book is another 6 weeks down the track because this shithole
called Australia is so far away from the rest of the world!!!!
--
                 "Sam-Michael Myers/Ozzy Osbourne-Jorgensen"
            "Of all the things I've lost I miss my mind the most!"
                            -Ozzy Osbourne-                

                        Here's my stupid homepage
                http://www.nectar.com.au/~mmyers/lordoflight.html

 
 
 

BMRT..GAMMA

Post by Stephen Westi » Tue, 22 Oct 1996 04:00:00



> Does anyone know where I can adjust the gamma settings in BMRT??
> My renders always appear dark at best and black at worst. I would ask
> Larry Gritz but I already ask him too many questions :).
> My RC book is another 6 weeks down the track because this shithole
> called Australia is so far away from the rest of the world!!!!

In RIB, it's Exposure. Calling a library, I'd bet on RIExposure.

# Correct for monitor gamma of 2.2
Exposure 1.0 2.2

Works in any compliant RenderMan implementation, I believe.

--
-Stephen H. Westin

The information and opinions in this message are mine, not Ford's.

 
 
 

BMRT..GAMMA

Post by Larry Gri » Wed, 23 Oct 1996 04:00:00





>> Does anyone know where I can adjust the gamma settings in BMRT??

>In RIB, it's Exposure. Calling a library, I'd bet on RIExposure.

># Correct for monitor gamma of 2.2
>Exposure 1.0 2.2

>Works in any compliant RenderMan implementation, I believe.

Yes, this pre-corrects for a particular display device before quantization.

I do not recommend using Exposure.  The pre-corrected files are a pain
to manipulate via image arithmetic or compositing.  And it's corrected
for a particular display -- it will still appear wrong on somebody
else's monitor.

A better strategy, I think, is to render linear files (i.e. Exposure 1 1)
and correct at *display* time.  Some platforms (like SGI) allow you to
correct your entire lookup table, so it's a no-brainer.  On other
platforms, you may want to instruct your image display program to
correct as it displays.  For example, if you use "xv", you can
specify the gamma using the command line switch -gamma.

        -- lg

--
Larry Gritz

 
 
 

BMRT..GAMMA

Post by Stephen Westi » Wed, 23 Oct 1996 04:00:00



> I do not recommend using Exposure.  The pre-corrected files are a pain
> to manipulate via image arithmetic or compositing.  And it's corrected
> for a particular display -- it will still appear wrong on somebody
> else's monitor.

> A better strategy, I think, is to render linear files (i.e. Exposure 1 1)
> and correct at *display* time.  Some platforms (like SGI) allow you to
> correct your entire lookup table, so it's a no-brainer.  On other
> platforms, you may want to instruct your image display program to
> correct as it displays.  For example, if you use "xv", you can
> specify the gamma using the command line switch -gamma.

I disagree with this. Gamma-correcting 8-bit linear images is a great
way to introduce quantization artifacts at low intensity levels. It's
less convenient to have to de-correct before any image processing, but
more useful information is retained in gamma-corrected images.

For broadcast, there is a standard receiver transfer characteristic,
and images eventually must be corrected for this anyway. My approach
is to pre-correct for 2.2, which is close to the NTSC and HDTV
standards, and to set the display correction to fit that. The display
correction is quite mild in this case: too little to introduce visible
quantization problems.

One way to ameliorate the problem is to dither the image. Instead of
writing the color value to file, you can add noise so that the mean
output value over the local area will be the "correct" value. If done
properly, this can make quantization bands disappear. Maybe prman and
BMRT do this.

--
-Stephen H. Westin

The information and opinions in this message are mine, not Ford's.

 
 
 

BMRT..GAMMA

Post by Larry Gri » Wed, 23 Oct 1996 04:00:00





>> A better strategy, I think, is to render linear files (i.e. Exposure 1 1)
>> and correct at *display* time.

>I disagree with this. Gamma-correcting 8-bit linear images is a great
>way to introduce quantization artifacts at low intensity levels.

In the case where there's lots of detail that must be preserved in the
dark color ranges, one should be rendering deeper than 8 bits.

Quote:>One way to ameliorate the problem is to dither the image. Instead of
>writing the color value to file, you can add noise so that the mean
>output value over the local area will be the "correct" value. If done
>properly, this can make quantization bands disappear. Maybe prman and
>BMRT do this.

Not only do they both do this, it is required by the RenderMan standard.
c.f. RiQuantize for ways to control channel bit depth as well as
dither amount.

        -- lg

--
Larry Gritz

 
 
 

BMRT..GAMMA

Post by Paul Bruggema » Thu, 24 Oct 1996 04:00:00





[snip]

Quote:> > A better strategy, I think, is to render linear files (i.e. Exposure 1 1)
> > and correct at *display* time.  Some platforms (like SGI) allow you to
> > correct your entire lookup table, so it's a no-brainer.  On other
> > platforms, you may want to instruct your image display program to
> > correct as it displays.  For example, if you use "xv", you can
> > specify the gamma using the command line switch -gamma.

> I disagree with this. Gamma-correcting 8-bit linear images is a great
> way to introduce quantization artifacts at low intensity levels. It's
> less convenient to have to de-correct before any image processing, but
> more useful information is retained in gamma-corrected images.

[snip]
 I am curious about this. Images directly from the DDR (abekas/diskus)
appear to be captured at gamma 1.0 (displayed on a SGI FB/monitor set at
1.0). The input to the DDR is set up to bars (using a waveform monitor),
the NTSC monitor is setup to grey scale bars (and chroma to "blue
only"). My other experience is with a old Videopak/videoframer, which
also used a gamma of 1.0.
 The only thing I can figure is that the software is constantly fooling
with the image by darkening it (during render) and then the 2.2 setup
of the SGI frame buffer looks fine. The only problem is you have to
gamma warp your texture maps to the 2.2 region before using them. (this
appears to be what wavefronts old renderer does)
 anyway, gamma 1 works for me,
  paul

> --
> -Stephen H. Westin

> The information and opinions in this message are mine, not Ford's.

 
 
 

BMRT..GAMMA

Post by Stephen Westi » Fri, 25 Oct 1996 04:00:00



> > > A better strategy, I think, is to render linear files (i.e. Exposure 1 1)
> > > and correct at *display* time.  Some platforms (like SGI) allow you to
> > > correct your entire lookup table, so it's a no-brainer.  On other
> > > platforms, you may want to instruct your image display program to
> > > correct as it displays.  For example, if you use "xv", you can
> > > specify the gamma using the command line switch -gamma.

> > I disagree with this. Gamma-correcting 8-bit linear images is a great
> > way to introduce quantization artifacts at low intensity levels. It's
> > less convenient to have to de-correct before any image processing, but
> > more useful information is retained in gamma-corrected images.

> [snip]
>  I am curious about this. Images directly from the DDR (abekas/diskus)
> appear to be captured at gamma 1.0 (displayed on a SGI FB/monitor set at
> 1.0). The input to the DDR is set up to bars (using a waveform monitor),
> the NTSC monitor is setup to grey scale bars (and chroma to "blue
> only"). My other experience is with a old Videopak/videoframer, which
> also used a gamma of 1.0.

Broadcast video is, by standard, gamma-corrected. So when a DDR
captures video, it need not do anything to a pre-corrected digital
image. This is one reason why digital video can get away with 8 bits
per color; the nonlinearity effectively concentrates more levels at
low luminance, where you need them. My approach, gamma-correcting
while writing the image file, parallels this process.

Quote:>  The only thing I can figure is that the software is constantly fooling
> with the image by darkening it (during render) and then the 2.2 setup
> of the SGI frame buffer looks fine.

No, the video going into your DDR has been gamma-corrected by
circuitry in the camera. If you don't do anything to the output of
your renderer, it will look dark; gamma correction parallels what has
already happened to live video.

Quote:> The only problem is you have to
> gamma warp your texture maps to the 2.2 region before using them. (this
> appears to be what wavefronts old renderer does)
>  anyway, gamma 1 works for me,
>   paul

You have to gammawarp texture maps on the way into the renderer
because if they look right on your screen, they have already been
corrected. Running them through the renderer and then correcting again
makes them look washed out.

If you normally render and display with no gamma correction, I bet
your ambient and fill lights are pretty bright to try to compensate.
It's a common practice, but not a good one.
--
-Stephen H. Westin

The information and opinions in this message are mine, not Ford's.

 
 
 

1. Monitor Gamma and Picture Gamma

There has been much discussion about Gamma on this list lately, a
topic of some confusion because there is Monitor Gamma and Picture
Gamma, and the two are not the same.

Theoretically, a perfect monitor could be built, where pure red shows
as pure red, pure green as pure green, etc.; however, because the
components that are used to build electronic equipment are highly
inaccurate, a perfect monitor is only theoretical.

The actual values of resistors, capacitors, and coils that go into a
piece of electronics vary greatly from their stated values. For
example, a higher-grade 3,000 ohm resistor can vary in value from
2,850 to 3,150 ohms. Standard resistors have a 10% tolerance. The
value of a capacitor can vary from +50% to -20% of its rated value.
Then there are factors such as stray capacitance, wire resistiance,
and inductance caused by the current to contend with.

So, while the design engineer says this circuit will do this, the
resultant application of that design might not, and they add variable
components to allow "tweaking". Instead of having a 3,000 ohm resistor
in some part of the circuit, they might use a 2,500 ohm one along with
an adjustable 250 to 750 ohm one.

The whole point of this is that your monitor is not going to be
perfect, even when it is new, and as it ages, the values of its
components (especially capacitors) will change.

Adjusting your monitor gamma is a way of tweaking it so pure red show
as pure red, etc. It also is used to establish a uniform grayscale.
This can be done completely independently of your graphics program,
and needs to be repeated periodically to compensate to component
aging.

On the other hand, if you use a program like Paint Shop Pro to adjust
the gamma value of a picture, you actually change the palette values
of that picture. One way to see this is to compare the palettes of a
picture at different gamma value adjustments (double-click on the
foreground or background color box or actually open the Jasc-format
palettes in a text editor).

Calibrating the gamma of your monitor just changes the way you view
pictures, not someone else's view. It's becoming the norm for PC
monitors to include gamma adjustment (I believe that it has been built
into Macs for some time, and UNIX). A good package will allow you to
set the values for red, green, and blue independently, along with
grayscale. If your monitor does not include this capability, then I
would search out one of the web sites that have been set up to handle
this, and not foing it from within a paint program.

I have found that I get a good match between my scanner, my printer,
and my monitor since I did the calibration.

Adjusting the gamma value of a picture can be useful for "tweaking"
its appearance, but remember that you are actually changing the colors
when you do so.

co

------------------------------------------------
NOTE: any e-mail sent to the originating address
is automatically deleted without being read.
------------------------------------------------

2. HP 870Cxi vs Epson Stylus 800, PowerMac G3 question.

3. Gamma Gamma Hey Hey

4. Images from DOS text files.

5. Gamma mia, here we go again, Gamma...

6. Vectors don't update after changes

7. BMRT NT VS. BMRT LINUX: Which is faster?

8. BMRT radiosity, BMRT MTOR Shaders?

9. MaxMan (BMRT only version) and BMRT

10. Gamma correction: O = pow(I,gamma) or O = pow(I,1/gamma)?

11. Need Gamma Advice- Is This Gamma Java Applet Accurate?