Absolutely agree, thanks again !
As you mentioned with the load and slew option most of the use case will be covered. The feature described by Croz is a powerful feature that is available in NINA preview. Prior to moving to kstars I used NINA and the framing assistant did this. I used this extensively to reduce the no. of panels required when planning a mosaic. My workflow was:
1. during the day I entered the coordinates or the target I wanted to image and press the load button and the target was loaded on the right hand side.
The box over the image represented the sensor field of view. (note the image source on the top had the option of loading a file and plate solving similar to what feature that we are looking at)
2. On the target section the user can add panels and set the rotation required. The is particularly helpful as it allows me to reduce the number of panels required.
3. Once I am happy with the panels I press add target to scheduler (sequencer in NINA) and panel one and two are send to the sequencer where the no of light frames and dithering and autofocus etc. can be selected similar to kstars.
In my astroclub this is a typical workflow for most users.
Framing live as you have mentioned is no issue, but sometime time consuming when you include setup, pack up manual rotation and manual filter change etc..
But.. thanks heaps for working on this feature this will solve a lot of issues for users like me and increase our imaging time.
This is great, thank you! This would solve most of the issues with manual rotation and give the user the ability to reduce rotational errors. Just one thing to mention
1.Once the rotation is complete and within tolerance, it would be necessary to check the image center and plate solve again to ensure the user didn't accidentally move the center point. This happens at times and causes the image to shift in the horizontal or vertical directions. [plate solve steps would be : Solve the loaded image send reference co-ordinates and rotation to Ekos --> calculate deviation and center the image and slew to target and be within required accuracy. --> Check rotation and report required rotation [as per your video] --> Once the rotation is within tolerance ---> Plate solve to check center of image and reslew to center and be within tolerance.
Thanks Jasem, cant thank enough for the excellent work you do !
Thanks endlessky, It makes sense and will give it a try this week if the sky clears up, have you tried this workflow with mosaics ? many a times I set the job up on scheduler but do the second panel next night and this is when the rotation matters the most, as you would know the difference in rotation between the panels contributes to excessive crop and the only way I know to counteract it is to do more panels.
This will be great ! thanks a lot Jasem ! It will also help with minimizing max power draw when running of battery supply.
I find the QHY camera cools rapidly ...very rapid at 100% cooler power while the ZWO camera cools slowly in steps not sure why ? I though it was because of the camera driver and its control, having said that in NINA the QHY camera and the ZWO camera cools in steps.
I originally asked the question if this can be done and if there was a workflow to achieve this, and as you mentioned using the plate solved info in kstars I gave it a try a couple of times and could not get the rotations to match between different setups and pack ups. I hence added this to the wishlist if this feature could be added in future release.
The workflow is being able to set a target angle of rotation and when plate solving the result compares to this original target angle and denotes which way and how much to rotate by. The process is repeated until the tolerance is met.
Thanks in advance.
I am fairly new to Kstars and Ekos and I must say I love it. Every aspect of it including the RPi4 setup and connecting to equipment, planning and etc. etc.
However there's one missing feature that has caused more heart ache for me and at least 3 others that I know off who have gone back to laptop based setup using SGP and NINA. Its the manual rotation feature.
In NINA and SGP, the user can select manual rotator and request the plate solver to check the actual angle of the FOV against the desired FOV rotation, then SGP/NINA reports the rotation required say 5.5 deg. clockwise or counter clockwise, the user then manually rotates the focuser and selects ok and the plate solver solves again and reports the required rotation. This is done until the required tolerance is met, In my case I've set it to 0.5 deg.
This is critical in my setup because, I use a 1" sensor at 550mm focal length and for most targets (eg:M45) it just fits in the FOV and because we have to pack up and setup over different nights and swap between targets, getting back to the original rotation as close as possible is important so as to not destroy the edges of the stacked image and minimize the crop.
We could use a automatic rotator but the equipment is too expensive and we have been using manual rotation successfully in SGP/NINA.
Could you please consider the feature
Thank you I will give it a try. Say I have packed up night 1 and set up again night 2 to achieve the same location i can use an image from night 1 via load and slew and go back to the same target but how can I get the fov rotation close to my first nights fov ?
Is it possible to set the angle of rotation required prior to 1st plate solving so I can frame the target accurately ? The problem is, I have a 1" 183 sensor and with most targets, my setup doesn't leave me with too much area left to crop hence the rotation is critical to be within 30 arcmin, which I can easily & repeatedly achieve with NINA. With Kstars I can get the location right with the ASTAP solver but no rotation indicator or I don't know how to proceed. Without this when I setup over multiple nights my rotation could be slightly off every night for the same target which would be a major issue after stacking as I would need to crop a lot of the edges compromising the framing.