×

INDI Library v2.0.6 is Released (02 Feb 2024)

Bi-monthly release with minor bug fixes and improvements

Re:Mosaic tool - overlap not correct on width

  • Posts: 398
  • Thank you received: 117
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.....
Last edit: 3 years 8 months ago by Doug S. Reason: clarification and minor correction (DEC vs RA).
3 years 8 months ago #56768

Please Log in or Create an account to join the conversation.

  • Posts: 1309
  • Thank you received: 226

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.
3 years 8 months ago #56773

Please Log in or Create an account to join the conversation.

  • Posts: 30
  • Thank you received: 26
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).
3 years 8 months ago #56787
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
@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.
Last edit: 3 years 8 months ago by Doug S.
3 years 8 months ago #56793

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
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
The following user(s) said Thank You: Jasem Mutlaq
3 years 8 months ago #56807

Please Log in or Create an account to join the conversation.

Thank you Doug, did you recompile KStars to test this?
3 years 8 months ago #56811

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
Not originally (but see edit below). My dev environment wasn't up to date. I did a stand-alone unit test on the code fragment using mock input data after evaluating the version of mosaic.cpp you referenced. I also snooped about the code base to find necessary aid (e.g. dms::DegToRadians call). Otherwise, I just matched up against BigNoel's test outputs and sanity checked RA output correction. Testing/verification is still required, but I'm reasonably confident the frag will compile and run. As I said, others need to take the ball (or not) from here. Cheers, Doug

Edit: I updated my kstars/ekos dev env today, and yes, the code as posted drops in as a direct replacement for line 501. Kstars/Ekos compiles and runs (sim env). Whether this fixes the issue is TBD pending on-sky testing. Having had multiple difficulties recently getting code submitted and approved, and not wanting to revisit those experiences again, someone else will need to do the submission. Cheers, Doug
Last edit: 3 years 8 months ago by Doug S. Reason: Updated status to indicate kstars/ekos compiles and runs with the new code fragment.
3 years 8 months ago #56812

Please Log in or Create an account to join the conversation.

  • Posts: 62
  • Thank you received: 9

I was just removing myself from the conversation when it went into 'cos' and 'sin' math functions. After reading the Telescopis code and that work around for the DEC I knew I was way outta my league...

Cheers
Jim
Celestron CGX, QSI683 Astrodon Gen 2 E series LRGB, Ha, OIII, ES102CF, ZWO-ASI178MC, 60mm guide scope, Pegasus Focus Cube 2, Feather Touch Focuser.
3 years 8 months ago #56816

Please Log in or Create an account to join the conversation.

  • Posts: 910
  • Thank you received: 86
I just completed a 4-panel mosaic before seeing this thread - overlaps are definitely not right.
Panels 1-3 were collected during one night. Panel 4 was added 5 nights later (tonight).

-- Max S
ZWO AM5. RST-135. AZ-GTI. HEQ5. iOptron SkyTracker.
TPO RC6. FRA400. Rokinon 135 and other lenses.
ZWO ASI2600MC. D5500 modified with UVIR clip-in filter.
ZWO ASI120MM Mini x 2. ZWO 30F4 guider. Orion 50mm guider.
ZWO EAF x 2.
3 years 8 months ago #56824
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 30
  • Thank you received: 26
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.
3 years 8 months ago #56839

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
From Jasem's earlier post: "The calculation in Mosaic assumes a flat plane which is only approximate for very small angles and breaks down over large areas".

Max & BigNoel, Max's mosaic clearly shows the excessive overlap in RA (panel 1 vs 3, RA is up/down in the image). That's the issue BigNoel started with the OP, provided test data for, and resulted in the code fragment. Unless Max had some odd setup issue, his panels also show a ~20-30 arcmin DEC issue (panel 1 vs panel 3, seen left vs right edge offsets). I can't imagine how an error of that magnitude could occur for panels taken on the same night!

I think at this point, others who have worked more with mosaics should weigh in about their experiences (panel layouts, field sizes, capture declinations, and results). Otherwise, much more work (sim and on-sky) will be required to better understand the scope of Jasem's statement, extent of modeling errors, and what if anything can be done to make the tool function better.
3 years 8 months ago #56865

Please Log in or Create an account to join the conversation.

  • Posts: 398
  • Thank you received: 117
Having seen Jasem reply to other posts today, but not to this thread, I began to wonder whether this issue is new or not (sorry, should have searched before extending this thread). For completeness, and to link the posts, note that DerPit documented this exact Mosaic issue about 10 months ago (apparently without resolution). See here:
www.indilib.org/forum/development/5744-m...are-wrong.html#43599
and here:
indilib.org/forum/ekos/5743-mosaic-overl...osaic-fov.html#43577
DerPit's post is consistent with the OP in this thread (and the suggested solution). No search results are returned that mention the DEC offsets seen by Max....
The following user(s) said Thank You: Peter Sütterlin
Last edit: 3 years 8 months ago by Doug S.
3 years 8 months ago #56877

Please Log in or Create an account to join the conversation.

Time to create page: 0.516 seconds