Strange Hot Pixels ...
 
Share:
Notifications
Clear all

31 July 2020 - Comet Registration video tutorial using APP 1.083-beta1 released.

30 July 2020 - APP 1.083-beta1 has been released introducing Comet processing! This 1st beta has comet registration. The stable release will also include special comet integration modes.

9 July 2020 - New and updated video tutorial using APP 1.081: Complete LRGB Tutorial of NGC292, The Small Magellanic Cloud by Christian Sasse (iTelescope.net) and Mabula Haverkamp

2019 September: Astro Pixel Processor and iTelescope.net celebrate a new Partnership!

Strange Hot Pixels on Final Integration  

Page 2 / 2
  RSS

(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 26, 2020 21:36  
image

These are the artefacts that I get when drizzle integrating.


ReplyQuote
(@petercpc)
Red Giant Customer
Joined: 3 years ago
Posts: 62
September 27, 2020 09:21  

Yes, they are just like I was getting but I never do drizzle integrating. I suppose we just try the settings set out above as the official wisdom is that there are problems with the data causing it. Although why it should suddenly start doing this, I have no idea.


ReplyQuote
(@neverfox)
White Dwarf Customer
Joined: 4 months ago
Posts: 11
September 27, 2020 19:04  

See my previous thread on the same issue. This is one of several issues I've had with drizzle and/or mosaics (another being that Ha and OIII extract don't result in different results).

This post was modified 4 weeks ago by Roman Pearah

