You can subscribe to this list here.
2000 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}
(390) 
_{Aug}
(767) 
_{Sep}
(940) 
_{Oct}
(964) 
_{Nov}
(819) 
_{Dec}
(762) 

2001 
_{Jan}
(680) 
_{Feb}
(1075) 
_{Mar}
(954) 
_{Apr}
(595) 
_{May}
(725) 
_{Jun}
(868) 
_{Jul}
(678) 
_{Aug}
(785) 
_{Sep}
(410) 
_{Oct}
(395) 
_{Nov}
(374) 
_{Dec}
(419) 
2002 
_{Jan}
(699) 
_{Feb}
(501) 
_{Mar}
(311) 
_{Apr}
(334) 
_{May}
(501) 
_{Jun}
(507) 
_{Jul}
(441) 
_{Aug}
(395) 
_{Sep}
(540) 
_{Oct}
(416) 
_{Nov}
(369) 
_{Dec}
(373) 
2003 
_{Jan}
(514) 
_{Feb}
(488) 
_{Mar}
(396) 
_{Apr}
(624) 
_{May}
(590) 
_{Jun}
(562) 
_{Jul}
(546) 
_{Aug}
(463) 
_{Sep}
(389) 
_{Oct}
(399) 
_{Nov}
(333) 
_{Dec}
(449) 
2004 
_{Jan}
(317) 
_{Feb}
(395) 
_{Mar}
(136) 
_{Apr}
(338) 
_{May}
(488) 
_{Jun}
(306) 
_{Jul}
(266) 
_{Aug}
(424) 
_{Sep}
(502) 
_{Oct}
(170) 
_{Nov}
(170) 
_{Dec}
(134) 
2005 
_{Jan}
(249) 
_{Feb}
(109) 
_{Mar}
(119) 
_{Apr}
(282) 
_{May}
(82) 
_{Jun}
(113) 
_{Jul}
(56) 
_{Aug}
(160) 
_{Sep}
(89) 
_{Oct}
(98) 
_{Nov}
(237) 
_{Dec}
(297) 
2006 
_{Jan}
(151) 
_{Feb}
(250) 
_{Mar}
(222) 
_{Apr}
(147) 
_{May}
(266) 
_{Jun}
(313) 
_{Jul}
(367) 
_{Aug}
(135) 
_{Sep}
(108) 
_{Oct}
(110) 
_{Nov}
(220) 
_{Dec}
(47) 
2007 
_{Jan}
(133) 
_{Feb}
(144) 
_{Mar}
(247) 
_{Apr}
(191) 
_{May}
(191) 
_{Jun}
(171) 
_{Jul}
(160) 
_{Aug}
(51) 
_{Sep}
(125) 
_{Oct}
(115) 
_{Nov}
(78) 
_{Dec}
(67) 
2008 
_{Jan}
(165) 
_{Feb}
(37) 
_{Mar}
(130) 
_{Apr}
(111) 
_{May}
(91) 
_{Jun}
(142) 
_{Jul}
(54) 
_{Aug}
(104) 
_{Sep}
(89) 
_{Oct}
(87) 
_{Nov}
(44) 
_{Dec}
(54) 
2009 
_{Jan}
(283) 
_{Feb}
(113) 
_{Mar}
(154) 
_{Apr}
(395) 
_{May}
(62) 
_{Jun}
(48) 
_{Jul}
(52) 
_{Aug}
(54) 
_{Sep}
(131) 
_{Oct}
(29) 
_{Nov}
(32) 
_{Dec}
(37) 
2010 
_{Jan}
(34) 
_{Feb}
(36) 
_{Mar}
(40) 
_{Apr}
(23) 
_{May}
(38) 
_{Jun}
(34) 
_{Jul}
(36) 
_{Aug}
(27) 
_{Sep}
(9) 
_{Oct}
(18) 
_{Nov}
(25) 
_{Dec}

2011 
_{Jan}
(1) 
_{Feb}
(14) 
_{Mar}
(1) 
_{Apr}
(5) 
_{May}
(1) 
_{Jun}

