Hi Axel, >> In lieu of reprojecting the image with pinterp, which is as you say >> unsupported, it is possibly to apply a correction to the image values to >> account for the difference in solid angle at each pixel. Given that the >> solid angle of the equisolid-angle projection is the same for each pixel, we >> really only need the solid angle for the equidistant projection. This can >> be computed with a simple expression, which is sin(theta)/theta. > > You see, this is where I get a little lost between 'projection', > 'distortion', and 'vignetting'. They are, of course, different things. > Something like (don't quote me on it): > - projection: that would be 'equidistant' or 'equisolidangle' > - distortion: the deviation from the ideal 'projection'. Think pin > cushion or barrel > - vignetting: drop-off in image brightness towards the image horizon > > Would not the sin(theta)/theta correction account only for the pixel > brightness? In other words: the pixel 'location' on the photographic > plate/CCD chip would still be wrong, so that the Guth index in the UGR > formula would be off?
The brightness of the pixel will be correct once you've accounted for vignetting. The sin(theta)/theta multiplier is used to reweight the pixel so that it contributes the same amount to luminous flux (luminance times steradians) everywhere in the image. This is what you need for the glare source calculations, I think. Otherwise, you would be treating the light sources near the view horizon as bigger than they should be. > I can imagine that one could create a pcomb cal file that builds up a > new image from the corrected radial distance of the pixel in the > source image. If this get too aliased (blocky), one could average over > the nearby pixels using the optional x,y offset that pcomb provides, > e.g. (spaces added for clarity): > ro=.5*ri(1) + .5*( ri(1,-1,0)+ri(1,1,0)+ri(1,0,-1)+ri(1,0,1) )/4 etc > which is effectively a box filter. Not tested! Don't try this at home! > One could fiddle with the pixel/off-pixel multipliers (both .5 in this > case) to see what would look best. I'm not sure how floating point > pixel coordiantes are handled by pcomb. Are they just rounded off? I suppose this would work, but it seems more work than is necessary. Yes, floating point pixel coordinates are rounded off. > This approach would, of course, smudge out the luminance of the new, > constructed pixel to a certain extend, but considering that the lens > rensponse function does this anyhow, it's probably a small price to > pay for a smooth-as-a-baby's-bottom image. > > This would correct the pixel 'position', but where I get confused with > all this is this: How would one then have to correct the pixel > brightness (vignetting?) to account for this re-projection of pixel > locations, while still maintaining photometric integrity of the image > as a whole (vertical illuminance, say... Or UGR)? I guess you'd want to correct for vignetting in whatever projection you measured your vignetting error, probably before getting to this reprojection stage. I still think the easiest thing is to correct for vignetting and pixel size at the same time, then go ahead and treat the image as if its an equidistant projection. In other words, divide by the solid angle ratio (i.e., multiply each pixel by theta/sin(theta)) and then pass it through findglare as you would normally. Make sense? -Greg _______________________________________________ HDRI mailing list [email protected] http://www.radiance-online.org/mailman/listinfo/hdri
