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

[Matthias Biedermann]

Well - that doesn't sounds very promising...

As this evaluation of the HDR-Envmap is just a preprocess (done by the
app each time another "global" envmap is loaded), I can still perform
those histogram-based steps on the CPU. It was just an idea inspired by
your tone mapping LUT function; but facing all those obstacles might not
be worth it for this single task - there's still plenty of work left in
the other parts...


However, thanks a lot for all your advices!

Matthias



> -----Ursprüngliche Nachricht-----
> Von: Simon Green [mailto:address@hidden 
> Gesendet: Dienstag, 27. Januar 2004 02:08
> An: 'Drew Hess'; Matthias Biedermann
> Cc: address@hidden
> Betreff: RE: [Openexr-devel] Re: LUT for HDR-histograms, too?
> 
> 
> 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.
> > 
>