_{Jul}

_{Aug}
(37) 
_{Sep}
(6) 
_{Oct}
(2) 
_{Nov}

_{Dec}

2012 
_{Jan}

_{Feb}
(7) 
_{Mar}

_{Apr}
(4) 
_{May}

_{Jun}
(3) 
_{Jul}

_{Aug}

_{Sep}
(1) 
_{Oct}

_{Nov}

_{Dec}
(10) 
2013 
_{Jan}

_{Feb}
(1) 
_{Mar}
(7) 
_{Apr}
(2) 
_{May}

_{Jun}

_{Jul}
(9) 
_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

2014 
_{Jan}
(14) 
_{Feb}

_{Mar}
(2) 
_{Apr}

_{May}
(10) 
_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}
(3) 
_{Dec}

2015 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(12) 
_{Nov}

_{Dec}
(1) 
2016 
_{Jan}

_{Feb}
(1) 
_{Mar}
(1) 
_{Apr}
(1) 
_{May}

_{Jun}
(1) 
_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 







1
(4) 
2
(3) 
3
(3) 
4
(4) 
5
(10) 
6
(10) 
7
(6) 
8
(8) 
9
(1) 
10
(7) 
11
(7) 
12
(6) 
13
(6) 
14
(19) 
15
(1) 
16

17
(2) 
18
(3) 
19
(1) 
20

21
(2) 
22
(3) 
23
(2) 
24
(2) 
25

26
(3) 
27
(26) 
28
(4) 
29
(4) 
30







From: Alen Ladavac <alenlml@cr...>  20060423 19:29:27

