Problems with Star Alignment

[jeffweiss9]

I've tried for the first time to use PI StarAlignment and ImageIntegration to align and stack my subs but I'm getting very poor results trying to follow Harry's tutorial (default) settings.  Many stars are getting black pixels surrounding them and, in addition, I'm getting lots of black pixels appearing in the stacked result that weren't in the original subs.  When I examined the subs registered by StarAlignment, I discovered both of these effects are being introduced by StarAlignment.   Can anyone tell me  what might be wrong here?   
Thanks.
-Jeff

[Juan Conejero]

Hi Jeff,

Decrease the value of the clamping threshold parameter (available on the Interpolation section of StarAlignment's interface). The default value of 0.3 has been chosen because in our tests it has proven valid for the vast majority of images, but sometimes a lower value is required. Start with 0.1 and make a few tries. Decrease it until there is no dark artifact around your stars. If in doubt, prefer a low value to stay at the safe side.

The algorithm used by StarAlignment to generate registered pixels is bicubic spline interpolation. While bicubic interpolation has excellent detail preservation properties, a naive implementation —such as the ones available in most software packages— makes it mostly useless to interpolate linear raw images. The reason is that a cubic function tends to generate ripple artifacts, or strong oscillations, in presence of wild variations in the interpolated data.

These variations happen frequently in linear data, especially with relatively weak data (short exposures), and mainly around bright stars. For example, suppose that there are some contiguous pixels in your image with ADU values such as 1600, 4500, 20000, and 50000. A cubic interpolation function fitted to these values may generate a deep oscillation between the second and third values, due to the extremely strong slope. As a result, the interpolated image will show a dark artifact close to a bright feature in the image.

Our implementation includes a special clamping mechanism to prevent these problems. The clamping device basically switches between bicubic and bilinear interpolation adaptively, when it detects a too strong variation in the interpolated values. For example, in the sequence of pixel values above, the cubic function would be replaced by a straight line between the second and third pixels (the actual mechanism is more complex, but this is the basic concept). The clamping threshold defines when to start replacing bicubic interpolation with bilinear, so a lower value is always more conservative.

Let me know if this helps.

[jeffweiss9]

Thanks, Juan-
 That makes sense, however, even going down to zero on the clamping threshold still leaves a very large number of isolated black pixels in my integrated image, although the black pixels around stars were eliminated at some point below 0.1.  Is there a way to force bilinear rather than bicubic interpolation. Perhaps my 4 minute subs are just too noisy for bicubic. My previous 'standard' for registering and stacking was the bilinear procedure in AIP4WIN which gives none of the black pixels I'm seeing.
-Jeff

[Juan Conejero]

Hi Jeff,

even going down to zero on the clamping threshold still leaves a very large number of isolated black pixels in my integrated image

I haven't seen such behavior before. With linear clamping set to zero that should never happen (it is impossible, in theory). Are you sure those black pixels are being generated by StarAlignment? Can you confirm that by inspecting the registered images prior to the integration?

[jeffweiss9]

Hi, Juan-
   I examined carefully the same close-up area of several of the original subs and don't see any of the black pixel clusters prominent (and prevalent) in the stacked (ImageIntegrate) version, although there are other black single pixels scattered in the noise level (speckle) of the subs.  In the same subs after registration (StarAlignment) with clamping threshold=0, however, I see some but not all of the black pixel clusters visible in the integrated version. So it is pretty clear they are coming from StarAlignment.  My subs come from two different nights of observing (one cycle apart) and it looks like roughly half of the black pixel clusters from the stack are visible in the registered subs from the first night (at least all I examined) and the other half of them are visible in the registered subs I examined closely from the second night.  Somehow ImageIntegrate is stacking the registered images in a way that brings out all the black pixel clusters in the stacked version.  My ImageIntegrate settings are additive, noise evaluation, Windsorized sigma (+-3) clipping but I had tried "no rejection" also and got the same results with respect to the black pixel clusters.  My settings for StarAlignment were all default except for the clamping threshold (default gave black/white artifacts, zero gave what I thought was black-only). My version is 1.06.00.592 (eng) that I had just installed with the commercial license rather than the version I had previously with the trial license.  I don't believe I tried StarAlignment before, although I've used DynamicAlignment successfully quite a number of times.
   Looking even more closely at the integrated image and the AIP4WIN image, I discovered that there are also spurious white pixels appearing from StarAlignment as well.  In fact, setting the clamping threshold to zero apparently just made the black/white aspect of the original set of artifacts go away so I thought I was left with just isolated black clusters.  What actually happened was that the features were still there but StarAlignment left either spurious black pixel clusters or spurious white pixel clusters but not black and white cells adjacent to each other. When I examine the AIP4WIN stacks of the same subs, those residual white clusters are not stars, as I assumed previously and which explains why I didn't notice at first that they were spurious.  So it seems pretty clear to me this is coming from StarAlignment and that setting the Clamping Threshold to zero changes their "black/white" character to either all white or all black (~50-50) but does not make them go away.   
   I must say that when I look even more closely at the corresponding AIP4WIN stacks with the same auto STF in PI, I also discovered faint versions of at least some of the black pixel clusters, although there is no evidence for any of the spurious white pixel clusters in the regions I examined.   Thus there is something similar also happening in at least some of those locations in AIP4WIN's registration and stacking procedure also but it is much less noticeable. In fact, I really had to study the image at the locations of the ImageIntegration artifacts before I noticed these fainter versions of the 'black pixel clusters' were also in the AIP4WIN stacks.  I believe AIP4WIN uses straight bilinear interpolation.
  I hope all this helps pin down the problem, but it seems there is still might be some interpolation problem (bicubic or not).  Guess I've got a talent for stressing software.
 Thanks very much for your help.
-Jeff

[Juan Conejero]

Hi Jeff,

I am very interested in getting to the bottom of this problem. The next version of StarAlignment provides bilinear interpolation as an option. However, with clamp=0 this cannot happen in theory with our implementation of bicubic spline interpolation. So there's something wrong here and I want to know what it is.

Could you please upload a couple of these images somewhere so I can try to reproduce the problem? I'd need them raw, the same images you're working with. Thanks!

[jeffweiss9]

Hi, Juan-
 Ok, I will use yousendit.com to send you two or three of the subs when I get home this evening (free large file email).
-Jeff