Lodestar acquisition and noisy pixels

Discussions, Bug Reports and Issues related to Beta versions of SharpCap
Post Reply
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Lodestar acquisition and noisy pixels

#1

Post by Hibou »

There are two important differences between SharpCap and an old version of PHD for real-time display of low light images with a lodestar.
1) My old PHD has a 3x3 median noise filter, which removes hot pixels. The intensity scale of the real time display is then not skewed by these high intensity points, and I immediately see faint details with PHD that I don't see with SharpCap. If I toggle off the filter, I immediately see the hot pixels - and nothing else, as with SharpCap. Yes, I can treat the SharpCap images off-line with ImageJ, but I need a real-time display. The 3x3 median noise filter is very simple to implement and runs fast in real time - hot pixels are simply replaced by the median value of the other 3x3 surrounding pixels. It would be great if SharpCap could optionally do that in real time.
2) When SharpCap reads the odd then even rows of a Lodestar, it actually exposes for twice as long ! A 60s exposure takes two minutes. Surely both the even and odd rows are accumulated on-chip in the first 60s, so why is a second exposure necessary to read them out separately ?

Regards, Alan.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Lodestar acquisition and noisy pixels

#2

Post by admin »

Hi,

an interesting question about the interlaced readout on the lodestar - I tried to get that to work when I first added support for the SX cameras and couldn't find a way to make it happen. I must admit that I never played around much with the lodestar in other applications - does PHD or some other application get around the 'read it twice to get all the pixels' problem? Knowing if it was possible might help ...

On the subject of the noise reduction, there isn't a median filter anywhere in SharpCap at the moment, but there is a gaussian blur that can be seen on the display in a couple of places - not quite the same, but should give noise reduction. Unfortunately neither place is ideal for just watching the image - one place that you can turn on noise reduction is in live stacking (but that probably is no use to you). The other, which is at least on a frame-by-frame basis is in the polar alignment. If you turn up the noise reduction there you actually see the results on screen, but unfortunately with stars highlighted, etc.

If the Gaussian Blur noise reduction is good enough then it would be relatively simple to add it as a display FX option I think, since the code for the actual blur already exists.

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: Lodestar acquisition and noisy pixels

#3

Post by Hibou »

Thanks for the reply Robin. I made screen captures to illustrate these two questions using faint afterglow from a square scintillator plate.

The first image is an unfiltered 8s exposure with simplified PHD. The afterglow is barely visible, with the auto intensity emphasising hot pixels.
1) https://neutronoptics.com/images/PHD-8s.gif
With the noise filter on, hot pixels are removed and auto intensity emphasises afterglow, visible for many minutes (the lighter square).
2) https://neutronoptics.com/images/PHD-8s-filtered.gif
Compare this to the third image with maximum gain in SC4. The auto intensity again emphasises hot pixels, masking low intensity afterglow.
3) https://neutronoptics.com/images/SC4-8s.gif
The afterglow can be seen if we increase the black level in image 4) but it's still pretty faint, even though the SC4 images preceded those of PHD.
3) https://neutronoptics.com/images/SC4-8s-blacklevel.gif

IMHO real time display should emphasise low intensities automatically, and it can't do that in the presence of hot pixels. But the saved image should be raw data including hot pixels. Post capture binning for real-time display would also help emphasise low intensity, again saving unbinned data.

The second point is that PHD takes 8s per capture, while SC4 takes 8+8s because it does a double exposure for odd then even rows. The green Frame completion bar in the bottom right corner is full after 8s, but then SC4 waits another 8s for the even rows.

I will try this experiment with the latest version of PHD which ships with the lodestar, though it's more complicated to use than my simplified version.

Regards, Alan
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Lodestar acquisition and noisy pixels

#4

Post by admin »

Hi,

I just looked at the code for PHD2 and the way it handles the StarlightXpress cameras. I found this...

Code: Select all

        if (Interlaced)
        {
            // Interlaced cams are run in "high speed" mode (vertically binned)
That means that PHD can get all the pixels read in one go by using the 2x vertical binning option - no need to take 2 exposures, but there is a loss of resolution.

The equivalent in SharpCap is to set the interlace option to "Capture All Rows (2x vertical bin)".

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: Lodestar acquisition and noisy pixels

#5

Post by Hibou »

Robin. That's brilliant. In fact, I feel pretty foolish, and don't know how I missed it. Probably because I only previously used short exposures, and didn't notice that SC4 was double exposing. If I did try the last option to "Capture all rows", I didn't understand it and overlooked it because it produced squashed images. Is there a way to vertically stretch the SC4 display to restore the aspect ratio ? Maybe the best way would be to simply repeat every row, so that the saved image also had the right aspect ratio. I suspect that's what PHD does. It would explain why the hot pixels in PHD appear vertically stretched.

So Sony made a chip that requires double exposure to read out the odd and even rows separately.

But if you have the PHD code open, perhaps you could also look how they do 3x3 median hot pixel removal :-)

Regards, Alan.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Lodestar acquisition and noisy pixels

#6

Post by admin »

Hi Alan,

I think I could add another 'interlace' option for 'both fields, 2x binning, full aspect ratio'. I also remembered that there is already a median blur as part of the star detection, so will look to see if/how that could be wired up to a display FX option.

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: Lodestar acquisition and noisy pixels

#7

Post by Hibou »

That sounds good. Thanks Robin.
Regards, Alan.
User avatar
admin
Site Admin
Posts: 13177
Joined: Sat Feb 11, 2017 3:52 pm
Location: Vale of the White Horse, UK
Contact:

Re: Lodestar acquisition and noisy pixels

#8

Post by admin »

Hi,

check out the latest update 4.0.8282 - that has both the new interlace handling mode and a 3x3 median blur (under the FX dropdown).

cheers,

Robin
User avatar
Hibou
Posts: 81
Joined: Thu Jul 05, 2018 3:25 pm
Location: French Alps
Contact:

Re: Lodestar acquisition and noisy pixels

#9

Post by Hibou »

Brilliant Robin. Those two changes work well. The x2 vertical stretching after capturing all rows and binning x2 vertically, as is done in PHD, is particularly useful. The 3x3 Median Blur to reduce noise certainly does that, but in practice it's not as useful as I imagined, since it has little effect on the visibility of very faint images as I supposed. More important for that is to increase the Black Level to about mid-way.

I don't know how the automatic enhancement of faint images is done in PHD and imageJ, but in both it is very effective when hot pixels are first removed. SX4's Boost Image does boost the image but not as well as imageJ's Image/Adjust/Brightness/Contrast/Auto (preceded by Process/Noise/Despeckle). To get the same result with SX4 the Black Level must be manually adjusted by trial and error, with Histogram Stretch.

It's good that SX4 saves the raw data, so that it can be filtered and boosted off-line in imageJ, but for my application I also need to see faint images in real-time.

Sorry I could not get back to this earlier in the week when you made the changes, and thanks again for these two very useful additions (tested in SC 4.0.8315.0 of 1/11/2021}.

Regards. Alan.
Post Reply