1.43
#...
·
 |
|---|
|
As I understand it there are two basic appoaches to avoid motion blur when imaging a comet. The first would be to track the stars while exposing, and keeping exposure time short enough so that comet motion during the exposure is negligible. This appears to be the most common method. However, there is also a second way, and that would be to track the comet during exposure. Potentially, this should make it possible to use longer exposures that should give better detail to the core and tail of the comet without risking motion blur. At first sight it would appear that the latter should be the method of choice. However, usually one wants to integrate several exposures. And at this point it seems to me that the second method becomes impractical, because many image stacking softwares cannot handle the images from it, since stars in such images are not points but streaks. And many algorithms seem to be relaying on beeing able to detect both the comet and the stars in the images, which is difficult when the stars are elongated streaks. Can somebody recommend which of the two methods to use? Is there somebody using comet tracking? If so, do you stack the images? How do you do stacking and in what software? I have never used it, but from some tutorials I saw it seems that Pixinsights comet stacking could perhaps do 'comet only' registration and stacking? Regards Ulf Granlund |
7.50
#...
·
·
1
like
|
|---|
|
To answer the first question: I would use (and used) the first method although I knew of few people that locked the auto guider on the comet's nucleus. Nowadays, unless you use an old CCD imager, there is no compelling reason to do that with modern CMOS imagers. To answer the second question: IRIS could easily do that and I suppose would Siril, with the assumption that there is no field rotation between frames. I doubt that PI would be able to do that as it relies on proper PSFs to register the stars and then removed them form the "comet-only" image. |
|
1.43
#...
·
|
|---|
andrea tasselli: Thank you for your answer, Andrea. It is not needed to lock the guider on the comet nucleus to track the comet. PHD2 for example can use stars as guide objects while correcting for the comet motion. I do not really understand why the sensor type would make a difference here, could you please explain that? I would use a DSLR. Regards Ulf. |
|
7.50
#...
·
|
|---|
Thank you for your answer, Andrea. It is not needed to lock the guider on the comet nucleus to track the comet. PHD2 for example can use stars as guide objects while correcting for the comet motion. I do not really understand why the sensor type would make a difference here, could you please explain that? I would use a DSLR. Because of the read-out noise being very low for CMOS and rather large for CCDs. So you can have shorter exposures (ideally, sky-limited) without the traditionally drawback of read-out noise common to CCDs. |
|
1.43
#...
·
|
|---|
|
So assuming that I would use the "short enough" exposure method, what is a suitable exposure time? Given knowledge about the comets angular motion speed ( i.e. arcsec/hour in RA and Dec), how could I conclude on what exposure time to use? /Ulf |
|
7.50
#...
·
|
|---|
It would depend on the image scale you're using to image said comets. My rule of thumb is to allow a maximum of 50% of the image scale as maximum error for each integration. So if you have, say a 1"/px as image scale (s) and the comet's motion is 100"/hour (m) then your exposure time is s*3600/(2*m) in seconds. Hopefully the math is correct...  |
|
1.43
#...
·
|
|---|
|
Ok, thanks. As an example I will calculate for C/2017 K2 Panstarrs. The current motion for this comet is about 76 "/h in Ra and 61"/h in Dec. This gives 97 "/h total. My pixel scale is 1.4 "/pixel. This gives 1.4*3600/(97*2)=26 s. This would seem quite reasonable. However, on Astrobin there are many images of the comet that uses 120 s exposures, and they seem quite OK... And then there is also the factor of seeing.. With my imaging conditions I typically get stars with FWHM in the order of no less than 3". So to require motion of no more than 0.7" feels rather tough.. is it really necessary? Regards Ulf |
|
7.50
#...
·
|
|---|
Ok, thanks. As an example I will calculate for C/2017 K2 Panstarrs. The current motion for this comet is about 76 "/h in Ra and 61"/h in Dec. This gives 97 "/h total. Well, that is up to you. You can replace the pixel scale with the FWHM and I see no harm in it. The rule of thumb is for guidance and needs adapt to circumstances as well as prescribing a minimum value. |
2.86
#...
·
·
1
like
|
|---|
|
Hi, this is a useful topic, that pops up in larger intervals - large enough to forget a lot of what you learned last time. At least for me. Plus, technology is advancing so quickly today, a lot of what i did on C/2020 F3 is now outdated for K2. For my part, not being an experienced comet hunter, i'm usually going for method one - guiding on stars. I remember, there has been some feature in PHD where you could enter the comet's motion, to have PHD follow the comet while guide on stars. This is in my opinion only important, if you really want to resolve small details of the nucleus or so. Also a question of focal length. However, under common conditions i would think any guiding error will be much quicker obvious on the stars. But in the end it is on you, what you want to emphasize. Guiding on the stars has been working well for me so far, comets have been more ore less blurry objects. If you want to take it seriously, on top of the different trajectories there is also the motion in the ion tail happening on short time scales, at least for close comets and unsteady solar wind. There are some really stunning animations around from F3. When i captured K2 last week for the first time, i wasn't prepared at all and started over with my usual deepsky approach. It appeared i had K2's nucleus in the FOV of my guider, which runs PHD and multi-star tracking. I also use a mono camera with a filter wheel, and i perform a re-focus after filter change. So PHD tried to follow two different motions at the same time. I could force PHD to guide on a specific single star on the run, by manually chosing the guide star, but after a filter change it went back into multiple-star tracking mode. I didn't try to switch it off in the menu, and it turned out it didn't cause elongated stars. Beneath exposure time, framing is also an important topic. When capturing you can't see all of the tail you're recording. So you should know its direction, and off-center the comet's core accordingly. But i think the most remarkable progress has been made in image processing. Things like StarXterminator or Starnet are very useful to separate the comet from the stars. Getting rid off all star residuals in the comet-registered stack is still an issue, though. At least in my latest frameset. I'm sure there will be some large improvement in future. CS Horst |
7.75
#...
·
|
|---|
|
Thank you Horst, your contribution answered a lot of my questions. To me a comet was sort of a fuzzy thing, so I wondered why you would have to worry about exposure time. With my wide field image scales I couldn't imagine aiming at core details ... Fortunately Stellarium shows the direction of the tail - although knowing where the sun is, should help too. Clear skies Wolfgang |
