Dear all, I am trying to process images which are coming from a frame transfer CCD with electron multiplication which is shooting pictures at the sky during the night. My task is to find the stars within the picture and calculate their position - relative to the CCD coordinates - and magnitude. From time to time the raw image looks like showing a big difference of illumination between columns, as if their amplification is different. I tried to evaluate the mean on each column and subtract it from each pixel of that column, but the result is not really good. Does anyone know about any technique that address this specific issue? So far I have not been able to even *name* the issue and I'm afraid is a feature of our hardware. Thanks in advance, Al p.s.: I'm in the process of implementing a median filter and/or a gaussian filter to remove some 'salt and pepper noise' that I have in addition to what I mentioned and maybe the situation will be different afterward. -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?
column problem in image processing
Started by ●April 28, 2012
Reply by ●April 29, 20122012-04-29
On Apr 28, 11:21�am, alb <alessandro.bas...@cern.ch> wrote: (snip).> My task is to find the stars within the picture and calculate their > position - relative to the CCD coordinates - and magnitude. > From time to time the raw image looks like showing a big difference of > illumination between columns, as if their amplification is different. > > I tried to evaluate the mean on each column and subtract it from each > pixel of that column, but the result is not really good. > > Does anyone know about any technique that address this specific issue? > So far I have not been able to even *name* the issue and I'm afraid is a > feature of our hardware.Could be a problem called blooming (common for CCDs). Google "CCD + astronomy + blooming" and you'll find quite a few hits, such as: http://www.astrophys-assist.com/educate/noise/noise.htm http://www.badastronomy.com/bad/misc/planetx/soho.html search the above for the sections on blooming. Plus, there are links at: http://www.astroimages.org/astrlink.html There are software approaches for dealing with the problem - you should be able to find some links to see how other people handle it. Kevin McGee
Reply by ●April 29, 20122012-04-29
On 4/29/2012 6:25 AM, kevin wrote:> On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: > > (snip). >> My task is to find the stars within the picture and calculate their >> position - relative to the CCD coordinates - and magnitude. >> From time to time the raw image looks like showing a big difference of >> illumination between columns, as if their amplification is different.[...]> > Could be a problem called blooming (common for CCDs). Google "CCD + > astronomy + blooming" and you'll find quite a few hits, such as: >Thanks for the pointers, but unfortunately is not a problem of blooming. I uploaded a sample of the picture I'm talking about here: http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png As you may see there is some stray light coming in and from the histogram on the right it is clear that something is wrong with the column projection (mean of the column). Even though there are a couple of 'stars' (many more indeed), their brightness is rather dim compared to the surrounding noise and hard to find if the columns are not equalized first (I'm not sure is the right term here). On the bottom of the screenshot it is shown some info about the image and if you compare the sigma of the last one w.r.t. the ones taken @04:56:41 they differ a lot (~300 vs ~20). So any threshold which is based on the sigma will likely fail to find the star.> There are software approaches for dealing with the problem - you > should be able to find some links to see how other people handle it. >We have also some blooming effect which needs to be addressed, but as you said there are several approaches to address this issue.> Kevin McGee >
Reply by ●April 30, 20122012-04-30
> On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote:> Thanks for the pointers, but unfortunately is not a problem of blooming. > I uploaded a sample of the picture I'm talking about here: > > http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png > > As you may see there is some stray light coming in and from the > histogram on the right it is clear that something is wrong with the > column projection (mean of the column). > > Even though there are a couple of 'stars' (many more indeed), their > brightness is rather dim compared to the surrounding noise and hard to > find if the columns are not equalized first (I'm not sure is the right > term here). > > On the bottom of the screenshot it is shown some info about the image > and if you compare the sigma of the last one w.r.t. the ones taken > @04:56:41 they differ a lot (~300 vs ~20). So any threshold which is > based on the sigma will likely fail to find the star.Yes, it doesn't look like blooming. I can see many faint points of light in the image you provided, but, as you said, they are very dim compared to the noise. Not what I would expect. And that sigma variation is worrysome. I think the first link in my previous post (re: noise) mentions a number of noise sources that you'd only be able to diminish by calibrating your sensor (as mentioned in the link: master bias frame for read noise; dark frame for reduction of thermal noise; etc.). Unfortunately, I don't have a lot of experience regarding calibration of CCDs. I've visited a number of university astronomy departments over the years, and have used CMOS sensors in the 1980's, but my specific interests were not in CCDs. Given the large number of astronomy related sites, some of which are devoted to CCDs, you might ask at those sites to find someone who can more quickly identify your problem and help you solve it. My (inexperienced) guess is that it's related to calibration. Those alternating light/dark lines in your image don't look anything like the 'master dark frame' shown in the picture 'Example of a typical dark frame' in the first link. And I wouldn't expect the histogram of the column to show such a bias. Kevin McGee
Reply by ●April 30, 20122012-04-30
On 4/30/2012 7:11 AM, kevin wrote:> > On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: >> Thanks for the pointers, but unfortunately is not a problem of blooming. >> I uploaded a sample of the picture I'm talking about here: >> >> http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png >> >> As you may see there is some stray light coming in and from the >> histogram on the right it is clear that something is wrong with the >> column projection (mean of the column). >> >> Even though there are a couple of 'stars' (many more indeed), their >> brightness is rather dim compared to the surrounding noise and hard to >> find if the columns are not equalized first (I'm not sure is the right >> term here). >> >> On the bottom of the screenshot it is shown some info about the image >> and if you compare the sigma of the last one w.r.t. the ones taken >> @04:56:41 they differ a lot (~300 vs ~20). So any threshold which is >> based on the sigma will likely fail to find the star. > > Yes, it doesn't look like blooming. I can see many faint points of > light in the image you provided, but, as you said, they are very dim > compared to the noise.Currently we are shooting 5 images in a row (130 ms each) and then transmit them to ground. We don't have more space on board than that. The sequence of 5 images allow us to clearly see objects moving, therefore we are pretty confident that those dim points are stars. The problem is how to make the software recognize them as stars. The system should be capable of recognize the star, calculate the position w.r.t. the CCD coordinates and transmit only a pair of numbers for each object instead of the whole raw image. Not what I would expect. And that sigma> variation is worrysome.Indeed. There are pictures which don't have so much noise and even though the 'salt and pepper' noise is rather significant, it should not be a problem to remove it. By the way, does anybody know how much a median filter would take on a 50MHz dsp if the image is 512x512 pixels? I know about an implementation which is O(1) (http://nomis80.org/ctmf.html) and does not depend on the dimension of the kernel, but I have no feeling how that is suitable for my dsp. I think the first link in my previous post> (re: noise) mentions a number of noise sources that you'd only be able > to diminish by calibrating your sensor (as mentioned in the link: > master bias frame for read noise; dark frame for reduction of thermal > noise; etc.).It looks to me that this effect is present only when there's stray light coming in the CCD (which happens unfortunately).> > Given the large number of astronomy related sites, some of which are > devoted to CCDs, you might ask at those sites to find someone who can > more quickly identify your problem and help you solve it. My > (inexperienced) guess is that it's related to calibration. Those > alternating light/dark lines in your image don't look anything like > the 'master dark frame' shown in the picture 'Example of a typical > dark frame' in the first link. And I wouldn't expect the histogram of > the column to show such a bias.Indeed we don't even have a 'dark frame' since we don't have a shutter and we cannot take a dark picture. The CCD is a frame transfer one and was chosen for the possibility to avoid the presence of a shutter and therefore add complexity to the system... leaving the problems to the software guy!> > Kevin McGee
Reply by ●May 1, 20122012-05-01
On Apr 30, 8:16�am, alb <alessandro.bas...@cern.ch> wrote:> On 4/30/2012 7:11 AM, kevin wrote: > > > > > > > �> On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: > >> Thanks for the pointers, but unfortunately is not a problem of blooming. > >> I uploaded a sample of the picture I'm talking about here: > > >>http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png > > >> As you may see there is some stray light coming in and from the > >> histogram on the right it is clear that something is wrong with the > >> column projection (mean of the column). > > >> Even though there are a couple of 'stars' (many more indeed), their > >> brightness is rather dim compared to the surrounding noise and hard to > >> find if the columns are not equalized first (I'm not sure is the right > >> term here). > > >> On the bottom of the screenshot it is shown some info about the image > >> and if you compare the sigma of the last one w.r.t. the ones taken > >> @04:56:41 they differ a lot (~300 vs ~20). So any threshold which is > >> based on the sigma will likely fail to find the star. > > > Yes, it doesn't look like blooming. �I can see many faint points of > > light in the image you provided, but, as you said, they are very dim > > compared to the noise. > > Currently we are shooting 5 images in a row (130 ms each) and then > transmit them to ground. We don't have more space on board than that. > The sequence of 5 images allow us to clearly see objects moving, > therefore we are pretty confident that those dim points are stars. The > problem is how to make the software recognize them as stars. The system > should be capable of recognize the star, calculate the position w.r.t. > the CCD coordinates and transmit only a pair of numbers for each object > instead of the whole raw image. > > Not what I would expect. �And that sigma > > > variation is worrysome. > > Indeed. There are pictures which don't have so much noise and even > though the 'salt and pepper' noise is rather significant, it should not > be a problem to remove it. > > By the way, does anybody know how much a median filter would take on a > 50MHz dsp if the image is 512x512 pixels? I know about an implementation > which is O(1) (http://nomis80.org/ctmf.html) and does not depend on the > dimension of the kernel, but I have no feeling how that is suitable for > my dsp. > > � I think the first link in my previous post > > > (re: noise) mentions a number of noise sources that you'd only be able > > to diminish by calibrating your sensor (as mentioned in the link: > > master bias frame for read noise; dark frame for reduction of thermal > > noise; etc.). > > It looks to me that this effect is present only when there's stray light > coming in the CCD (which happens unfortunately). > > > > > Given the large number of astronomy related sites, some of which are > > devoted to CCDs, you might ask at those sites to find someone who can > > more quickly identify your problem and help you solve it. �My > > (inexperienced) guess is that it's related to calibration. �Those > > alternating light/dark lines in your image don't look anything like > > the 'master dark frame' shown in the picture 'Example of a typical > > dark frame' in the first link. �And I wouldn't expect the histogram of > > the column to show such a bias. > > Indeed we don't even have a 'dark frame' since we don't have a shutter > and we cannot take a dark picture. The CCD is a frame transfer one and > was chosen for the possibility to avoid the presence of a shutter and > therefore add complexity to the system... leaving the problems to the > software guy! > > > > > > > Kevin McGee- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text -Without a shutter, it would seem to be difficult to calibrate the CCD. The link below shows an uncalibrated vs. calibrated image: http://www.astrophoto.net/calibration.php and a few more here: http://starizona.com/acb/ccd/software/maxim_calibrate.aspx You can also search for "calibrate CCD image sensor" and find quite a few hits. When working with CMOS sensors, I used a cheap camera for the optics and shutter - no cooling, so I had some thermal noise problems, plus nonuniform illumination (due to differences in oxide thickness?), etc. So I had some of the same problems as with a CCD, and calibration was a needed step. (CCD and CMOS link shown below:) http://www.axis.com/files/whitepaper/wp_ccd_cmos_40722_en_1010_lo.pdf I'm not exactly sure you'd go with a median filter (thanks for the link - O(1) is quite interesting). I don't know if that's common or typical with CCDs. You might consider contacting the manufacturer of your CCD - perhaps they have some suggestions that you could try (or maybe point you to some software that they know of). Once again, the astronomy community has some expertise in this area, so it would be helpful to seek them out. Kevin McGee
Reply by ●May 1, 20122012-05-01
On Mon, 30 Apr 2012 14:16:02 +0200, alb wrote:> On 4/30/2012 7:11 AM, kevin wrote: >> > On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: >>> Thanks for the pointers, but unfortunately is not a problem of >>> blooming. I uploaded a sample of the picture I'm talking about here: >>> >>> http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png >>> >>> As you may see there is some stray light coming in and from the >>> histogram on the right it is clear that something is wrong with the >>> column projection (mean of the column). >>> >>> Even though there are a couple of 'stars' (many more indeed), their >>> brightness is rather dim compared to the surrounding noise and hard to >>> find if the columns are not equalized first (I'm not sure is the right >>> term here). >>> >>> On the bottom of the screenshot it is shown some info about the image >>> and if you compare the sigma of the last one w.r.t. the ones taken >>> @04:56:41 they differ a lot (~300 vs ~20). So any threshold which is >>> based on the sigma will likely fail to find the star. >> >> Yes, it doesn't look like blooming. I can see many faint points of >> light in the image you provided, but, as you said, they are very dim >> compared to the noise. > > Currently we are shooting 5 images in a row (130 ms each) and then > transmit them to ground. We don't have more space on board than that. > The sequence of 5 images allow us to clearly see objects moving, > therefore we are pretty confident that those dim points are stars. The > problem is how to make the software recognize them as stars. The system > should be capable of recognize the star, calculate the position w.r.t. > the CCD coordinates and transmit only a pair of numbers for each object > instead of the whole raw image. > > Not what I would expect. And that sigma >> variation is worrysome. > > Indeed. There are pictures which don't have so much noise and even > though the 'salt and pepper' noise is rather significant, it should not > be a problem to remove it. > > By the way, does anybody know how much a median filter would take on a > 50MHz dsp if the image is 512x512 pixels? I know about an implementation > which is O(1) (http://nomis80.org/ctmf.html) and does not depend on the > dimension of the kernel, but I have no feeling how that is suitable for > my dsp. > > I think the first link in my previous post >> (re: noise) mentions a number of noise sources that you'd only be able >> to diminish by calibrating your sensor (as mentioned in the link: >> master bias frame for read noise; dark frame for reduction of thermal >> noise; etc.). > > It looks to me that this effect is present only when there's stray light > coming in the CCD (which happens unfortunately).Do you know the physics behind where that's coming from? Before I saw your statement about it only happening in the presence of stray light, I was thinking that it looks like garden-variety nonuniformity on an IR CCD. But if it's only happening when you're getting stray light then either there's something about the physics of the detector that you're using that's letting the stray light "bleed" into the picture nonuniformly, or (perhaps more likely) there's some deficiency in the way that the CCD is calibrated, or the way that the calibration is used, that is messing up your picture. How _is_ the imager calibrated?>> Given the large number of astronomy related sites, some of which are >> devoted to CCDs, you might ask at those sites to find someone who can >> more quickly identify your problem and help you solve it. My >> (inexperienced) guess is that it's related to calibration. Those >> alternating light/dark lines in your image don't look anything like the >> 'master dark frame' shown in the picture 'Example of a typical dark >> frame' in the first link. And I wouldn't expect the histogram of the >> column to show such a bias. > > Indeed we don't even have a 'dark frame' since we don't have a shutter > and we cannot take a dark picture. The CCD is a frame transfer one and > was chosen for the possibility to avoid the presence of a shutter and > therefore add complexity to the system... leaving the problems to the > software guy!There should be an electro-optical egghead helping you out with this, in a well-formed project team. If not -- start eating eggs. -- My liberal friends think I'm a conservative kook. My conservative friends think I'm a liberal kook. Why am I not happy that they have found common ground? Tim Wescott, Communications, Control, Circuits & Software http://www.wescottdesign.com
Reply by ●May 1, 20122012-05-01
On Saturday, April 28, 2012 11:21:24 AM UTC-4, alb wrote:> Dear all, > > I am trying to process images which are coming from a frame transfer CCD > with electron multiplication which is shooting pictures at the sky > during the night. > > My task is to find the stars within the picture and calculate their > position - relative to the CCD coordinates - and magnitude. > From time to time the raw image looks like showing a big difference of > illumination between columns, as if their amplification is different. > > I tried to evaluate the mean on each column and subtract it from each > pixel of that column, but the result is not really good. > > Does anyone know about any technique that address this specific issue? > So far I have not been able to even *name* the issue and I'm afraid is a > feature of our hardware. > > Thanks in advance, > > Al > > p.s.: I'm in the process of implementing a median filter and/or a > gaussian filter to remove some 'salt and pepper noise' that I have in > addition to what I mentioned and maybe the situation will be different > afterward. > > -- > A: Because it fouls the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing on usenet and in e-mail?Several questions: Do the same columns exhibit the same bias from capture to capture? If not, you may have a read noise problem here - try reading the array slowly! Same cameras in order to read the data quickly have multiple read paths each with its own biases. However these stripes occur in a regular pattern. Yours seem to be irregular. However if the biases are consistant, a dark frame may be used (and they should always be used along with flat frames in astrophotometry) to remove them. If not, then you can treat each column as a mostly flat line with occasional blips. This isn't a good place to start accurate astrophotometry. Have you shot any dark frames and subtracted them out? Clay
Reply by ●May 1, 20122012-05-01
On Sun, 29 Apr 2012 11:25:49 +0200, alb <alessandro.basili@cern.ch> wrote:> On 4/29/2012 6:25 AM, kevin wrote: >> On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: >> >> (snip). >>> My task is to find the stars within the picture and calculate >>> their position - relative to the CCD coordinates - and magnitude. >>> From time to time the raw image looks like showing a big >>> difference of illumination between columns, as if their >>> amplification is different.[...]> Thanks for the pointers, but unfortunately is not a problem of > blooming. I uploaded a sample of the picture I'm talking about > here: > > http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png > > As you may see there is some stray light coming in and from the > histogram on the right it is clear that something is wrong with the > column projection (mean of the column). > > Even though there are a couple of 'stars' (many more indeed), their > brightness is rather dim compared to the surrounding noise and hard > to find if the columns are not equalized first (I'm not sure is the > right term here).Curious... I loaded a copy of the image into The GIMP and played with the Brightness-Contrast controls (B=+10,C=+120). The result was a lot of star-like points against a very black background. Given that the original looked rather uniformly grey and stripey, I found this surprising. If you were aimed at Ursa Minor (or some similar shape) this may be helpful. On the other hand, if you aere aimed at, say, Orion, well, feel free to ignore this interruption. <grin!> Frank McKenney -- Gallipoli illustrates a principle which began to be apparent in European wars as early as the Armada. It is that distance lends enchantment to the most crackbrained strategic ideas. Not that the high command or the home public is any less well informed about operations in distant theaters. All the necessary facts may be at hand; they simply lack urgency; the imagination has freer play with them. -- Charles Fair / From the Jaws of Victory -- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney aatt mindspring ddoott com
Reply by ●May 2, 20122012-05-02
On Mon, 30 Apr 2012 21:56:39 -0700, kevin wrote:> On Apr 30, 8:16 am, alb <alessandro.bas...@cern.ch> wrote: >> On 4/30/2012 7:11 AM, kevin wrote: >> >> >> >> >> >> > > On Apr 28, 11:21 am, alb <alessandro.bas...@cern.ch> wrote: >> >> Thanks for the pointers, but unfortunately is not a problem of >> >> blooming. I uploaded a sample of the picture I'm talking about here: >> >> >>http://ams.cern.ch/AMS/Basili/Docs/snapshot1.png >> >> >> As you may see there is some stray light coming in and from the >> >> histogram on the right it is clear that something is wrong with the >> >> column projection (mean of the column). >> >> >> Even though there are a couple of 'stars' (many more indeed), their >> >> brightness is rather dim compared to the surrounding noise and hard >> >> to find if the columns are not equalized first (I'm not sure is the >> >> right term here). >> >> >> On the bottom of the screenshot it is shown some info about the >> >> image and if you compare the sigma of the last one w.r.t. the ones >> >> taken @04:56:41 they differ a lot (~300 vs ~20). So any threshold >> >> which is based on the sigma will likely fail to find the star. >> >> > Yes, it doesn't look like blooming. I can see many faint points of >> > light in the image you provided, but, as you said, they are very dim >> > compared to the noise. >> >> Currently we are shooting 5 images in a row (130 ms each) and then >> transmit them to ground. We don't have more space on board than that. >> The sequence of 5 images allow us to clearly see objects moving, >> therefore we are pretty confident that those dim points are stars. The >> problem is how to make the software recognize them as stars. The system >> should be capable of recognize the star, calculate the position w.r.t. >> the CCD coordinates and transmit only a pair of numbers for each object >> instead of the whole raw image. >> >> Not what I would expect. And that sigma >> >> > variation is worrysome. >> >> Indeed. There are pictures which don't have so much noise and even >> though the 'salt and pepper' noise is rather significant, it should not >> be a problem to remove it. >> >> By the way, does anybody know how much a median filter would take on a >> 50MHz dsp if the image is 512x512 pixels? I know about an >> implementation which is O(1) (http://nomis80.org/ctmf.html) and does >> not depend on the dimension of the kernel, but I have no feeling how >> that is suitable for my dsp. >> >> I think the first link in my previous post >> >> > (re: noise) mentions a number of noise sources that you'd only be >> > able to diminish by calibrating your sensor (as mentioned in the >> > link: master bias frame for read noise; dark frame for reduction of >> > thermal noise; etc.). >> >> It looks to me that this effect is present only when there's stray >> light coming in the CCD (which happens unfortunately). >> >> >> >> > Given the large number of astronomy related sites, some of which are >> > devoted to CCDs, you might ask at those sites to find someone who can >> > more quickly identify your problem and help you solve it. My >> > (inexperienced) guess is that it's related to calibration. Those >> > alternating light/dark lines in your image don't look anything like >> > the 'master dark frame' shown in the picture 'Example of a typical >> > dark frame' in the first link. And I wouldn't expect the histogram >> > of the column to show such a bias. >> >> Indeed we don't even have a 'dark frame' since we don't have a shutter >> and we cannot take a dark picture. The CCD is a frame transfer one and >> was chosen for the possibility to avoid the presence of a shutter and >> therefore add complexity to the system... leaving the problems to the >> software guy! >> >> >> >> >> >> > Kevin McGee- Hide quoted text - >> >> - Show quoted text -- Hide quoted text - >> >> - Show quoted text - > > Without a shutter, it would seem to be difficult to calibrate the CCD. > The link below shows an uncalibrated vs. calibrated image: > > http://www.astrophoto.net/calibration.php > > and a few more here: > > http://starizona.com/acb/ccd/software/maxim_calibrate.aspx > > You can also search for "calibrate CCD image sensor" and find quite a > few hits. > > When working with CMOS sensors, I used a cheap camera for the optics and > shutter - no cooling, so I had some thermal noise problems, plus > nonuniform illumination (due to differences in oxide thickness?), etc. > So I had some of the same problems as with a CCD, and calibration was a > needed step. (CCD and CMOS link shown below:) > > http://www.axis.com/files/whitepaper/wp_ccd_cmos_40722_en_1010_lo.pdf > > I'm not exactly sure you'd go with a median filter (thanks for the link > - O(1) is quite interesting). I don't know if that's common or typical > with CCDs. You might consider contacting the manufacturer of your CCD - > perhaps they have some suggestions that you could try (or maybe point > you to some software that they know of). > > Once again, the astronomy community has some expertise in this area, so > it would be helpful to seek them out. >I'm rusty. Yes, one needs to do a calibration for offset looking at a neutral scene. You can sometimes do this just by defocusing the optics -- but only if the light impinging on the detector is made uniform by doing so. Actually, if it weren't for the stray light problem, given that what you're looking at is essentially a field of black with little bright dots that are guaranteed to be moving, you could average a bunch of frames for your offset correction. Hey, Alb: does what you're seeing have some sort of automatic gain and level applied to it before it gets to you? That may account for why you sometimes see the nonuniformity and sometimes don't. And if it's there -- it's going to greatly complicate your job. -- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
