Feature suggestion for avoiding oval stars

[CaLIGHTs DSO Image Calibration Tool]

 I have been studying how guiding can result in oval stars in my astrophotos. Pix Insight has star eccentricity, aspect ratio and flatness measurements which are great but I think that PHD2 could have something displayed that can alert a user that there guiding could result in oval stars. Here is how it could be implemented:

The user would input a star HFD in arc-seconds that they typically obtain in their astrophotos. Not entering a value would disable this feature. PHD2 would require that the user display their guiding error in arc-seconds.

PHD2 would then monitor the RArms, DECrms and Totalrms. PHD2 would then calculate whether these values, combined with the user supplied star HFD meets the cryteria for oval stars. This feature could just be a status indicator "OVAL".

I posted a description of what I have been up to regarding this suggestion on my website https://astrohobby.ca/2022/02/26/star-eccentricity-and-guiding-accuracy/

Your comments...

Peter

[mj.w...@gmail.com]

IHi Peter

I just look at the RA and Dec Guide Errors.

If they're similar, then stars are round.

If they're very different, stars are elongated.

Large and similar errors result in round but bloated stars.

Maybe a feature is required.

Michael

Wiltshire UK

[Brian Valente]

Hi Peter

What kind of problems do you envision this solving, and how would having it in PHD solve it? 

in my opinion, it's generally a good notion. I'm not sure PHD is the place for it.

As someone else pointed out, you already have the data in PHD to see if the RMS is significantly different between RA and Dec and make a judgement call as to whether it may produce star elongation.  

Very generally, divergent RMS is usually a sign something needs to be addressed in the mount, so fiddling with guide algorithms because PHD is saying "oval" probably isn't going to solve that kind of problem. 

When users do have PHD setup improperly, it typically takes a session or two to correct the settings, get a good calibration, etc. and then what PHD can do for RMS is pretty well set. 

I think a controlling app like NINA would be better suited, where it would actually measure star eccentricity, and be able to distinguish between tracking errors, backfocus issues, collimation issues, all of which can result in star elongation. using ASTAP would also be a good solution here

These apps have access to the final images can do a better job as to what type of issue it is and how to address it. 

Simplifying it down to a "oval stars" i think would give a lot of false positives. I don't think people staring at their guiding all night long, tweaking things in an attempt to fix oval stars is going to be productive, 

Brian

--
You received this message because you are subscribed to the Google Groups "Open PHD Guiding" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-phd-guidi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-phd-guiding/ae2311e2-d374-4e8a-8967-7c3a18444265n%40googlegroups.com.

--

Brian 

Brian Valente

portfolio brianvalentephotography.com 

[Pict...@earthlink.net]

Brian,

I see the suggestion differently.  If I understand your response, you seem to say that the final outcome of a guided exposure is better evaluated by another controlling app such as NINA.  And, again if I am understanding your comments, that the user could monitor the RMS values (RA, DEC, & Total) since they are reported by PHD2, but that there is little use in doing that in order to make PHD2 guiding adjustments ("tweak things").

First, the final image accessible to NINA or other program is the result of however long the exposure is.  It is not a moment to moment monitor of PHD2's guiding actions.  Second, for those who prefer not to have to watch the PHD2 user interface (UI) real-time, if PHD2's RMS values were exposed, they could be used by the user however they wish.  The astrophotographer may not want to have spent precious exposure time on an image doomed to be discarded at the session's end.

If PHD2's RMS values were available other than via the user interface (UI), the user could perhaps implement a script to abort that exposure based on criteria they choose; they could abandon that target entirely; they could perhaps simply change the filter selection, or any number of other things.  The point is that they would have the freedom to decide how to respond at the time rather than finding out after the session is over, that the image(s) are unusable.  I think it is a mistake to presume that if the RA and DEC RMS values are discrepant, the only possible cause is a mechanical issue with the system or bad choices of parameter settings in PHD2 and therefore the user needs to fix those problems first.  While that may be true some of the time, I think it is not true all of the time.

The value I see in the OP's suggestion is that it gives the user the freedom to choose how to respond during an imaging session.  I think that freedom is a good thing.

The guide actions are, of course, written to the Guide Log, but there is no annotation describing what the numbers there mean and, in any case, they are not the RMS values which represent a moving, historical summary of the guiding. PHD2 is obviously performing calculations based on those guiding actions and providing the results to the UI.  If those values were exposed and accessible then, the user would at least have a chance to do something with them if they choose before finding out after the fact that the image is spoiled.

I will also use this topic to bring up another possible future direction which may never be implemented in PHD2 but could have great benefit.  That is, if PHD2 guiding parameters and actions were exposed and accessible, some enterprising coder may implement an AI tool that could learn for each user's system what settings can achieve the best possible results during any given session.  As we all know, users' systems vary greatly as do atmospheric conditions from location to location and night to night.  I think such a tool would make astrophotography much more rewarding for many who work with less than the best equipment at less than ideal locations.  I see no reason why such a tool is impractical and PHD2 certainly provides the basis for enough functionality to support it, I think.

Regards,

Manning B

[CaLIGHTs DSO Image Calibration Tool]

All,

Lots of good feedback. I like the idea of having a real-time "OVAL" warning light on the PHD2 UI that can take all of the required parameters(Totalrms, RArms, DECrms, HFD) into consideration. It's not a simple calculation that you can do in your head. The PHD2 graph has adjustable history length which helps to avoid false alarms. Having the "OVAL" alarm may help me to decide what should be done right now...instead of realizing what I should have done while I develop the photos. 

Peter