Re: Undershooting in spherical harmonics generated bycubemap convolution

Sam wrote at 5/5/2009:
> I'm not quite sure what you mean by diffuse radiance?
Eh, sorry. This radiometry terminology always gets somehow mixed up in
my head. :) I was refering to irradiance, whereas I think that method of
testing would work e.g. for incoming radiance.

> If you start with a SH function in a cube map (say, an L1 term),
> "do your thing" to get it into SH, and then regenerate a cube map
> (or similar) from your generated SH data you can still check whether
> it's correct as the end result should just be a scaled version of
> the original. The scaling should depend on which of the 3 of the
> above you are working with in the "do your thing" step.

Am I wrong to think that the difference is not just a scaler in some
of those cases? When trying to get irradiance SH from a cubemap which
represents radiance, I'm convolving not just by the SH, but also by
clamped cosine. When convolving with cosine, I'm effectively
generating a "blurry" SH from a "non-blurry" cubemap. Converting that
"blurry" SH into a cubemap will generate a "blurry" cubemap, which
cannot be easily compared to the "non-blurry" original (save for doing
O(P^2) convolution in the cubemap space and comparing to that).

I'm not very proficient with SHs, so it's all a bit hand-wavy on my
side, but... Such test passes if I use the c0-c4 coefficients as
intended for irradiance (without the 2/3 and 1/4 parts), but not if
I use the coefficients that incorporate cosine convolution (those with
2/3 and 1/4). This leads me to believe that my hunch makes sense.

Granted, I could generate a cubemap from synthetic SHs, convolve them
back and check that the result is exactly different by the 2/3 and 1/4
factors in the correct places. But I fear it kind of defeats the
purpose of testing.

> If it's radiance it should be exactly the same, if it's irradiance
> it should be scaled by the cosine terms (see the ramamoorthi paper)
> and if it's exit radiance it'll be the irradiance * albedo. 

> Even if you ignore scaling you should still be able to check that if
> you put a single SH term in you get a single SH term back - all
> other terms should remain 0.

That passes. But it seems like (and is intuitive to be that way) this
kind of test covers only existence of correct x/y/z powers in the
polynomials. Putting any coefficients in front passes the test. (E.g.
if c0-c4 are all 1, this test passes.) Or am I missing something?

In general I'd be very happy if I could test whether the convolution
actually generates SHs that are equivalent (to within approximation
error) to the source cubemap _with_ cosine term already included. I
guess there is no other way than to convolve the old-fashioned way?

Thanks,
Alen


------------------------------------------------------------------------------
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com
_______________________________________________
GDAlgorithms-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gdalgorithms-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=gdalgorithms-list