ReplyQuote
(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 28, 2020 08:18  

Ok so I made a BPM with 10min subs (with 20 darks/3.3 hours) and a master bias. It got worse! So it must be the darks/master dark but I made my master dark according to all the beste practices. So I really dont know what to do know. 

 

image

ReplyQuote
(@petercpc)
Red Giant Customer
Joined: 3 years ago
Posts: 62
September 28, 2020 08:25  

@vincent-mod

I have no more ideas. Perhaps Vincent can help.


ReplyQuote
(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 28, 2020 08:55  
image
image
image

(there still seem to be hot pixels after integration. Something I did not have a couple of weeks ago. So I made new calibration frames as maybe my sensor had aged.(sensor is now 4 months old asi533mc)

 

-So I made my darks at the same settings as the lights (20 darks for each exposure length and same temperature also).

-added 80 bias.

-60 flats with 40 darkflat frames each.

 

Used the above settings and let APP run. (only thing I did different now was check create 32 bit masters and used adaptive rejection on all masters as a test) normally I don't check that box and use winsored when using 20 darks.

 

Is there anyone who can give feedback on these settings?

 


ReplyQuote
(@vincent-mod)
Quasar Admin
Joined: 3 years ago
Posts: 2469
September 28, 2020 12:14  

Ok so I have asked Mabula now to have a look, just in case I'm missing something here. Hope he can answer soon.


xs4allan liked
ReplyQuote
(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 28, 2020 22:31  

Is there a solution for the artefacts around stars? (I get these when using different settings to create (better) master dark, bias and bpm to get rid of hot pixels in my integrations)

Like these:

image

 


ReplyQuote
(@mabula-admin)
Quasar Admin
Joined: 4 years ago
Posts: 2470
September 29, 2020 21:21  

Hi @petercpc & @xs4allan & @vincent-mod,

I have read the entire topic and in my experience the problem of elongated pixels will only occur if:

1) you are not really dithering between the frames combined with outlier rejection. The elongated hot pixels in the integration are a clear sign that no dithering is done... the noise is burnt into the integration because of it. It is always possible that not 100% of the hot pixels is corrected by the BPM. Then dithering with outlier rejection will and should fix it still once the integration is made.

2) or the Bad Pixel Map can't be constructed properly from the darks for some reason. This could happen with consumer camera's (Nikon,Canon) where the raws are not real raws but already altered internally by noise reduction algorithms, some Nikon and Sony camera's have this problem for sure, my Nikon D5100 without firmware hack was terrible in this regard...

If you dither and use the automatic BPM function, this problem should not occur and there should be no need to use the cosmetic hot pixel correction (which is not working well yet on OSC data I must admit, this is scheduled to be improved though;-) ) I would never recommend to use cosmetic hot pixel correction on OSC nor mono data, I never use this myself because the automatic BPM with dithering combined always works perfectly with different camera's and telescopes and it is way more reliable than cosmetic correction algortihms in general I think.

Regarding the hot kappa for the BPM, if you set it too low like a value of 2.0 or lower, then yes, you will start to get ugly artifacts, too many pixels are indicated then to be not-linear and thus would need correction, but they should only be seen in the final integration if you have not dithered at all between the frames I would think. If you dither and use outlier rejection, the result should still look very good.

Please share your data if you want me to have a look at what is happening 😉

https://upload.astropixelprocessor.com/

username: upload3

password: upload3

Please let me know once uploaded.

Kind regards,

Mabula


ReplyQuote
(@petercpc)
Red Giant Customer
Joined: 3 years ago
Posts: 62
September 30, 2020 08:37  

Re dithering. I always dither when using my Canon and BYE. However, when using my cooled ASI533 i find that noise is not such an issue and have been using it without dithering to save time on capturing lights. I use Sharpcap generally with the ASI533 and, so far, I can see no way to dither unless I do live stacking which is not something I do. I would rather stack in APP.

Peter


ReplyQuote
(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 30, 2020 09:56  

Mabula and Vincent, Thank you for the reply! I checked my dithering with the ASI533MC and it appears it is ON in Stellarmate/EKOS/KStars (and it says it is dithering) but PHD2 is not receiving the commands! So this is it. Thank you for your help. Will have to sort this out in EKOS>PHD2 then.


(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 30, 2020 10:00  

@petercpc Also Turning off local normalization rejection in the integration TAB got rid of almost all of these pixels. So when not dithering this seems like a reasonable solution for now.


ReplyQuote
(@vincent-mod)
Quasar Admin
Joined: 3 years ago
Posts: 2469
September 30, 2020 10:03  

@xs4allan Excellent! I learned something as well as I didn't know some sensors might "misbehave" in this manner. 🙂


xs4allan liked
ReplyQuote
(@mabula-admin)
Quasar Admin
Joined: 4 years ago
Posts: 2470
September 30, 2020 14:19  
Posted by: @petercpc

Re dithering. I always dither when using my Canon and BYE. However, when using my cooled ASI533 i find that noise is not such an issue and have been using it without dithering to save time on capturing lights. I use Sharpcap generally with the ASI533 and, so far, I can see no way to dither unless I do live stacking which is not something I do. I would rather stack in APP.

Peter

Dear Peter @petercpc, @xs4allan , @vincent-mod

Still, dithering is highly recommended allthough visually you think that it is okay not to do it because off less obvious noise patterns.

Any sensor has patterns that are bigger then several pixels large... only by dithering several pixels you will be able to completely get rid of that when you integrate your frames.

Noise analysis always confirms this, noise will go down more efficient in the integration if you dither ;-). If you don't dither, yes you will save some time, but your end result might still have higher noise with more exposure time because the patterns are burnt into the integration... I can not see a good reason not to dither to be honest 😉 It really improves the results and you will get far less issues like this. If your mount is slow with dithering, okay, maybe reduce the dither step somewhat so it goes quicker, but in my experience, you always want the dither step to be at least several pixels to get the best noise reduction. On my asi1600mm-c I dither 30-50 pixels even. If I do only 3-5 pixels, noise is not dropping as efficient and I have tested this on multiple datasets. If I don't dither, the result immediately is rather bad in terms of noise reduction. The difference is a factor of 10-40% in some cases, which is very clear to the eye.

Let me know if this makes sense,

Mabula

 


ReplyQuote
(@petercpc)
Red Giant Customer
Joined: 3 years ago
Posts: 62
September 30, 2020 14:41  

@mabula-admin

Hi Mabula

Yes, that makes perfect sense. As I said I am still trying to find a way to get Sharpcap to dither. If not I may be forced to use APT which I find unnecessarily complicated to use. If only BYE made an application for ZWO cameras.

Peter


ReplyQuote
(@xs4allan)
White Dwarf Customer
Joined: 7 months ago
Posts: 17
September 30, 2020 18:10  

@petercpc N.I.N.A. is free and also good software to image with.


ReplyQuote
(@petercpc)
Red Giant Customer
Joined: 3 years ago
Posts: 62
October 1, 2020 08:06  

@xs4allan

I find NINA even more complicated than APT.


ReplyQuote
Page 2 / 2
Share: