RA is in hours, but yeah it's more likely to do with spherical trig. The calculation in Mosaic assumes a flat plane which is only approximate for very small angles and breaks down over large areas. Will have to look at it more in the future unless someone wants to step it to fix that.

I haven't yet used the mosaic tool (but soon will). Big Noel, I'm curious whether you've tried to mosaic at the celestial equator (Dec=0). Is the answer correct at Dec=0? If so, could this be a simple issue with not correctly factoring cos(dec) in the RA calc? The error for NGC5139 is suspicious in this regard.... Just a thought.

Okay that makes sense. In a flat plane I would assume that each quadrant would have a value in relation to the one above, below, left, and right. On a four panel mosaic this would work out:

top left: Position lower, move to right.
top right: Position lower, move left.
bottom left: Position higher, move to right.
bottom right: Position higher, move to left.

Anything beyond 4 panels is way over my head...

Now to try and wrap my head around this with RA and DEC numbers. Thank you Jasem for the explanation, I now see that to change hours to degrees the calculation is one hour equals 15 degrees.

Cheers
Jim

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.

Big Noel and dmsummers

It appears that within Telscopius they use +- 90, +- 180, +- 270 to achieve the overlap. The math is beyond my understanding when 'cos' and 'sin' is involved.

Gonna remove myself from this conversation while I still have a single brain cell left...

Cheers
Jim

I'll just leave this here as it may be insightful.
people.sc.fsu.edu/~jburkardt/m_src/spher...sphere_llq_grid.html
people.sc.fsu.edu/~jburkardt/m_src/sphere_grid/sphere_grid.html

Sorry, I don't understand either of the last two posts. What seems to make sense (although it could also be totally wrong) is that the total RA field must need a mosaic panel RA position offset adjustment proportional to (1-cos(dec))/N RA panels (or similar). At DEC=45, and for a 2 panel RA mosaic, this would be a 30% total RA panel field size position adjustment divided by the 2 panels (left panel left, right panel right). The devil's always in the details (e.g. likely need to map camera rotation to N/S, E/W coordinate vectors), so a deeper code eval with a few good sim tests is needed to sort and fix the bug. BigNoel, since you're already good at setting up the test(s), it might be nice to know what the sim says about a 2W x 1H mosaic on Polaris.....

Sorry, my post is little more than some links to some examples of existing code I thought could be applicable. With regards to plotting grid points, which are analogous to the center of a frame, upon a sphere using Longitude and Latitude coordinates.

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).



The FOV width of the sensor used when simulating the above was 0.795 deg [1280x1024, 5.2μm pixels with 480mm focal length).

@BigNoel....thanks. If it's any consolation, our friends in the south are MUCH more impacted by this bug than we are in the north. Both Magellanic clouds are at or below DEC minus 70. IMHO, there are no large structures worth a mosaic above DEC 85 or below DEC -85, so an RA/(cos(dec) correction factor (even if a temporary workaround) should suffice until/if someone wants to work a more formal solution for the poles. That said, there may be complicating factors in how the code is arranged (e.g. how/when camera rotation effect on panel field definition is done).

I'm not the one to code up this bug fix. I'll only encourage Jasem or another primary developer to address this bug sooner rather than later. I'll note a conversation I had with a colleague (also an astro-imager) a few months back about astro-imaging software in general (and kstars/ekos in particular). What he said is that a requirement for him to use any astro-imaging software is a good mosaic tool. I didn't appreciate that comment at the time, but I am beginning to appreciate it more now. This bug probably deserves at least a near term workaround to address the sky between DEC +85 to -85. Working around the bug in the manner you describe (i.e. Telescopius->manual enter) seems (for lack of a better word) yucky. Any primary developers willing to help on this? Thanks, and Cheers, Doug

Edit: Additional note to BigNoel: The correction factor doesn't really breakdown at high DEC as badly as you think. We're working on a circle (0-360), so your value needs to be MOD(360). Thus, the 2730 value is actually 210 degrees (2730-(7*360)). That's not that far off of the Telescopium (175) value, especially given how close the test case is to the pole. The delta isn't going to be very significant here.

Ok, looking a bit closer at the code Jasem referenced in an earlier post, it would seem that only line 501 of mosaic.cpp needs to be removed and replaced with a new fragment. I've provided a fragment below that I believe could do the job. The actual change, submission, & final testing I leave for others to resolve as/when desired. A stand-alone test seems to give results consistent with BigNoel's tests above, except that the modulo operator addresses the issue in his data near the pole. Here's the recommended code fragment to replace line 501 (direct insert at same location after removal of existing line):

double offset_degs;
double offset_fract_part, offset_int_part;
// calc offset (degrees) and constrain between 0-360
offset_degs = diffFromSkyMapCenter.x() / (pixelsPerArcmin * 60.0) / (cos(center.dec0().Degrees() * dms::DegToRad));
offset_fract_part = modf(offset_degs, &offset_int_part);
offset_degs = (double)((int)offset_int_part % 360);
offset_degs += offset_fract_part;
// now set skyCenter RA (in RA hours format)
tile->skyCenter.setRA0( (center.ra0().Degrees() + offset_degs) / 15.0);

Cheers, Doug

Thank you Doug, did you recompile KStars to test this?