Closed gnthibault closed 1 month ago
gnthibault
commented
1 year ago Ok I confirm it seems that this dummy commit fully fixes the issue I am experiencing (but that's not likely what the project wants): https://github.com/gnthibault/phd2/commit/4691361d5a48cff3bc5af755c41c97aa9b220267
Not doing a PR at the moment because it wouldn't make sense as is. But I'll be interested in getting feedback about how to improve that to make a PR that would go through.
Thank you in advance for your help
bwdev01
commented
1 year ago I don’t think you’ve given us enough information to work with here – just comments about inconsistency and lack of robustness in general terms which I don’t know how to interpret. I think you should run a series of back-to-back comparisons of the interactive and event-server driven find operations on the same stars. Note the times you did each pair, then submit the debug log file for that session, telling us the timestamps of interest and what results you are unhappy about. Also, please move the discussion to our support forum and upload the full debug log file using the built-in PHD2 Upload Logs feature:
https://openphdguiding.org/getting-help/
If you look at the debug log file yourself, you may discover there are unintended differences between the two operations, e.g. the spatial region that is actually being searched.
Regards,
Bruce
From: gnthibault @.> Sent: Sunday, July 23, 2023 7:08 AM To: OpenPHDGuiding/phd2 @.> Cc: Subscribed @.***> Subject: [OpenPHDGuiding/phd2] find_star method from event server have lower performances than its UI counterpart (Issue #1088)
To whom it may concern. I have been playing with the event server for quite some time now, but still experiencing issues with robust star selection method. Basically I know where is the star I want to guide one (as part of a spectroscopic workflow), and I send a find_star command to the event server, which is documented here: https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring#available-methods
The signature seems to be: find_star(x,y,width,height) Which I use with x, y being the leftmost, lowermost coordinates (in sensor coordinate system) of my bounding box (usually 50 pixels), and widht, height the respective size in pixel of the desired search bounding box.
Unofrtunately this method seems extremely inconsistent, end more importantly, it is much less robust that the autoselection that works perfectly in the UI, which I am testing quite often at the same time that I try to debug the actual event server method.
Unfortuantely the code is a bit cryptic to me, but in practice it seems that event server method is completely different from the UI method where you just have to click somewhere neat your star for it to be detected properly. Can someone help me understand how to reach the same performances of detection from event server, as what is provided from the UI ?
Thank you in advance for your help Best regards
— Reply to this email directly, view it on GitHub https://github.com/OpenPHDGuiding/phd2/issues/1088 , or unsubscribe https://github.com/notifications/unsubscribe-auth/ADDHSV2ZGFOGW6JD4AYE6H3XRUV3NANCNFSM6AAAAAA2URIACU . You are receiving this because you are subscribed to this thread. https://github.com/notifications/beacon/ADDHSV3TD7AZFKTEUMI6O6TXRUV3NA5CNFSM6AAAAAA2URIACWWGG33NNVSW45C7OR4XAZNFJFZXG5LFVJRW63LNMVXHIX3JMTHGYT3FBI.gif Message ID: @. @.> >
bwdev01
commented
4 months ago Unless we get raw log data that clearly demonstrates the problem, I plan to close this.
To whom it may concern. I have been playing with the event server for quite some time now, but still experiencing issues with robust star selection method. Basically I know where is the star I want to guide one (as part of a spectroscopic workflow), and I send a find_star command to the event server, which is documented here: https://github.com/OpenPHDGuiding/phd2/wiki/EventMonitoring#available-methods
The signature seems to be: find_star(x,y,width,height) Which I use with x, y being the leftmost, lowermost coordinates (in sensor coordinate system) of my bounding box (usually 50 pixels), and widht, height the respective size in pixel of the desired search bounding box.
Unofrtunately this method seems extremely inconsistent, end more importantly, it is much less robust that the autoselection that works perfectly in the UI, which I am testing quite often at the same time that I try to debug the actual event server method.
Unfortuantely the code is a bit cryptic to me, but in practice it seems that event server method is completely different from the UI method where you just have to click somewhere neat your star for it to be detected properly. Can someone help me understand how to reach the same performances of detection fro m event server, as what is provided from the UI ?
I enclosed also the fits file from the log directory upon find_star failure: AutoSelectFail_2023-07-23_161042.zip
An example of corresponding logs in the log files looks like this:
In the logs up above, the first local max, ie [581, 409] was exactly the one I was looking f Unfortunately, it seems that this detection is discarded because of the following reason:
EDIT: I went in the log later on a slightly different setup, and here are the corresponding logs I see:
It seems that Star::Find is a different function, and this time, it finds the star perfectly... Now my question, is how I get to use this one. I will check if I can work this out on my own fork. Thanks in advance for your help
EDIT2: Ok it seems that I can get to use at least partly the same method (Star::find) by removing multistar mode in advanced setting pane:
EDIT3: Unfortunately, I realized my EDIT2 was wrong... PHD2 is still using Autofind with the same error I have shown earlier. I is still very weird that in the logs I find instances of case where there seems to be a mix of Star::Find and AutoFind, such as in here:
Thank you in advance for your help
Best regards