2022-01-07: APP 1.083 has been released !!!
- new Star Reducer Tool
- 15-30% speed increase in processing
- introducing Comet registration
- support for new camera models like Canon EOS R5,R6
- Greatly improved HSL Selective Color Tool
- New Batch Tools
- New File Saver Module with PNG support
[Solved] Bad Pixel Map
i purchased a new OSC-Camera (ASI071MC_Pro) and as recommended i started to do a good bad pixel map by taking 100 dark-frames (600sec, gain 0, -5°c) and 100 flats.
But i'm quite shocked about the result:
26,92% of BAD pixels. In the video from sarah i saw here values: 3,325 %!!!
am ii doing something wrong or is this a bad camera!!??
As it usually happens in ALL OSC CMOS cameras, gain 0 is noiser than all other gains. Don't use gain 0.
It's common to use UNITY GAIN: for your camera it is 90 as you can see here:
I found out, that this has nothing to do with the GAIN-value; nearly the same values with Darks Gain 90!! And i also watched a youtube-video from robin glover (
) saying that the 'unity-gain-concept' is a irrelevant one; so i decided to use gain 0.
And also see this post from mabula:
No, the Bad Pixel Map is NOT ISO and exposure dependent. You can make a Bad Pixel Map using any ISO and exposure time and use it on data which have other ISO and exposure times. Just make one Bad Pixel Map using a set of darks with exposure times of several minutes (the longer the better) and an arbitrary ISO value. And the flats used in the BPM creation can have a different ISO and exposure time then those darks, no problem 😉
In both cases (gain 0 / gain 90) i used the values for 'bad kappa' and 'cold pixel percentage' that mabula is using in the example of his post: https://www.astropixelprocessor.com/community/tutorials-workflows/creating-a-bad-pixel-map/
As i don't really understand what this values are doing, for me is was helpful to use these values (cold pixels 50% and hot pixels kappa 2.5)
Today I restarted the whole thing, but this time i didn't change the default values suggested in the actual version of APP: cold pixels 25% and hot pixels kappa 3.0 and the result is a completely different one:
And now i'm completely confused; the idea is to create a very good BPM once in a year (as suggested by mabula)
And now i have this 2 completely different versions; and on top the second one looks quite strange to me compared to the first one (see above)
Maybe this is due to my self made 'flat-box' (a led light-pad from agptek)!?
So which one should i use for the calibration of my flats and my lights??
Would be very nice if someone could help me to clarify my confusions and tell me what to do; thanks in advance!
If a BPM is needed to do the best calibration; waht's the way to create a really good BPM?
Is it to find the best values or to detect a realistic number of so called 'bad pixels' and to apply this to the calibration of the flats and lights, or is it to optimise certain values?
Because when i play aorund a little bit with 'hot pixels kappa' and 'cold pixels percentage' i can find a combination with a maxium of 'number of linear pixels' and a minimum of 'number of bad pixels' ()
but again; what's really the goal to strive for?
Thank you for your answer; i think it must sound a little bit confusing for you!!
But meanwhile i found in another post ("ASI071MC processing") that it is needed to enable "force CFA" for these frames in 0) RAW/FITS!!
Coming from DLSR -and as a beginner- it was new for me or to be precise in the APP Tipp-Text to this topic it says: "Enable this if the frames are monochrome Bayer CFA frames..."; and i thought that the frames of a OSC-Camera are NOT monochrome because it is a One-Shot-COLOR camera (like DSLR)!!??
So again it's the same topic of a 'missing documentation/manual of the ACTUAL APP-Version' 🙁
But now i tried it again with this option enabled and i managed to get a 'better' or maybe 'correct' BPM and to find out the 'Hot-Pixels-Kappa-Value' that corrects all bad pixels -as it is mentioned in the post 'Creating a BPM' (from Mabula but from 2017!!)- means it stays the same value from there on (i hope that's the correct way); the cold pixel percentage is always 0!