On Friday, December 2, 2016 at 9:23:26 AM UTC-5, Helder wrote:
> I must make first a short intro: I'm not an astronomer and I found recent=
ly out that the Hubble telescope used a drizzle algorithm to achieve an ima=
ging resolution higher then the pixel accuracy. As I would say, they have g=
one below the Nyquist frequency (1/2l with l being the pixel spacing).
> This is useful when the imaging system delivers an image with higher reso=
lution than what the detector can resolve *and* when the image can shifted =
arbitrarily on the detector with subpixel resolution.
> Ok, so I would like to try that. If anybody has some code that does that,=
it would be super-cool, but assuming that I'm not that lucky:
> - Anybody have a good reference where the math/physics of the image recon=
struction process is described?
> - Anybody have "practical" experience: how accurate does the subpixel shi=
ft have to be? Signal-to-Noise ratios?
> I came across an article on David's page, but apparently David's article =
deals with array decimation and Wayne Landsman mentions:
> - that there aren't any "drizzle or other flux conserving algorithms avai=
lable in IDL.
> - there is some C-code that can be linked to IDL. Anybody tried this???
> Half way down I thought that this is an astronomy or math question rather=
than IDL, but at the end of the day I want to implement this in IDL, not C=
or something else.
> Also, I don't use satellite images. I would be dealing with a set of n-im=
ages of (nx,ny) pixels and relative n-shifts (dx,dy). I can freely choose (=
dx,dy), but generally blow 1 pixel, if necessary higher.
> Thanks for any help and have a nice weekend,
I am an astronomer working with HST. I can point you to a few references, =
but before I do, let me just say a few things so we're talking the same lan=
guage here. You probably already know this stuff, but again just so we're =
on the same page.
First "drizzle" refers to the algorithm for resampling the image. There ar=
e many resampling algorithms you might like (bilinear or Lancozs come to mi=
nd). You might resample for a host of reasons, such as the detector grid is=
highly distorted and you want a rectified image. Or maybe you want to shr=
ink the pixels to improve the spatial resolution. To do this, particularly=
the latter, you need to "dither" the images. Here you take a multiple ima=
ges which are offset from one another by tiny amounts (fractions of pixels)=
, to inform you about scales smaller than the pixel scale (presumably this =
is what you mean about the dx,dy). For HST we're in both camps, distorted i=
mages and under sampled images, but before we can apply the "drizzle" algor=
ithm, we must correct a few things to the native images first (such as alig=
ning them and correcting for varying brightness of the background, and othe=
The current implementation of this is whole package is called DrizzlePac (w=
ritten mostly, if not entirely, in python). The website is:
but the manual for the package is:
I think what you're looking for is Chapter 2 of the manual. Though keep in=
mind this is highly astronomy-centric. In particular, how to deal with co=
smic rays, aligning images on the sky (for example, how accurate are your d=
x,dy estimates), and applying weight images to the arithmetic operations. =
However, I think the nuts and bolts are there. =20
As for an IDL or C implementation.... Well, there's far less there. Alas, =
IDL is falling out of favor among many astronomers, and so drizzle hasn't e=
ntirely been ported. I've written a great deal of stuff, but it's highly t=
ailored to my specific use case. Should you decide to embark on such a pro=
ject, then I can tell you that there are 2-3 major pieces you'll need. Fir=
st is the thing on Fanning's webpage about pixel collection. Second is som=
ething that does the computational geometry (ie. compute overlapping area o=
f two pixel grids), for that look for JD Smith's thing called polyclip. Th=
e other things you'll need are more pedestrian, like how to keep track of w=
hat input pixel goes to what output pixel, and how to combine sets of input=
pixels into the output (i mean, do you want to average them, median them, =
etc.). For the astronomy purposes, this last step gets really tricky with =
dealing with transient things, like cosmic rays. =20
The final thing I"ll caution you with... By construction, you will correlat=
e your output pixels. This will depend on parameters of the drizzle algori=
thm (for example in drizzle pac, they call this pixfrac). This correlated =
noise may or may not be bad for you, depending on the typical brightness of=
the things you're imaging. For astronomy, particularly when looking at ve=
ry very faint things, this correlated noise becomes the dominate source of =
noise (here our objects have signal-too-noise ratios of order 3). So this =
sub pixel stuff will definitely affect your output noise properties (and he=
nce the signal-t-noise ratios), but that's for you to judge. You can very =
very roughly consider this a trade --- you're trading clean noise propertie=
s for improved spatial resolution. THere's no free lunch here, you have to =
give something if you want to get something.
I hope this helps.