Oh I see. Makes sense, of course. I thought it was something more complicated. I'm not using this for cube>sh (not anymore at least), I'm using those factors for directional light. But now that I understand some stuff here better, I started getting curious about how exactly does the directional light to sh conversion works. But it's all snapping into place now. Thanks for all your help. I only list 5 numbers as the 9 polymonials repeat the same 5 coefficients, so no need to repeat them. The polynomials are in fact: c0 c1*y c1*z c1*x c2*x*y c2*y*z c3*(2z*z1) c2*x*z c4*(x*xy*y) Do you see a problem there, or is it all ok? Thanks, Alen Sunday, April 23, 2006, 5:57:33 PM, you wrote: > The Pi*16/17 factors comes from the notion of a normalized ([0,1] space) > directional light. It is derived by solving for a scale factor that > given a normal pointed in Z with a directional light shining right on it > and unit albedo would reflect 1.0. But I don't think you need this  > you just need to integrate the RGB values against the raw SH basis > functions (there should be 9 through the cubics  not sure why you are > just showing 5 below and they are polynomials of the normalized > direction.) > PeterPike Sloan > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen > Ladavac > Sent: Saturday, April 22, 2006 11:12 AM > To: PeterPike Sloan > Cc: gdalgorithmslist@... > Subject: Re[2]: [Algorithms] Cubemap to spherical harmonics (again) > Thanks a bunch! This does the trick. The reference I was using for > differential angle obviously got it wrong, plus I didn't do the cos > kernel convolution correctly. > For an additional note, r^(3/2) is not quite correct in this context. > I messed that while retyping C into pcode. It should be only r^3. The > full expression from that Mathworld article is (x^2+y^2+z^2)^(3/2), > but since r is already length, not length squared, the square root > should be dropped. So the differential angle for a point on a > (1,+1)^3 cube is r^3. With this formulation, sum(diffangle * > pointarea) / numpoints approaches 4*PI, so it seems to be correct. > Now that my cubemap to SH code is fine, I'm getting curious about my > directional light to SH formulae. They work perfectly, but I don't > understand why. :) > I use the coefficients mentioned before: >> 0.282095*0.282095 * PI*16/17 * 1, >> 0.488603*0.488603 * PI*16/17 * 2/3, >> 1.092548*1.092548 * PI*16/17 * 1/4, >> 0.315392*0.315392 * PI*16/17 * 1/4, >> 0.546274*0.546274 * PI*16/17 * 1/4 > The decimal numbers are from the SH basis (1/2*sqrt(pi) etc). They are > squared to save on one more multiplication at runtime. The 1, 2/3 and > 1/4 factors are from the cosine convolution. I reckon PI is because I > need to transform irradiance integral into outgoing radiance. But I > still don't know what's 16/17 doing there. I recall that it supposedly > has something to do with 17/16*4 being the sum of 1 + 3*2/3 + 5*1/4. > But why is that sum used here, and not when cosine kernel is added to > the cubemap projection. And what about the 4? Any explanation or clue > on this are warmly welcome. :) > Thanks, > Alen > Saturday, April 22, 2006, 2:27:00 AM, you wrote: >> I think you are mixing a couple of things up (directional lights and >> projection.) It's much easier to just think of this as projection  > in >> that case you get: >> sum =3D 0 // vector of SH coeffs for each color channel >> wt =3D 0 >> For each face >> For each pixel >> =20 >> vdir =3D position on cube (domain is (1,+1)^3) >> r =3D len(vdir); >> vdir /=3D r; >> da =3D 24.0*r^(3/2) >> wt +=3D da >> rgb =3D sample the pixel value >> rgb *=3D da; >> =20 >> addtoSHC(rgb,vdir,sum) >> =20 >> sum *=3D 4*Pi/wt >> addtoSHC should just evaluate the SH basis functions in direction dir. >> wt/num_pixels should equal 4*Pi (but it won't be exactly on the CPU, > so >> I tend to do this normalization), so you can just not accumulate the >> total weight and instead just divide sum by the # of pixels. >> The addtoSHC should literally just be evaluating the basis functions > (if >> you want to convolve with the normalized cosine kernel just scale the >> bands by 1,2/3,1/4,0,etc.) >> PeterPike Sloan >> (the differential solid angle term is where the r(3/2) comes from  >> it's commonly used when computing form factors in radiosity, a >> derivation is here: >> http://mathworld.wolfram.com/SolidAngle.html=20 >> for what amounts to a cube map. A factor of 4.0 is used in the >> numerator of a single face, where 24 can be used for the full cube > (it's >> just the area of the cube so that when you divide by the number of >> samples you get the correct fraction of 4*Pi  if you do the >> normalization yourself this doesn't matter of course since it just >> cancels out...) ) >> Original Message >> From: gdalgorithmslistadmin@... >> [mailto:gdalgorithmslistadmin@...] On Behalf Of > Alen >> Ladavac >> Sent: Friday, April 21, 2006 9:10 AM >> To: gdalgorithmslist@... >> Subject: [Algorithms] Cubemap to spherical harmonics (again) >> Hi list, >> I believe that this issue, even though discussed a lot, was never >> completely clarified in one place. So as my implementation is a kind >> of a Frankenstein creation stitched from fragments of math that I >> understand and pieces that still make by head steam, I guess it can't >> hurt to run the actual result by some people that comprehend the SH >> math better than me. >> The reason I ask is that when I run it on a cube that has upper half >> pure red and lower half pure green, I get something that I don't quite >> expect. Upon evaluating the resulting SH in various directions, I get >> mostly yellow everywhere, with just a tiny bit of red/green in the >> up/down directions. >> Even with the cosine term, I'd expect the straight up/down directions >> to be pure red/green. Is my expectation wrong, or is the problem in my >> implementation? >> Here is the pcode: >> correction =3D 1/(PI*16/17) >> pixelarea =3D 4/(sizeU*sizeV) >> for each face on the cube >> for each pixel on the face >> vdir =3D position on cube (domain is (1,+1)^3) >> r =3D len(vdir); >> vdir /=3D r; >> da =3D pixelarea*r^(3/2) >> rgb =3D sample the pixel value >> rgb *=3D angle * correction; >> addtoSHC(rgb,dir) >> Where "addtoSHC()" is the one normally used by the directional light. >> I.e. it uses the squared factors with extra corrections: >> 0.282095*0.282095 * PI*16/17 * 1, >> 0.488603*0.488603 * PI*16/17 * 2/3, >> 1.092548*1.092548 * PI*16/17 * 1/4, >> 0.315392*0.315392 * PI*16/17 * 1/4, >> 0.546274*0.546274 * PI*16/17 * 1/4 >> I also tried using the plain set of factors for adding (without the >> squaring and the corrections), but I get even stranger results. >> Thanks in advance for any insight, >> Alen >>  >> Using Tomcat but need to do more? Need to support web services, >> security? >> Get stuff done quickly with preintegrated technology to make your job >> easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache >> Geronimo >> > http://sel.asus.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat= =3D121642 >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >>  >> Using Tomcat but need to do more? Need to support web services, > security? >> Get stuff done quickly with preintegrated technology to make your job > easier >> Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo >> http://sel.asus.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 >> _______________________________________________ >> GDAlgorithmslist mailing list >> GDAlgorithmslist@... >> https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist >> Archives: >> http://sourceforge.net/mailarchive/forum.php?forum_ida88 =20 Best regards, Alen mailto:alenlml@... 
From: PeterPike Sloan <ppsloan@wi...>  20060423 15:57:40

