Test of experimental starless process on NEOWISE

[michael.h.f.wilkinson]

OK, so back at the office I grabbed my connected filter C code, and the emacs editor to adapt an earlier filter to removing the stars from several NEOWISE images. I added an option to indicate the centre position of the nucleus, and ran the star removal filter, which in this first version already gives results comparable to star-net++ but WAY faster (a few tens of seconds rather than minutes). It should also be easily adapted to floating point data, and run on the linear rather than stretched if you like. It still needs some work (like computing the offsets of the nucleus automatically, perform the starless stacking, and ideally also then stack the stars, but the basic principle shows some promise.

This is a stack of 5 images with stars removed, and then stacked in AS!3 on the nucleus. Some stellar residues can be seen, but I think that it the stars are added back, this might not be visible.

[Louis D]

51 minutes ago, michael.h.f.wilkinson said:

Some stellar residues can be seen

Just looks like imager noise, so not a big deal for most viewers.

I kind of like the effect of not having star streaks in the image distracting from the comet.

[ollypenrice]

Very much what I was thinking of trying should the comet see fit to present itself to the view from my observatories! (We didn't prioritize a low northern view when siting them.) As you say, I'm sure that adding the stars from a single sub (or the stars from a stack stacked on the stars) would take the eye away from any mild artifacts in the starless image. For the sake of accuracy one would want to make all the component images aligned to the same starfield but there's nothing complicated about that provided you know which was the registration sub for the 'aligned on comet' stack. Just use the same sub for reference on the starfield set.

It's already a thrilling image.

Olly

[michael.h.f.wilkinson]

5 minutes ago, Louis D said:

Just looks like imager noise, so not a big deal for most viewers.

I kind of like the effect of not having star streaks in the image distracting from the comet.

True, but I think some of the actual signal in the tail has been removed. Currently the filter removes stars simply based on area, so a single-pixel linear structure less than 10 pixels in length is also removed. A simple upgrade could include elongation, to preserve elongated structures. Another approach would be to remove only compact object significantly brighter than the background, leaving any noise (which stacking takes care of). This would only remove stars, rather than noise or wisps of gas and dust. The main result is that the idea itself is sound. 

[vlaiv]

I would like to further discuss this and similar approaches to star removal if you are up for it.

Main issue that I see with star removal is the fact that:

1. Stars often have significant signal, hence shot noise is much stronger than background nebulosity signal. Subtracting star profile from image will not leave background signal but rather noisy patch in place where star used to be

2. Some stars are clipping so we don't really have good means to produce star profile in that spot - even clipped one (not all stars in all subs will be equally clipping and stacking algorithm needs to be aware of clipping in order to produce good data).

So far I have identified some important points in star removal process.

- Understand per pixel SNR. This is actually much easier than most people believe. Only problem is light pollution - as it is unwanted signal that needs to be remove before we can produce per pixel SNR. There are a few more "gotchas" that need to be addressed here, but basic idea is as follows: We stack a number of subs, and we produce mean value as signal output. We can use stddev stack for noise component. Simple approach would be to take signal, subtract light pollution to represent our signal strength and then use stddev stack divided with square root of number of stacked subs to get noise part. Of course, if we don't use simple average, we need to modify noise part accordingly (like weighted standard deviation, removal of pixels due to sigma clip - we don't have same number of samples for each pixels and so on - these would be "gotchas" mentioned previously).

- In stacking method, we would produce clip map of our stack as well. This helps create accurate star profiles - in case of clipping we would know that and use only non clipped pixels in final stack, or do HDR composing or whatever and when creating star profile we would automatically set clipped pixels to NaN.

In the end, when we remove stars - by subtracting profile for each star - we examine remaining signal value and if it is below certain threshold - like remaining signal / original noise < 3 we place NaN value in that place. We similarly place NaN values in all clipping pixels.

What remains is to "fill in the blanks", or reconstruct NaN values somehow. There are several algorithms to do that, but I'm wondering if this algorithm that uses connectivity can be used/modified and what sort of results it would produce?

[michael.h.f.wilkinson]

50 minutes ago, vlaiv said:

I would like to further discuss this and similar approaches to star removal if you are up for it.

Main issue that I see with star removal is the fact that:

1. Stars often have significant signal, hence shot noise is much stronger than background nebulosity signal. Subtracting star profile from image will not leave background signal but rather noisy patch in place where star used to be

2. Some stars are clipping so we don't really have good means to produce star profile in that spot - even clipped one (not all stars in all subs will be equally clipping and stacking algorithm needs to be aware of clipping in order to produce good data).

So far I have identified some important points in star removal process.

- Understand per pixel SNR. This is actually much easier than most people believe. Only problem is light pollution - as it is unwanted signal that needs to be remove before we can produce per pixel SNR. There are a few more "gotchas" that need to be addressed here, but basic idea is as follows: We stack a number of subs, and we produce mean value as signal output. We can use stddev stack for noise component. Simple approach would be to take signal, subtract light pollution to represent our signal strength and then use stddev stack divided with square root of number of stacked subs to get noise part. Of course, if we don't use simple average, we need to modify noise part accordingly (like weighted standard deviation, removal of pixels due to sigma clip - we don't have same number of samples for each pixels and so on - these would be "gotchas" mentioned previously).

