KStars 3.4.3 Build: 2020-07-15T21:35:26Z ; Source : Nightly builds
Using the same simulation in my first post; a 2x2 mosaic of NGC5139, using SimulatorCCD, 1280x1024 5.2μ pixels with 480mm focal length.
Mosaic tool, using 0% overlap for illustrative purposes.
He's usually been pretty quick in the past, I see in DerPits thread he's mentioned he's published a fix but not had time to test it. This is good news in that the issue is on the radar and it will keep coming up as more people use kstars and want to do mosaics.
Knowing that Telescopius output a CSV table of panel coordinates I'm going to explore how I can parse this into creating job files for Ekos that I can import.
If fixing the native mosaic tool is to hard to do, having an easy way to paste the CSV output from Telescopius would be a good workaround.
Read More...
I'm worried there might be another issue with DEC. I spent some time tonight creating larger mosaic grids in kstars and Telescopius, comparing their output.
From my observations so far, it appears the RA value needs a 'correction factor' as well, which kinda makes sense as we need to 'curl' the flat pane in both dimensions to make it spherical.
Way more maths than I can handle.
I also noticed in kstars the mosaic tool wont center the target if its near the horizon at the date/time/location set in kstars - I'll investigate this further and maybe post something else about that as it's a separate issue.
Why would i want mosaic panels below the horizon? To be able to create a sequence that can run when those objects are in view at a later date/time, or different location.
Read More...
As requested, I did a comparison with Polaris, given its high DEC value. I also examined the difference between Telescopius and Kstars when calculating the image centers for a selection of coordinates where the RA is 0 and the DEC is 0, 30, 60 and ~89 degrees.
Whilst both tools act a little differently at high DEC approaching 90, there was a clear indication that the calculated Telescopius RA position relies on a factor applied by cos(DEC).
For most coordinates where DEC is say <85deg, the Kstars value can be corrected by dividing by cos(DEC).
This table shows the comparison. I used an online tool to covert the RA and DEC to degrees so some rounding issues may exist, though the relationship is clear - until it breaks at high DEC.
dmsummers was right on the money with cos(DEC), I don't know coding well enough to fix it and I don't know how to stop the crazy values at high DEC.
Hopefully this work fast-tracks a solution. Plotting a mosaic grid in Telescopius then manually creating jobs in Kstars is going to be painful... (but not impossible).
Good test dmsummers and you might be on to something.
I'll test Kstars more tomorrow night, but knowing the EKOS tool gives a 3' 10" difference in RA using the simulator when using NGC5139 as a test (DEC -47 28 36). I compared that to the Telescopius results, at RA 0, DEC 0, the difference in RA between centers of a 2x1 mosaic using the SimulatorCCD specs is... 3' 10" !
I entered a different target in Telescopius; RA 0, DEC 45. The difference in centers is 4' 28" . Clearly the Telescopius algorithm is factoring in something relating to the DEC. This might be enough for someone to solve the issue.
When it works, the mosaic tool and scheduler is magic, I really hope to see this issue fixed so I can use it more! AstroPixelProcessor does a good job at compiling the mosaic too.
Read More...
Cheers knro.
My maths or coding isn't good enough for this sorry. I did manage to recreate the calculations in Excel using the method from mosaic.cpp and found I got the wrong RA value as well.
I can say adding the width of the sensor, minus overlap (in degrees) to the RA position (degrees) gives the wrong position, though this method works for DEC.
I had a look at how
Telescopius
do their mosaic tool ((
pastbin
) and they do some spherical and cartesian coordinate conversion - perhaps that's a hint for you.
I'll keep giving it some thought, and hopefully someone can assist.
Read More...
I calculated the same 2Wx1H mosaic of NGC5139 layout using Telescopius. Interestingly it generated :
Pane, RA, DEC, Position Angle (East)
PANE 1, 13hr 29' 07", -47º 28' 46", 0
PANE 2, 13hr 24' 27", -47º 28' 46", 0
These are 4' 40" apart in RA. Compared to 3' 10.7" apart from the Ekos tool. The Telescopius panels line up correctly when checked in Stellarium.
As the DEC calculations are OK, I wonder if the issue relates to the difference in units used between RA and DEC - maybe the code behind the tool is treating these the same where they should be different?
Read More...
Some more info:
I tested this with the simulator creating a 2x2 mosaic.
The problem also is evident here too. I've also had the same issue in real world use with bigger mosaics like this.
Mosaic tool settings:
Hi all,
I'm using INDI Library 1.8.5 ; Kstars 3.4.2 ; Source: PPA ; Kernel/Arch : 5.4.0-40-generic #44-Ubuntu SMP Tue Jun 23 00:01:04 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux.
My mosaics that are 1W x 2H have correct overlap, however my 2W x 1H have more overlap - about 30% instead of 5%.
The maths seems to check out OK when looking at the calculated RA/DEC for the panels, but there is a big overlap for some reason.
This can be recreated using the simulator CCD.
I created an example using NGC5139, simulator CCD (1280x1024, 5.2um pixel) with a 480mm FL scope. FOV is 47.67' x 38.14'.
For the example I set a 2Wx1H mosaic with zero overlap, I expect difference between the panels to be 47.67', the width of the FOV.
The tool created 2 jobs:
(1) RA 13h 28m 20.77s DEC -47° 28" 39.59'
(2) RA 13h 25m 10.09s DEC -47° 28" 39.59'
The difference in RA is 3m 10.68s which is 47.67 arcmin, which is what I expected.
There is no difference in DEC, also as expected.
However, in real world use with my Canon DSLR and also evident here using the simulator CCD dimensions and viewing the RA/DEC for each panel in Stellarium, there is a big overlap between panels.
Hi,
I have found and issue with the Ekos mosaic tool than can be recreated with the Simulators. I generated a 1x2 mosaic job set, and a 2x1 set and compared the calculated RA and DEC using Stellarium.
The examples below show the issue. The 1x2 set has the correct 5% overlap. The 2x1 set has a 30% overlap. I've experience the same issue in the real world and found a 10% overlap resulted in images with a 60% overlap - but only when the short edge of the sensor overlaps. When the long edge overlaps things appear OK.
Right:
I recently tried to slew to a couple of different objects that were near the meridian. The mount refused to move and no error was given. I could move around fine east or west of the meridian, but not within say 5 degrees of it.
Is this by design or is it something I'll need to investigate further - collect logs and take notes etc.
I'm using a Skywatcher EQ6-R via Eqmod (direct USB cable), with latest Indi/Kstars on an Ubuntu 20.04 mini PC.
Cheers.
Read More...
Giving this a bump and following any progress - I too would like to see this feature.
I've occasionally closed a session mis-clicking or double clicking the X to close the FITS preview, inadvertently closing Kstars.
A simple optional prompt would be awesome. If it could warn that EKOS is running and devices are still connected; even better.
Cheers
Read More...