f



drizzle function (?)

Hi,
I must make first a short intro: I'm not an astronomer and I found recently=
 out that the Hubble telescope used a drizzle algorithm to achieve an imagi=
ng resolution higher then the pixel accuracy. As I would say, they have gon=
e below the Nyquist frequency (1/2l with l being the pixel spacing).
This is useful when the imaging system delivers an image with higher resolu=
tion than what the detector can resolve *and* when the image can shifted ar=
bitrarily on the detector with subpixel resolution.

Ok, so I would like to try that. If anybody has some code that does that, i=
t would be super-cool, but assuming that I'm not that lucky:

- Anybody have a good reference where the math/physics of the image reconst=
ruction process is described?
- Anybody have "practical" experience: how accurate does the subpixel shift=
 have to be? Signal-to-Noise ratios?

I came across an article on David's page, but apparently David's article de=
als with array decimation and Wayne Landsman mentions:
- that there aren't any "drizzle or other flux conserving algorithms availa=
ble 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 t=
han IDL, but at the end of the day I want to implement this in IDL, not C o=
r something else.

Also, I don't use satellite images. I would be dealing with a set of n-imag=
es 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,
Helder
0
Helder
12/2/2016 2:23:23 PM
comp.lang.idl-pvwave 12260 articles. 4 followers. Post Follow

1 Replies
551 Views

Similar Articles

[PageSpeed] 33

On Friday, December 2, 2016 at 9:23:26 AM UTC-5, Helder wrote:
> Hi,
> 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.
>=20
> 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:
>=20
> - 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?
>=20
> 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???
>=20
> 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.
>=20
> 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.
>=20
> Thanks for any help and have a nice weekend,
> Helder

Hi Helder.

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=
rs).

The current implementation of this is whole package is called DrizzlePac (w=
ritten mostly, if not entirely, in python).  The website is:

http://drizzlepac.stsci.edu

but the manual for the package is:

http://documents.stsci.edu/hst/HST_overview/documents/DrizzlePac/drizzlepac=
..pdf

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.
russell
0
rryan
12/8/2016 9:12:03 PM
Reply: