Oculars Plugin reticle center coordinates do not compensate for "Vertical View Offset"

[DogWatch441]

Expected Behavior

Center of FOV of Oculars reticle coordinates should compensate for any user change in "Vertical View Offset" in Stellarium's "Sky and Viewing Options".

Actual Behaviour

Oculars center of FOV does not compensatefor any user change in the "Vertical View Offset", so importing of visually framed targets coordinates into NINA is inaccurate. degree of inaccuracy varies with the change in overall screen field of view. The larger the screen FOV, the larger the Ocular center of FOV coordinates inaccuracy.
Coordinates of Oculars center of FOV reticle are always correct if "Vertical View Offset" in "Sky and Viewing Options" is set to 0% (I believe this is default).
This is a problem when using Stellarium to frame targets and then importing pre-framed coordinates into acquisition software (NINA in my case).
I use a Vertical View Offset to drop horizon down to the bottom of the screen to maximize the sky view on my laptop screen. My current kludge "fix" is to set the offset at 0% when using Stellarium for framing purposes. NINA's developers suggested fix is to just use NINA's Framing tab, but Stellarium's GUI is much, much better and preferred.

Steps to reproduce

Change "Vertical View Offset" to value different than 0%. Select and center target. Select Oculars reticle overlay. Zoom screen FOV in or out. The smaller the screen FOV, the more accurate the Oculars reticle center of FOV becomes with regard to the chosen target; the larger the screen FOV, the less accurate the Oculars reticle center FOV coordinates become with regard to the chosen target.

System

• Stellarium version: 24.4 Qt5
• Operating system: Win10 home 22H2, Build 19045.5371
• Graphics Card: Nvidia GeForce
• Screen type (if applicable): Resolution, HighDPI, scaling

Logfile

If possible, attach the logfile log.txt from your user data directory. Look into the Guide for its location.

[gzotti]

The view center shift is indeed a way to display more of the sky in wide-angle views where one would not want to cover much of the screen with horizon. What do users expect when "centering on an object"? Should the object appear in screen center, or at the location configured via offset setting? I assumed centering in the screen center is the more plausible choice.

Indeed we can only recommend to obviously switch it off for Oculars use. Whenever we might find time again to deal with the Oculars plugin, screen offset should just be forced to zero in Oculars mode to fulfill expectations from other programs.

[DogWatch441]

@gzotti : Thanks for reviewing my post and adding you comment. However, I am unclear on what you are saying. When one uses the "Vertical View Offset", it shifts the vertical aspect of the the horizon line on the screen. In my case lower on the screen. Whenever I select a target and center it, it along with the Ocular reticle overlay do center in the screen. The coordinates of the center of the Ocular reticle will vary from the centered selected target as you scroll to make the image on the screen larger (smaller screen FOV) or smaller (larger screen FOV). The ocular reticle center coordinates do not compensate for the changed "Vertical View Offset" and so, acquisition programs such as NINA which uses the Oculars center of FOV coordinates (if the Oculars tool is activated) then import inaccurate framing coordinates.
I was hopeful that the Vertical View Offset %change from zero could be compensated for by the Oculars Plugin center of FOV coordinates calculation. If this is not possible, or exceedingly difficult, I agree that having the Vertical View Offset be reset to zero whenever the Oculars Plugin is activated makes the most sense (while still keeping everything centered in the screen view).

[gzotti]

I don't know more of NINA than the name. When I center on an object using the Ocular view or Sensor view in the Oculars plugin, the object is centered even if I change the offset value. This is intended. If I center e.g. (via scripting) on coordinates and not an object, the view is shifted. Likewise, this behaviour is intended for scripting use.

Whatever NINA is communicating with Stellarium, if it then asks for the coordinate of the optical axis, it may be off. Maybe NINA devs should compensate for this.

[DogWatch441]

I've had a long conversation with the NINA devs and it was during that latest conversation that I discovered the specific cause of the problem. Their take is pretty much that NINA is harvesting coordinates produced in Stellarium and they can't change those (NINA harvests coordinates from the Oculars Plugin when it is activated). They also suggest that if there is a problem, why not just do the target imaging framing in NINA rather than in Stellarium... and the answer to that is simply that Stellarium's GUI is so much better! Being able to choose a target and then using the Oculars reticle to adjust the framing for the imaging session in Stellarium then importing those framed coordinates into NINA is wonderful. The problem is that the harvested coordinates are incorrect for the screen view in Stellarium if the "Vertical View Offset" in Stellarium is any value other than 0%.
The lack of compensation for the "Vertical View Offset" does seem to be a bug... granted only a problem for a very specific usage of the Oculars Plugin. My hope in following up is that it might be a straight forward fix, or barring that, that the issue gets documented and saves others from 6 months of looking for an answer.

[gzotti]

If NINA can harvest object or aiming coordinates, it can also harvest the screen offset in the same way to compensate whatever it has to. The math is then simple, and it's not us who has to add yet another maintenance burden. Our offset math within Stellarium is just the way we think it should be.

[DogWatch441]

Fair enough. I rather figured I was going to end up stuck between finger pointing, but thought it was worth a go. I know what the glitch is. I know how to get around the glitch. I have documented the glitch at both Stellarium dev site and Nina dev site for anyone that has the same or similar issue. Nothing else I can think to do so I'm tapping out.
(I specifically used the term glitch as it semantically seems to fall somewhere between "bug" and "feature").

[10110111]

Their take is pretty much that NINA is harvesting coordinates produced in Stellarium and they can't change those (NINA harvests coordinates from the Oculars Plugin when it is activated)

What coordinates does it harvest? From what I can see on the screen, the coordinates of the center of the FoV footprint are reported correctly — the same numbers as in the info panel (although the text appears skewed). And how do they connect to the plugin — I thought it doesn't provide any connectivity?

[alex-w]

And how do they connect to the plugin — I thought it doesn't provide any connectivity?

via Remote Control plugin IMHO

[DogWatch441]

What coordinates does it harvest? From what I can see on the screen, the coordinates of the center of the FoV footprint are reported correctly — the same numbers as in the info panel (although the text appears skewed). And how do they connect to the plugin — I thought it doesn't provide any connectivity?<

I wish I could give you an answer, but my programming knowledge is minute. What I know is that if a target is selected in Stellarium and you click in NINA to import target, the coordinates match perfectly (whether you have changed the vertical view offset of the screen in Stellarium or not. Once you turn on the Ocular Plugin and have it overlay a reticle, the target coordinates pulled into NINA no longer match the the visible ones in Stellarium if the vertical view offset in Stellarium is any value other than 0%... and the more you scroll the Stellarium screen out, the further the coordinates stray.

According to the devs at NINA, if the Oculars plugin is active with a reticle overlay, NINA pulls in the reticle's center FOV so as to allow the user to frame their target in Stellarium and then pull the coordinates of that sensor framing in as the target for acquisition. This is excellent, except if you have used a vertical view offset different from 0%. In that case, the value for the center FOV of the Oculars reticle overlay is incorrect. It appears that the Oculars reticle center FOV coordinate (which is hidden and not found on the Stellarium screen anywhere) does not compensate for a user defined change in the vertical view offset of Stellarium.

This variance is likely irrelevant for any usage of the Oculars reticle overlays aside from photographic framing, where it is very relevant. I also agree that this issue is low priority for a fix, especially since one can work around the problem now that it has been defined, but it is incongruous to suggest that this is the intended behavior of the plugin (as @gzotti did previously).

[10110111]

It would be useful to have a more complete steps for reproduction for those who have never used NINA. I.e. what one has to do after having installed Stellarium and NINA to see the issue.

Or the developers of NINA could join this discussion and tell what interface they use for getting the coordinates, so that we could find what's wrong. It may well be that some data element streamed by some Stellarium plugin is ignorant of the shift, but the question is what element and streamed by which plugin (if any).

[gzotti]

To be sure on terminology: @DogWatch441 with "reticle" you mean what we call "sensor frame", right? (A "reticle" is generally a net or grid, commemorated even by constellation Reticulum.)
The value to additionally take into account is StelMovementMgr.viewportVerticalOffsetTarget. Together with current screen fov, you can work out any shift.
I said the current implementation works as we have intended it to work. Requesting numbers by other programs for purposes the program was not developed for is possible as of now but of secondary importance to us, and whoever is querying data via RemoteControl must make sure to query all data required for such purpose.

[DogWatch441]

@gzotti : Yes, when I use the term "reticle" I am referring to the "sensor frame". I chose to use the alternate term to try to reduce confusion as I was already using the term "Framing tab" as the proper name of the window within NINA into which the coordinates were being pulled, frequently within the same sentence.

While the requesting of data from Stellarium by other programs is not a high priority for the Stellarium devs (understandably), precision within Stellarium does seem to be a priority item (proper magnitudes of stars, etc). The movement of the sensor frame away from the selected target (both visually and by coordinates) when scrolling screen FOV if a user has modified the vertical view offset seems like a lack of precision that the Stellarium devs would like to know about. In addition, the best place to fix this imprecision would be at the source code (Stellarium) and not by every piece of software that draws this information from Stellarium. To be clear, the lack of offset compensation is visible in Stellarium also, though not to a degree that most users would notice it.

Thank you for pointing to where other program devs should look to provide their own compensation calculations to the data harvested. I will pass the information along to the NINA devs and also see if I can encourage a direct discussion between them and the Stellarium devs. Personally, I think you should take it as a compliment that other software devs look to harvest data generated by Stellarium. As far as I am concerned, Stellarium is head and shoulders above any other planetarium software.