[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "A method for optimal image subtraction" on TASS WWW site
- To: Chris Albertson <chris@topdog.pas1.logicon.com>
- Subject: Re: "A method for optimal image subtraction" on TASS WWW site
- From: hjohnson@pluto.njcc.com (Herbert R Johnson)
- Date: Wed, 14 Jan 1998 13:46:26 -0500
- Cc: tass@wwa.com
- In-Reply-To: <34BC4528.F9A3AC49@topdog.logicon.com>
- Old-Return-Path: <hjohnson@pluto.njcc.com>
- Organization: NJ Computer Connection for Astro Imaging Systems
- Reply-To: hjohnson@pluto.njcc.com
- Resent-Date: Wed, 14 Jan 1998 17:07:12 -0500
- Resent-From: tass@wwa.com
- Resent-Message-ID: <"6cFQnB.A.O7.89Sv0"@kani.wwa.com>
- Resent-Sender: tass-request@wwa.com
On Tue, 13 Jan 1998 20:55:04 -0800, Chris Albertson <chris@topdog.pas1.logicon.com> wrote:
*>Herbert R Johnson wrote:
*>>
*>> I believe I've also "called out" simple image comparisons before for
*>> TASS data. I'm sure the paper reference offers a more robust method.
*>
*>Herb,
*>
*>Their "more robust method" seems to address differences in the PSF
*>and in seeing between images. What they do is compute a convolution
*>kernel that when applied to an image results in an image that "matches"
*>a reference image. Then the two can be directly compared. In the
*>paper they give an example of subtracting badly blurred image from
*>a sharper version of the same field. They get just sky noise as the
*>difference.
OK, that makes sense and is not particularly new. So, they use two
images to get more information about the image and about seeing. In a
crude way, image subtraction is a kind of background subtraction: most
of the image is background, y'know. It also subtracts a lot of point
sources, which generally is not useful - but to look for dim objects,
you want the bright ones out of the way. And to look for moving objects,
you want the stable objects out of the way too.
*>Right, The high color index stars will kind of mess this up. I didn't
*>think of that. Maybe the technique would only apply to cameras in
*>the same band or the same camera on diferent nights.
Thanks for confirming this thought.
*>I would not have to re-write a driver in any case. All the driver
*>does now is call a script each time it closes a FITS file. Just
*>edit the script with whatever you want to do to each file. By
*>default the script only prints the FITS filename to the screen.
Well, I meant writing some on-line postprocessor that would have to
be synchronized with the data collection process, as you suggested.
"Driver" was a sloppy reference on my part. More to my point, a
postprocessor program (or algorithm) could be tested without any
reference to TASS data collection before the issues of integrating
it with the TASS collection software. SOme image processing program
or language, for example, could be used to test the concept.
*>One problem is our frames don't line up well at all. They are cut
*>up into short segments of RA and the three cameras are not "in phase".
For testing, we can "hand align" if that makes sense. Presumably an
automated process could use the same algorithms we use to find RA and
dec based on reference stars, at least to the nearest pixel. Again, try
and see what we get: it can't be worse than half a pixel or so...well,
maybe root 2 over 2 (.707), there is always a root 2 in there.....!
*>I had not though of negative pixels either. I guess you'd compute
*>the absolute value or maybe square of the diference
First cut is to do *two* subtractions, A-B and B-A, and cut off the
negative values: that way you retain the information's reference (is it
from A? is it from B?). HOw you integrate the results is the fun part.
(Maybe I should post *my* article? I'll dig it up and give it to Michael
for the Web page.)
*>I think it is a good project for someone with an IP program and
*>lots of free time. For me I'll stick to what I'm doing now.
...and there it is. If I get a chance I'll do the deed with some
recent images. Anyone have a string of images with the following
characteristics:
* two TASS cameras (of the triplet) with the same filter?
* images taken on a nice night with consistent imageing?
* and images taken on a subsequent night (a day or two)
with similar seeing? at similar times of night?
* ...and to look for moving objects, shots in the ecliptic
(RA 12h and RA 0h, where the ecliptic crosses the celestial equator)
which would likely guarantee some asteroids.
If we consider asteroids as the detection target, we can use the color
index of typical asteroids to "integrate" results between different
color images. Asteroids if I recall are in only a few flavors, and are
not great reflectors in general. Hey, sounds like a plan to me.
Herb Johnson
**** ------------------------------------------------------ ****
Herbert R. Johnson voice/FAX 609-771-1503 day/nite
hjohnson@pluto.njcc.com Ewing, in central New Jersey, USA
amateur astronomer and astro-tour guide
supporter of classic S-100 computers as "Dr. S-100"
rebuilder of Mac Plus computers for your computing pleasure
and senior engineer and asteroid spotter at Astro Imaging Systems