Sticky converter...

Thant Tessman thant at horus.sgi.com
Fri Jun 9 01:56:38 AEST 1989


In article <8906070946.aa00999 at SMOKE.BRL.MIL>, swenson at NUSC-WPN.ARPA writes:
> G'day,
> 
> 	Here is a puzzler...
> 
> 	I was doing some ray-tracing on a 60T when one morning I came
> in and displayed an image that I had traced the day before.  There were
> pixels (usually forming some pattern) that were corrupted.  I naturally thought
> that something was wrong in my ray-tracer...I looked and looked and everything
> seemed to be in order.  For grins, I redisplayed the image and the corrupt 
> parts were gone.  After much thinking, I wrote a short program to display
> a grey-ramp in RGB mode.  Well what to my wondering eyes should appear
> but a little red line where RGB value (156, 156, 156) should have been.
> Evidently, my Iris goes to the Bahamas every now and then and forgets to 
> fire its blue and green guns when 156 is in the bit planes.  Curious.
> 	SGI says its the D/A's getting stuck (I hate when that happens).
> I would be interested to know if anyone else has suffered from sticky
> D/A's.
> 
> 				Steve Swenson
> 				SWENSON at NUSC-WPN.ARPA
> ------


The old graphics (after the 3000's but before GT) uses a gamma ramp that takes
up the top 256 entries of the color ramp.  (It is actually three gamma ramps,
R, G, and B.)  Anything that uses RGB will actually do a lookup in this table
for the ammount of red, green, or blue to use.

They normally contain (0, 0, 0) to (255, 255, 255).  If one of those entries
got messed with (such as the 156'th) everything that used that brightness
would be something other than the number stored in the bitplanes.

The 'showmap', 'cedit', 'interp', and 'gamma' tools can be used to alter
these.  I used to have a lot of fun messing with RGB pictures using the 
gamma tables.

thant at sgi.com



More information about the Comp.sys.sgi mailing list