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.
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 weeks 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 weeks 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.