- In stacking method, we would produce clip map of our stack as well. This helps create accurate star profiles - in case of clipping we would know that and use only non clipped pixels in final stack, or do HDR composing or whatever and when creating star profile we would automatically set clipped pixels to NaN.

In the end, when we remove stars - by subtracting profile for each star - we examine remaining signal value and if it is below certain threshold - like remaining signal / original noise < 3 we place NaN value in that place. We similarly place NaN values in all clipping pixels.

What remains is to "fill in the blanks", or reconstruct NaN values somehow. There are several algorithms to do that, but I'm wondering if this algorithm that uses connectivity can be used/modified and what sort of results it would produce?

This is an area of active research in my group, with the aim of segmenting the signal as accurately as possible into overlapping objects and background. The idea is that we remove the star profile, not represented as a model, but simply "warts and all" with noise included. This leaves a flat area in the remainder, which is a bit ugly, but in this instance they are rather small (<10 pixels). There are ways to mitigate this (including inpainting based on the surrounding pixels, which is rather trivial in these tiny areas), and suitable Poisson noise can be added if desired, for a more natural look. However, this might not be needed if the stars are added back after separate processing, as they will fill the flat areas with their original profile. If you reduce star sizes by some means, you need to have a suitable transition region in order to fill the flat areas up, or you do the inpainting. Again, this is early days, but the initial result is promising.

[michael.h.f.wilkinson]

Just had another idea: These filters work in 3D as well as 2D (all that changes is the number of neighbours). As in this case, I first star align the images in whatever program I like, and indicate to the program where the nucleus is roughly. It then works out the centre coordinates of the bright blob I indicated, and creates a set of images (with stars) aligned on the comet's nucleus. I then treat a stack of these aligned images as a 3D data set. Faint, aligned structures can then be separated from the stars more effectively, because the stars show trails not parallel to the z-axis of the stack of images, and they have a small volume. They will also all have about the same slope in the z direction, making them easy to pick out. You could then separately stack the "straight" comet data from the "skewed" star data. This should not be too hard to code.

The current program treats all colours separately. It is also possible to treat this type of data as a luminance data set (simply by adding the signals) and using the colour data separately to reintroduce the colour information. This might be more robust against noise.

[Louis D]

I was going to say, can't you use multiple frames to detect stars because they move in a deterministic manner within and between images?  I'm not familiar with the 3D data set idea, but if all the comet data does end up in a single plane, it should be fairly simple to remove everything not in that plane (the stars).  That, or squash them all into a single point each within the comet image plane so the stars are pinpoints instead of trails.

[michael.h.f.wilkinson]

4 hours ago, Louis D said:

I was going to say, can't you use multiple frames to detect stars because they move in a deterministic manner within and between images?  I'm not familiar with the 3D data set idea, but if all the comet data does end up in a single plane, it should be fairly simple to remove everything not in that plane (the stars).  That, or squash them all into a single point each within the comet image plane so the stars are pinpoints instead of trails.

The comet data will be spread out over all z-planes, but should not show a consistent slope. In this way, small area structures which follow the motion of the comet can be distinguished from the stars. Noise pixels will also show no preferred orientation, which the stars will show.