openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Openexr-devel] Re: LUT for HDR-histograms, too?


From: Simon Green
Subject: RE: [Openexr-devel] Re: LUT for HDR-histograms, too?
Date: Mon, 26 Jan 2004 17:08:08 -0800

Yeah, it's actually pretty hard to do histogram-like operations using
current graphics hardware. OpenGL has an optional imaging subset which
includes histograms, but no mainstream vendors hardware accelerate this as
far as I know, and certainly not for floating point images.

The problem is that pixel shaders operate on each pixel independently, and
there is no persistent global storage between pixels.

However, if you just want the total luminance of an image, it is possible to
implement this recursively, similar to generating mipmaps. Write a shader
that sums 4 neighbouring pixels, and then write out the results to a quad
half the size. Repeat until you have a 1x1 image, which is the final sum.
The GPGPU (http://www.gpgpu.org) crowd call this kind of thing a reduction
operator.

Future hardware will also likely support texture reads in the vertex shader
(see the DirectX 9 spec). This effectively allows recirculating data from
the output of the pixel shader to the input of the vertex shader. You can
imagine implementing a histogram by rendering the image as an array of
points, with the vertex shader moving the position of each point to an
appropriate position in the histogram texture based on its color.

Well, this should give you some ideas for you thesis, anyway!

-Simon.


> > 2) Do you think the same approach (using a 2D-texture as 
> lut indexed by
> > floats) would work with creating a histogram of the 
> HDR-image? As I need
> > some information about the "light sources" of the 
> HDR-Envmap, some sort
> > of image processing (binary/n-ary thresholding) based on the image's
> > histogram has to be performed beforehand...
> 
> 
> Well in the shader I posted, you really want a 1x65k 1D 
> texture for the
> lookup, but because you can't make a texture that large, we 
> use this trick
> of folding it into a 256x256 2D texture and then splitting 
> the half color
> component from the HDR texture into two 8-bit indicies.
> 
> I guess you could render to texture, where the histogram is a 
> 256x256 2D
> texture and the color value in the HDR texture is your index into the
> histogram texture.  Then you need to do a read-modify-write on the
> histogram texture (read, add one, write)... that's the tricky part.
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]