Re: Hardware questions...

New Message Reply Date view Thread view Subject view Author view

Javier Castellar (javier++at++sixty.asd.sgi.com)
Thu, 30 Jan 1997 18:50:19 -0800

For auto gain, one good way is to page the frame buffer into texture memory and
then render it back onto a 2D polygon using TLUTs (Texture Look Up Tables).
Both OpenGL and Performer support direct framebuffer to texture paging (also
named as texture copy).

In the TLUT you can apply whatever is the transfer function that you whish to
achieve in funtion of the "main brightness" of the previous frames.

The TLUT has no performance penalty.

-Javier

On Jan 30, 4:34pm, Jeff Clark wrote:
> Subject: Hardware questions...
>
> Hello all,
>
> I am having difficulty implementing an "automatic gain control" for my
> Performer app. By AGC, I mean the gain on each pixel is a function
> of the average pixel value (intensity... one color component) of the
> current frame (or previous frame, Ill take what I can get). The correct
> result would be constant overall brightness on the display.
>
> I have implemented this in a handful of ways, but all of my attempts EITHER
> make it impossible to maintain my target frame rate OR don't provide
> an adequate AGC performance (I would like an AGC update rate of ~15Hz).
>
> There are two issues involved... here they are along with my attempted
> solutions:
>
> -Come up with an accurate (or approximate) average pixel value at ~15Hz:
>
> -approximate average pixel value using an ogl MINMAX histogram. This
> is fast, but the approximation is unsatisfactory.
>
> -approximate average pixel value by reading a slice of the framebuffer
> (glReadPixels()) every frame. i.e. if I read 32 lines/frame, I read
> the entire FB every 32 frames. So what I have is an "idea" of the
> brightness of the entire scene over the last 32 frames. This introduces
> temporal inaccuracies that are probably unacceptable. This actually
> looks pretty good a lot of the time, but sometimes not...i.e. in the
> worst case a bright source moves into the scene and has no effect on
> the AGC until 31 frames later. At 60 fps, this is an effective AGC
> update of 2 Hz... unacceptable.
>
> -approximate average pixel value using an ogl MINMAX histogram of one
> color component. The penalty to the draw process is comparable to
> using glReadPixels() and, therefore would be done in slices. Now
> I have the same problem as in the last attempt.
>
> -Apply a gain to the entire display based on the result of the first task
> above:
>
> -accumulate the 1 million pixels in the accumulation buffer and set the
> acbuf gain to the desired gain. This, of course, works fine but takes
> up so much draw that I don't have enough time to draw my scene at the
> complexity my simulation requires.
>
>
> SO, anybody have any ideas? (in the context of a 2 pipe iR with Sirius
option)
>
> I am starting to think of ways to do it near the end or after the pipeline:
>
> On the gain issue, I wonder if there is a way to apply a gain (analog or
> digital) in the DG... i.e. near the DAC or gamma tables? In the ircombine
> channel attributes window I notice a GAIN field... is this a user register
> that can be changed at 15 Hz? (ASD, if this doesn't exist it sure would be
> a groovy thing to have!) Or, could the Sirius box apply a gain offline
> (and do so quickly) (sorry, I'm Siriusly ignorant)?
>
> On the pixel averaging issue, I wonder again if the Sirius can't be used?
>
> If not Sirius, I would think it would be posible to find a specialized
> hardware box that performs my AGC... i.e. a box that takes analog video
> and outputs a signal with constant overall brightness. Anybody ever heard
> of such a gizmo?
>
> Apologies:
>
> Im sorry that these aren't -exactly- Performer questions, but they are SGI
> questions... and this list is the best resource I know of. Besides, it is
> difficult to get this kind of info from support.
> Im sorry that this post is long enough to cut into your lunch break!
>
>
> Any responses will be GREATLY appreciated... I'm am beginning to run out of
> ideas.
>
>
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Jeff Clark

-- 
*************************************************************************
* Javier Castellar Arribas          * Email:         javier++at++asd.sgi.com *                 
*                                   * Vmail:            	 3-1589 *            
* Member of Technical Staff         * Phone:  415-933-1589 / 2108 (lab) *
* Core Design - Applied Engineering * Fax:                 415-964-8671 *     
* Advanced Systems Division         * MailStop:                  8L-800 *
************************************************************************* 
* Silicon Graphics Inc.                                                 *
* 2011 N. Shoreline Boulevard,                                          *                        
* Mountain View, California 94043-1386, USA                             *
*************************************************************************
"Violence is the last refuge of the incompetent"
						Hardin Seldon
=======================================================================
List Archives, FAQ, FTP:  http://www.sgi.com/Technology/Performer/
            Submissions:  info-performer++at++sgi.com
        Admin. requests:  info-performer-request++at++sgi.com

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:30 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.