Stellarium
Oculars plugin
Is your feature request related to a problem? Please describe. When I go to find a new target to image and I enable my camera and telescope, I would like when I rotate my sensor, for the view to rotate with the sensor, keeping the sensor level. But It looks like there is no option to do that. Instead, to get a visualization of how my image is going to look, I have to use Alt-Az mode and play with the time and location.
Describe the solution you'd like I would like there to be an option to enable the view to rotate as well when you rotate the sensor.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context
Isn't the config option Oculars → Sensors → (choose your sensor) → Rotation Angle the one that you're looking for?
Isn't the config option Oculars → Sensors → (choose your sensor) → Rotation Angle the one that you're looking for?
The OP want to see rotation sky for static sensor (inverting rotation of sensor).
P.S. I think it should be mark as "Won't fix" or it can be task for community
P.S. I think it should be mark as "Won't fix"
Why? We already have Alt-Az and equatorial modes, why not add one more, "sensor" mode? Given that astrophotography is one of the most frequent use cases of Stellarium, I think it would be quite a sensible display mode to have.
P.S. I think it should be mark as "Won't fix"
Why? We already have Alt-Az and equatorial modes, why not add one more, "sensor" mode? Given that astrophotography is one of the most frequent use cases of Stellarium, I think it would be quite a sensible display mode to have.
To adding a "sensor" mode we should rewrite StelMovementMgr class to quaternions, because adding extra modes can be very painful with current implementation.
adding extra modes can be very painful with current implementation
This is not a reason to mark this as "Won't fix". Someone some day may have enough motivation to implement this, it's not against any of our policies.
adding extra modes can be very painful with current implementation
This is not a reason to mark this as "Won't fix".
And I added or part for my P.S.
This is a good task for the community to participate in the contribution into Stellarium. Who wants to help us?
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
It could be called "Framing mode" and entail a separate screen with the bitmap of the current sky fragment snapshot displayed behind the sensor wireframe, with rotation and pan controls (kbd) for moving the bitmap around a bit. No single quaternion kicking required. From the UX perspective there is no difference.
From the UX perspective there is no difference.
At the very least you'll get rotated labels if you just do like this. Additionally, moving the bitmap will shift the center of projection, so you'll get a distorted image (especially important for wide FoV).
I envisioned an option in the settings that would enable this feature. A separate mode like EQ mode would be cool, but I would like to also work with EQ mode so that I can get the correct camera rotation with my EQ mount.
For an AP artist text labels does not matter, while the typical CCD frame size is around 100 -200 arc min, thus distortion is negligible as well (especially as the frame is naturally centered on the projection). The implementation could just hide all labels, make a snapshot of the selected region in X/Y +50% around it (to allow minor wiggling of the content within the fixed frame) to a bitmap or X/Y projection list. When user is satisfied with the resulting portrait or landscape frame composition, the new true frame center is calculated along with the absolute frame rotation angle and returned as the new center/rotation of the original frame for the "normal mode" view on that "Framing mode" exit. Any final corrections can be manually done in that real "normal mode" if needed.
Just a thought. I'm not into the AP anymore personally, so would definitely prefer it implemented in the Math properly, i.e. for the use with the Eyepiece mode, which is nearly a gimmick without the interactive FOV rotation given most of visual telescopes does not maintain any clearly fixed direction of the AFOV (like the precise Z-N plane).
adding extra modes can be very painful with current implementation
This is not a reason to mark this as "Won't fix". Someone some day may have enough motivation to implement this, it's not against any of our policies.
indeed: a long standing meta issue that reappears often in this project.
it's not because the developers can't fix this easily (and they have strong arguments for that, we can fully appreciate that, we are grateful for their work) that there is no other developer that could have a go at it. With a decent review of the code prior to integration, to prevent the Observing Lists problems.
Burying it in "wont' fix" hides potentially good features. The community label is the solution.
Why am I writing this? Because several of my suggestions have been flagged as such. As a result, I've lost most of my interest in participating in the coding effort, even when I used to be a software engineer fluent in C++ and have a decent astronomy background (contrary to how some people here want to portray me).
Keep up the good work.
