2023-04-17: APP 2.0.0-beta17 has been released !
RAW support for camera color matrix with Bayer Drizzle integration, fixed couple of image viewer issues.
We are very close now to releasing APP 2.0.0 stable with a complete printable manual...
Astro Pixel Processor Windows 64-bit
Astro Pixel Processor macOS Intel 64-bit
Astro Pixel Processor macOS Apple M Silicon 64-bit
Astro Pixel Processor Linux DEB 64-bit
Astro Pixel Processor Linux RPM 64-bit
Structures in the background
I stacked my first picture in APP, and I am very satisfied with the result for the first time. But something struck me and I hope that a solution will be found. In the dark background of the picture I find several dark structures which stand out.
Can these be eliminated by the stacking? Maybe I have a wrong setting inside? Here is a crop from the picture:
It happens regularly and quite always to me.
Try with bad pixel map, instead of darks. For me it works. And works always better.
Darks always don't calibrate correctly and completeley 100% the lights: instead, BPM corrects them very well.
But BPM is made of the same darks: so no much sense. I don't know why.
Hi Dane @dv_stranger & @ippiu,
Can you be more specific, because I can't tell from the image what the problem seems to be. The image has very low quality due to JPG compression.
Best to zoom all the way in with APP on the problem and then make a screenshot ?
If you refer however to black pixel holes, than they are caused by hot pixels in the MasterDark that overcorrect when applying MasterDark calibration. And that will be solved if you start using a Bad Pixel Map 😉 The Bad Pixel Map works completely different than a MasterDark. It corrects the bad pixels by interpolating surrounding good pixels. To be able to find the bad pixels, darks are needed though.
And you can use both a MasterDark and Bad Pixel Map. Or only a Bad Pixel Map. There is no good reason not to use a Bad Pixel Map, create one and use it on all of your data.
Exactly, @mabula-admin, i did this regularly. I learnt this method by myself experimenting a lot with APP: i didn't know the theory, as you described above. But you said exactly what i'm doing now every time i calibrate an image: i use only BPM, not darks anymore.
After many tests and side by side monitor comparison at 100%, i came to final conclusion that BPM works best and well, compared to using just darks.
So i'm building a new BPM library made of only darks and not flats too (because i did many tests using also flats but my camera, asi533, doesn't have any cold pixel): exposure / gain starting from 600s / gain 100 21 darks....to 60 s / gain 300 55 darks (for live stacking quick EAA sessions). Every BPM created from each combination of exposure / gain has different noise level: ranging from 1,4 % until 2,3 %, with just only one BPM that has only 0,08% (for me this is an error: i have to redo it).
Thanks @mabula-admin for this wonderful piece of software
Ps. I look forward to having in APP: noise reduction tool, and many other tools...
Bad Pixel Map is activatet. At APP, this structures are really weak. I looks like this:
They will get stronger when im darken the bright background in photoshop. Like this:
If I brighten the picture extremely, you can see that more clearly what i mean:
You probably mean the dark "bands"? Those are irregularities in the background data, usually a result of having some form of light pollution which isn't corrected completely. If it's not an actual gradient, removing that will be quite hard, but you can have a go with the light pollution tool and use it on that final over-stretched image, I do it like that as well to be able to judge if it worked well.
I collected in the last night some more lights and i stacket it again and i also use the calibrate background and remove light pollution tool. But i have the same problem like on my example before. These dark spots are now in other positions.
Why its not possible to set the background to a homogeneous area? These dark spots really don't look good. It looks uneven. Are these dark bands? i dont know?
I must say that I'm not seeing the issue at the spot of the arrow. Maybe because of jpeg compression? How does the uncompressed full fits image look like?
Me too...i couldn't see any significant spots that compromises final image quality. I think he refers to normal background issues. I have always disomogeneous background spots, but only if i zoom to more than 100%: it's normal, it's a mix of gradient, light pollution, dark current, hot pixel removal, etc....
That could be yes, a background will never be 100% even, the correction of the background with various tools can only do so much, if it would be too aggressive you will get worse artefacts or loose valuable data in the background. Noise and a bit of uneven background remains part of the game, you can get that down to a very nice level, when you're taking data from a really dark sky.
Thanks for your answers. Maybe I look too closely and a really homogeneous background is not possible. But maybe I still have a reason for the result. The photo was taken over several nights, and each time at the beginning of the shooting, the first ones still have a high brightness because the object was still close to the horizon. I think this is a big problem, or does the software take this into consideration automatically?
Would it be better to exclude the upper half of the photos from stacking? In spite of the brightness there is also information which is helpful for stacking?
No that's not a big problem, ofcourse it would be better if you take the entire session when the sky is at its darkest for that night (the darker the more signal and the better the background), but APP will correct the background and make them even across all frames. Do you use LNC in the integration tab? This will also help a bit. You can test it, by removing that first row you showed above and check the result.
I will remove the first very bright pictures and try again. But its good to know that its not a big problem and APP will correct them.
Yes I use LNC 1 Degree. Should i better try another one?
You can always experiment a bit, maybe 2 iterations, but I don't see major issues in your data so I don't think it will make a big difference to be honest.