› Forums › Spectroscopy › DEFECT Map
- This topic has 2 replies, 3 voices, and was last updated 8 years ago by Grant Privett.
-
AuthorPosts
-
29 November 2016 at 5:24 pm #573642
I need some help in loading the defect map in ISIS. I understood a defect map correction was to first identifty the defect columb or pixel sites and because they pass through the calbration process un-detected a process is necessary to detect them.
The correction process is to over right the defective pixels by replacing them with neighbouring areas with similar values,
I have never found this necessary during an imaging run.
am I missing something?
29 November 2016 at 11:58 pm #577693Robin LeadbeaterParticipantHi Nick
The defect (or cosmetic as it is called in ISIS) map is to catch the hot and warm pixels which will have unreliable values after the dark subtraction (ie the pixels will either already be saturated or will become prematurely saturated during the exposure, so the dark subtraction will not work correctly.) The same procedure is sometimes used in imaging where it prevents dark holes appearing in the image after dark subtraction where fully saturated hot pixels are for example. The cosmetic file is generated from the master dark and a threshold is set above which the pixels are considered defective. I have mine set to 500 currently which is well above the noise and generates around 100 pixels in a 10 min exposure with my ATK314
Cheers
Robin
30 November 2016 at 9:55 am #577694Grant PrivettParticipantYep. Defect pixels are those that cannot be relied on: being either too sensitive, too insensitive or just plain whacky in their behaviour. When a chip contains that many pixels its not surprising that a few are not perfect.
I also tend to create my defect map using the master dark. I measure the standard deviation and image background (Statistics option if using AstroArt) of the dark and then set the threshold at background + 5 x standarddev. The Starlight 694 I use doesn’t have many defective pixels and that usually cleans them up. My approach is overkill perhaps, but its adaptive and does lend itself to processing automation – I still sometimes use the Starlink CCDPACK image reduction system under Linux.
But if you always use the same camera temperature and binning, then a hardwired threshold derived by experiment should be fine – as Robin has found.
-
AuthorPosts
- You must be logged in to reply to this topic.