The Pi*16/17 factors comes from the notion of a normalized ([0,1] space) directional light. It is derived by solving for a scale factor that given a normal pointed in Z with a directional light shining right on it and unit albedo would reflect 1.0. But I don't think you need this  you just need to integrate the RGB values against the raw SH basis functions (there should be 9 through the cubics  not sure why you are just showing 5 below and they are polynomials of the normalized direction.) PeterPike Sloan Original Message From: gdalgorithmslistadmin@... [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen Ladavac Sent: Saturday, April 22, 2006 11:12 AM To: PeterPike Sloan Cc: gdalgorithmslist@... Subject: Re[2]: [Algorithms] Cubemap to spherical harmonics (again) Thanks a bunch! This does the trick. The reference I was using for differential angle obviously got it wrong, plus I didn't do the cos kernel convolution correctly. For an additional note, r^(3/2) is not quite correct in this context. I messed that while retyping C into pcode. It should be only r^3. The full expression from that Mathworld article is (x^2+y^2+z^2)^(3/2), but since r is already length, not length squared, the square root should be dropped. So the differential angle for a point on a (1,+1)^3 cube is r^3. With this formulation, sum(diffangle * pointarea) / numpoints approaches 4*PI, so it seems to be correct. Now that my cubemap to SH code is fine, I'm getting curious about my directional light to SH formulae. They work perfectly, but I don't understand why. :) I use the coefficients mentioned before: > 0.282095*0.282095 * PI*16/17 * 1, > 0.488603*0.488603 * PI*16/17 * 2/3, > 1.092548*1.092548 * PI*16/17 * 1/4, > 0.315392*0.315392 * PI*16/17 * 1/4, > 0.546274*0.546274 * PI*16/17 * 1/4 The decimal numbers are from the SH basis (1/2*sqrt(pi) etc). They are squared to save on one more multiplication at runtime. The 1, 2/3 and 1/4 factors are from the cosine convolution. I reckon PI is because I need to transform irradiance integral into outgoing radiance. But I still don't know what's 16/17 doing there. I recall that it supposedly has something to do with 17/16*4 being the sum of 1 + 3*2/3 + 5*1/4. But why is that sum used here, and not when cosine kernel is added to the cubemap projection. And what about the 4? Any explanation or clue on this are warmly welcome. :) Thanks, Alen Saturday, April 22, 2006, 2:27:00 AM, you wrote: > I think you are mixing a couple of things up (directional lights and > projection.) It's much easier to just think of this as projection  in > that case you get: > sum =3D 0 // vector of SH coeffs for each color channel > wt =3D 0 > For each face > For each pixel > =20 > vdir =3D position on cube (domain is (1,+1)^3) > r =3D len(vdir); > vdir /=3D r; > da =3D 24.0*r^(3/2) > wt +=3D da > rgb =3D sample the pixel value > rgb *=3D da; > =20 > addtoSHC(rgb,vdir,sum) > =20 > sum *=3D 4*Pi/wt > addtoSHC should just evaluate the SH basis functions in direction dir. > wt/num_pixels should equal 4*Pi (but it won't be exactly on the CPU, so > I tend to do this normalization), so you can just not accumulate the > total weight and instead just divide sum by the # of pixels. > The addtoSHC should literally just be evaluating the basis functions (if > you want to convolve with the normalized cosine kernel just scale the > bands by 1,2/3,1/4,0,etc.) > PeterPike Sloan > (the differential solid angle term is where the r(3/2) comes from  > it's commonly used when computing form factors in radiosity, a > derivation is here: > http://mathworld.wolfram.com/SolidAngle.html=20 > for what amounts to a cube map. A factor of 4.0 is used in the > numerator of a single face, where 24 can be used for the full cube (it's > just the area of the cube so that when you divide by the number of > samples you get the correct fraction of 4*Pi  if you do the > normalization yourself this doesn't matter of course since it just > cancels out...) ) > Original Message > From: gdalgorithmslistadmin@... > [mailto:gdalgorithmslistadmin@...] On Behalf Of Alen > Ladavac > Sent: Friday, April 21, 2006 9:10 AM > To: gdalgorithmslist@... > Subject: [Algorithms] Cubemap to spherical harmonics (again) > Hi list, > I believe that this issue, even though discussed a lot, was never > completely clarified in one place. So as my implementation is a kind > of a Frankenstein creation stitched from fragments of math that I > understand and pieces that still make by head steam, I guess it can't > hurt to run the actual result by some people that comprehend the SH > math better than me. > The reason I ask is that when I run it on a cube that has upper half > pure red and lower half pure green, I get something that I don't quite > expect. Upon evaluating the resulting SH in various directions, I get > mostly yellow everywhere, with just a tiny bit of red/green in the > up/down directions. > Even with the cosine term, I'd expect the straight up/down directions > to be pure red/green. Is my expectation wrong, or is the problem in my > implementation? > Here is the pcode: > correction =3D 1/(PI*16/17) > pixelarea =3D 4/(sizeU*sizeV) > for each face on the cube > for each pixel on the face > vdir =3D position on cube (domain is (1,+1)^3) > r =3D len(vdir); > vdir /=3D r; > da =3D pixelarea*r^(3/2) > rgb =3D sample the pixel value > rgb *=3D angle * correction; > addtoSHC(rgb,dir) > Where "addtoSHC()" is the one normally used by the directional light. > I.e. it uses the squared factors with extra corrections: > 0.282095*0.282095 * PI*16/17 * 1, > 0.488603*0.488603 * PI*16/17 * 2/3, > 1.092548*1.092548 * PI*16/17 * 1/4, > 0.315392*0.315392 * PI*16/17 * 1/4, > 0.546274*0.546274 * PI*16/17 * 1/4 > I also tried using the plain set of factors for adding (without the > squaring and the corrections), but I get even stranger results. > Thanks in advance for any insight, > Alen >  > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with preintegrated technology to make your job > easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.asus.falkag.net/sel?cmd=3Dlnk&kid=3D120709&bid=3D263057&dat=3D= 121642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=3D6188 >  > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with preintegrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.asus.falkag.net/sel?cmdlnk&kid=120709&bid&3057&dat=121642 > _______________________________________________ > GDAlgorithmslist mailing list > GDAlgorithmslist@... > https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_ida88 =20 Best regards, Alen mailto:alenlml@...  Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with preintegrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.asus.falkag.net/sel?cmd=3Dk&kid=120709&bid&3057&dat=121642 _______________________________________________ GDAlgorithmslist mailing list GDAlgorithmslist@... https://lists.sourceforge.net/lists/listinfo/gdalgorithmslist Archives: http://sourceforge.net/mailarchive/forum.php?forum_ida88 