For better sorting of images for later stacking it’s instructive to have both SQM and seeing available; SQM can be recorded in the FITS header already (if you have the appropriate ASCOM driver), but seeing as measured by FWHM is not. PhD2 tracks this information as part of it’s logging [Redirecting to Google Groups], it would be useful if the FWHM of it’s guide star could be included in the FITS header of the image
Out of curiosity, what advantages would recording the FWHM of PHD2’s guide star offer over simply recording the average FWHM calculation of the image itself?
The FWHM of the image itself might be unclear; for instance, what would be the FWHM of the North America Nebula, or of the Horsehead? By using the guidestar FWHM (which is reasonably close to the image and has close to the same seeing) it’s much less ambiguous …
I’m not talking about the “FWHM of the Horsehead”. I mean an average FWHM of stars in the field, the way AutoFocus does it.
Just seems to me if that method can determine best focus, then it can serve the same purpose you’re trying to achieve, of recording a value and monitoring its change over time, could it not?
I’m certainly not opposed to your suggestion (wouldn’t matter if I was lol) I was just genuinely curious if a single star’s FWHM from a 3rd party app had some advantage over a frame-wide average that the native app is already capable of calculating.
The autofocus of the field would be better and more representative of the object being imaged, to be sure and that’s definitely easier than parsing the PhD log! The only reasons I didn’t suggest from there is that …
-
Not everyone uses the AutoFocus routine, but a much larger percentage of user use PhD for guiding … in addition, not everyone AutoFocuses at the beginning of an image capture (some do it based on temperature change, or time change, or just do it once)
-
If someday we could record the high and low seeing numbers during the duration of an imaging session … so, we would get a “best seeing” number and a “worst seeing” number in the FITS file, that sort of tracking would be difficult using the AutoFocus routine, a lot easier from the PhD logs …
Where this is coming from is my attempts to do a “lucky stacking” collection, where I take lights over a period of days and then stack them all together. Since seeing and SQM values vary day to day, I’ve found that if I can stack lights with seeing and SQM values as close as possible I get better results … I can track the SQM numbers using the ASCOM Unihedron driver, but seeing eludes me. By having seeing in the FITS file I can sort lights programmatically versus getting the seeing numbers for each light from my PhD logs and putting that into the FITS file manually …
No reason to actually use autofocus though. AutoFocus merely demonstrates that SGP can aclulate an average FWHM for a field of stars.