19 June 2021: Our upload server https://upload.astropixelprocessor.com/ has been migrated successfully to our new office with higher upload and download speeds (nearly 10MByte/sec up/down ) ! We now have 1 general upload user called: upload with password: upload. The users upload1 - upload5 have been disabled.
31 May 2021: APP 1.083-beta2 has been released ! APP 1.083 stable will follow soon afterwards. It includes a completely new Star Reducer Tool, New File Saver Module, Improved Comet registration and much more, check the release notes here!
Strange behaviour in a mosaic, corners are stretched
Two panels of Ha, extracted from L-eNhance-frames, plus the mosaic made with them. As you can see, the mosaic definition is not very well done. But that is not the issue. If you look at the mosaic, you'll see that the corners are stretched. I also made a mosaic of corresponding OIII panels, extracted from the same L-eNhance frames. That mosaic is oke.
Because of the stretched Ha-mosaic, combining it with the OIII-mosaic is not possible.
In Analyse Stars I put number of stars to 2000. In Register I used pentagons, scale start to 5, stop to 10. I checked "use dynamic distortion correction", disabled "same camera and optics", set "registration mode" to "mosaic" en "model" to "projective". In Normalize-tab "mode" to "advanced", Integrate-tab "average", "equal", "2nd degree LNC", 10 iterations, enabled MBB, 10 %.
I remade the mosaic with "use dynamic distortion correction" unchecked. Then you get a warning from APP ("Are you sure. This is almost always necessary" (something like that)) And now it does not show the stretched corners... I think we have an APP-bug here!
Not necessarily, that warning may need to be written a bit different maybe. It's usually needed as many optics have distortion, but sometimes your data can be so nicely corrected already, that it can cause an issue. Not sure why it worked like this here though.
I remade the correct OIII mosaic also without "use dynamic distortion correction". It appears to be exactly the same as the first one. So far so good. But when I compare the OIII mosaic with the Ha mosaic-that-seems-to-be-correct-now (see my earlier reply), it becomes clear that these two mosaics cannot be registered together. In the middle the stars match, towards the edges they do not. Not only in the corners, but everywhere near the edges the stars don't match.
When I said that we have an APP-bug here, I was not referring to the message. I was referring to the stretching of the corners. And now, even after this stretching disappears, I have two mosaics, extracted from the same L-eNhance frames, that cannot be registered together. So why not confirming that there is something wrong here?
Why not confirming there is a bug? Because it doesn't have to be, we need way more study to conclude that and it works well for a whole lot of data, so that would surprise me, there always is a possibility of course. If you can share the 2 frames I can have a closer look if you want.
Go to https://upload.astropixelprocessor.com and use upload1 as username and upload1 as password.
Create a directory named “jan-monsuur-dynamiccorrection” and upload in there. Thank you!
Yesterday, after remaking the two mosaics without "use dynamic distortion correction", the Ha-mosaic did no longer show this strange stretching. But it could not be registered with the OIII-mosaic. That is the situation where we were yesterday.
This morning I was thinking: perhaps this is caused by the fact that the underlying panels were produced with "use dynamic distortion correction" on. So I reproduced everything this morning with "use dynamic distortion correction" off. Now everything is oke.
So imho we still need an explanation for this stretching, because it is so extreme. But getting this explanation is no longer very urgent for me. Perhaps it is for APP. Again, imho, it should be. Thanks for your support so far.
Yes, if one of the two did have correction on, that would be an issue as APP will have changed one panel. So that makes sense, I'll see if we can see what the distortion is about in your data.
Thank you Jan, for sharing this.
I am aware of this issue, and it will be fixed going forward when the whole registration engine gets a big update.
Right now, it is important to realize, that for the individual mosaic panels you really only want to turn on distortion correction when needed 😉 And.. it is needed when you see that registration/alignment is not good with it turned off. Then you need to enable it to get good alignment.
If you turn it on, on data where it is not needed, it can cause the optical distortion correction calculation to become unstable (very complicated regression calculus) and that is a mathematical issue which I will prevent in the future update.
I am happy to read that the solution for now indeed was found by not turning on distortion correction for the individual panels.
In addittion, the multi-channel mosaic should be created by enabling multi-channel in 1) Load. Then load the individual panels of both Ha & O3 and register the mosaic. Then you should get 2 mosaics that are perfectly registered and normalized to start with 😉
I just updated my workflow by enabling multichannel in 1) Load. And, yes, it delivers perfectly registered mosaics!