×

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

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

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

So turns out this was a rather simple fix after all. I first trying to introduce a new variable, but ended up just changing one line and the results appears to be consistent with Noel's results. Can you please re-compile and test again to verify?
The following user(s) said Thank You: Noel, Jim S.
3 years 8 months ago #56882

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

  • Posts: 398
  • Thank you received: 117
There's much more than 1 line of diff (see below, not including h file), but I think we're still talking about your latest code. After pull, recompile, & sim run, the results look ok (match the fragment). Still not an exhaustive test (especially near the poles), but this is likely good for on-sky test reports by users. Anything that fixes the bug is good. Cheers Doug

< pixelsPerArcmin = Options::zoomFactor() * dms::DegToRad / 60.0;
---
> pixelsPerArcminRA = (Options::zoomFactor() * dms::DegToRad / 60.0);
> pixelsPerArcminDE = Options::zoomFactor() * dms::DegToRad / 60.0;

< double fov_w = map->width() / pixelsPerArcmin;
< double fov_h = map->height() / pixelsPerArcmin;
---
> double fov_w = map->width() / pixelsPerArcminRA;
> double fov_h = map->height() / pixelsPerArcminDE;

< double x = (fov_w - targetWFOVSpin->value() * 2) / 2 * pixelsPerArcmin;
< double y = (fov_h - targetHFOVSpin->value() * 2) / 2 * pixelsPerArcmin;
< double w = targetWFOVSpin->value() * 2 * pixelsPerArcmin;
< double h = targetHFOVSpin->value() * 2 * pixelsPerArcmin;
---
> double x = (fov_w - targetWFOVSpin->value() * 2) / 2 * pixelsPerArcminRA;
> double y = (fov_h - targetHFOVSpin->value() * 2) / 2 * pixelsPerArcminDE;
> double w = targetWFOVSpin->value() * 2 * pixelsPerArcminRA;
> double h = targetHFOVSpin->value() * 2 * pixelsPerArcminDE;

< mosaicTileItem->setPos(skyMapItem->mapToScene(QPointF( mosaicWSpin->value()*cameraWFOVSpin->value()*pixelsPerArcmin / 2,
< mosaicHSpin->value()*cameraHFOVSpin->value()*pixelsPerArcmin / 2)));
---
> mosaicTileItem->setPos(skyMapItem->mapToScene(QPointF( mosaicWSpin->value()*cameraWFOVSpin->value()*pixelsPerArcminRA / 2,
> mosaicHSpin->value()*cameraHFOVSpin->value()*pixelsPerArcminDE / 2)));

< qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile FOV in pixels W:" << cameraWFOVSpin->value() * pixelsPerArcmin << "H:"
< << cameraHFOVSpin->value() * pixelsPerArcmin;
---
> qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile FOV in pixels W:" << cameraWFOVSpin->value() * pixelsPerArcminRA << "H:"
> << cameraHFOVSpin->value() * pixelsPerArcminDE;

< mosaicTileItem->setFOV(cameraWFOVSpin->value() * pixelsPerArcmin, cameraHFOVSpin->value() * pixelsPerArcmin);
---
> mosaicTileItem->setFOV(cameraWFOVSpin->value() * pixelsPerArcminRA, cameraHFOVSpin->value() * pixelsPerArcminDE);

< qCDebug(KSTARS_EKOS_SCHEDULER) << "Mosaic Tile W:" << mosaicTileItem->boundingRect().width() << "H:" << mosaicTileItem->boundingRect().height();
---
> qCDebug(KSTARS_EKOS_SCHEDULER) << "Mosaic Tile W:" << mosaicTileItem->boundingRect().width() << "H:" <<
> mosaicTileItem->boundingRect().height();

< qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile #" << i * mosaicTileItem->getWidth() + j << "Center:" << tile->center << "Rot Center:" << tile->c
enter_rot;
---
> qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile #" << i * mosaicTileItem->getWidth() + j << "Center:" << tile->center <<
> "Rot Center:" << tile->center_rot;

< //tile->skyCenter.setRA0( (center.ra0().Degrees() + (diffFromSkyMapCenter.x() / (pixelsPerArcmin * 60.0))) / 15.0);
< tile->skyCenter.setDec0( center.dec0().Degrees() + (diffFromSkyMapCenter.y() / (pixelsPerArcmin * 60.0)));
---
> tile->skyCenter.setRA0( (center.ra0().Degrees() + (diffFromSkyMapCenter.x() / (pixelsPerArcminRA * cos(
> center.dec0().radians()) * 60.0))) / 15.0);
> tile->skyCenter.setDec0( center.dec0().Degrees() + (diffFromSkyMapCenter.y() / (pixelsPerArcminDE * 60.0)));

< qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile RA0:" << tile->skyCenter.ra0().toHMSString() << "DE0:" << tile->skyCenter.dec0().toDMSString();
---
> qCDebug(KSTARS_EKOS_SCHEDULER) << "Tile RA0:" << tile->skyCenter.ra0().toHMSString() << "DE0:" <<
> tile->skyCenter.dec0().toDMSString();
3 years 8 months ago #56883

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

Initially I splitted the variable to RA/DE and pushed that, then I found out it's not really necessary and just updated one line which did the actual fix. I didn't roll back the initial change as it could prove useful for something else in the future.
3 years 8 months ago #56891

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

  • Posts: 1309
  • Thank you received: 226

I haven't used it much, but I did this quick mosaic of the Pleiades some time ago as a test. Only had time for 3 out of 4 frames, not counting an unplanned frame in the center of this compilation.

It seemed OK to me at the time, maybe a little off. But it is a somewhat small FOV. If I recall I used 5% overlap.
I will add it would be nice to be able to adjust the horizontal and vertical overlap % independently. As with a 2:3 ratio there is excess overlap in the long dimension.
3 years 8 months ago #56918
Attachments:

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

  • Posts: 910
  • Thank you received: 86
I actually collected another mosaic about a month ago. It looks much better in terms of overlaps (comparing to what I posted earlier in this thread).
Not sure why such a difference.
Different versions of KStars (Windows by the way)? Both mosaics were collected with nightly builds. Veil was probably an older build.

-- 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.
Last edit: 3 years 8 months ago by maxthebuilder.
3 years 8 months ago #56920
Attachments:

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

  • Posts: 30
  • Thank you received: 26
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.



The RA/DEC of the 4 panel jobs generated were simulated in Stellarium configured with same focal length and sensor parameters.

Result:



Success!

I look forward to trying this 'for real' when weather clears.

Thanks for everyone that contributed an especially to Jasem for taking the time to apply this fix.
3 years 8 months ago #56929
Attachments:

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

Time to create page: 0.392 seconds