15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
I have just finished the integration of 25 300s lights together with 20 darks, 20 bias, flats and dark flats. the final image is good BUT I am noticing some strange hot pixels. Strange because they are elongated whereas in the BPM they are square. See attached.
Any idea why these hot pixels are in the image and why they are elongated? Sorry i can't work out how to delete duplicate attachments.
I have just posted exactly the same problem for my integrations. Was able to remove these with creating a new BPM with a kappa high of 2.0 but it created even worse artifacts around the stars.
The elongated "hot" pixels are even worse when you do a drizzle integration. Tried all different sorts of integration rejections etc.
With a different BPM (Kappa 2) I got these
This post was modified 4 years ago 2 times by xs4allan
Ok so it worked for 90% because these elongated (hot) pixels keep popping up. Only got rid of the blue and red ones. Green ones still present. Such a strange problem...
1 has the (hot) pixels with higher kappa masters
2 has the strange star artefacts with the lower kappa masters
This post was modified 4 years ago 2 times by xs4allan
I think I finally fixed the problem (for me at least). Did it by creating new darks with these kappa settings (lower kappa high) and BPM to automatic.
Going to test a 2x drizzle with these settings. Will come back on that test.
I just tried again using those settings and it has removed all the odd hot pixels apart from 1. As regards the BPM i set this to enable, otherwise it would use an existing BPM. This is something that APP need to sort out.
And your stars are intact in a direct comparison? Because I dont think mine is an improvement if the star borders keep producing these artifacts that are definitely not necessary.
When I first did the integration for this one, it had loads of the weird hot pixels. This is the latest integration using the above method. Stars look good I think.
I found another way to make all the noise and artifacts go away. (at least in my images who had this strange Walking hot pixel noise whit under sampled dithered 2x drizzle integrations.) They can now be integrated fine. Only had to fine tune how much cosmetic correction it could take without destroying good data.
Well done. Thanks for all your input and help. I still think that there is a defect in APP for this to be necessary at all. I hope Mabula sees this and looks into it further.
I totally agree! I have subs from 2 evenings / different objects 1 not showing these artefacts with the same calibration masters and BPM. Tried a lot of different things and the strange thing is indeed that the BPM shows the pixels but in the integration they tend to be elongated.
PS. Correction on the Cosmetic correction as a help. You should start at a much higher number to prevent the destruction of (especially) stars on nebulae background. I rather have these weird looking artefacts instead of weird stars.
Hope APP will get this thing corrected. I see a lot more forum posts about this subject popping up now.
This is unlikely an issue with APP itself, we tested these algorithms a lot and people don't have these issues normally. So the more likely answer is a data issue, most likely with the darks. When you just take a single light sub, add the masterdark and BPM and then go to the top and select "l-calibrated". Do you see all hot pixels removed from that one sub? If not, try to zoom in on such a hot pixel that isn't removed and load the masterdark, check if you see a hot pixel on that location, same with the BPM.
ps. I say "unlikely", not "there is definitely no APP issue". But from experience, it almost always turned out to be the data. 😉
I did that. On the single light calibrated sub I zoomed in on a bad pixel. When I loaded the MD it was not there, when I loaded the BPM it was not there either.
So that points to the dark not having the pixels, APP isn't removing them if it doesn't actually have data for them and the BPM is based on the dark. It's strange the 10 min dark is not showing them either, the settings for those were the same as the lights? It might be interesting to make a dark of 20 min.
So that points to the dark not having the pixels, APP isn't removing them if it doesn't actually have data for them and the BPM is based on the dark. It's strange the 10 min dark is not showing them either, the settings for those were the same as the lights? It might be interesting to make a dark of 20 min.
The settings for the 10 min dark was the same as the 300s dark apart from exposure time. If these hot pixels are not showing on the darks then why do they appear on the integration? It suggests that APP are generating them. Also, bear in mind that these strange pixels are elongated unlike normal hot pixels. I'm not going to pursue this any further as the above settings seem to work. I still think that there is something going on in APP to make it generate these strange hot pixels. I see several posts about it.
No, APP is never generating hot pixels, that's simply not programmed into it (which would indeed be weird). The fact that the changing of the clipping settings works and that you don't have them in the darks, suggests a data issue. Anyway, it seems you solved it by doing that, if it happens again or worsens somehow, I'd love to have another look.
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.
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 years ago by Roman Pearah
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.
(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?
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)
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 😉
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.
