15th Feb 2024: Astro Pixel Processor 2.0.0-beta29 released - macOS native File Chooser, macOS CMD-Q fixed, read-only Fits on network fixed and other bug fixes
7th December 2023: added payment option Alipay to purchase Astro Pixel Processor from China, Hong Kong, Macau, Taiwan, Korea, Japan and other countries where Alipay is used.
after several days on a modern PC, the registration process is still not ready. I don´t get it, why it takes so much time. All other programs I know, need not more than about 1-2h, but not 3 or 4 days without result ?
Thank you for your question and welcome to the forum.
This will likely be caused by the settings that you are using in registration and the amount of stars that you have detected in your frames.
How many frames need to be registered?
How many stars were detected?
Have you set registration mode to mosaic mode perhaps?
Which scale stop is being used ?
What descriptors are you using? Triangles, qaudrilaterals or pentagons ?
For normal registration tasks, registration should be very fast and accurate, so any extra information on the data that you are processing is much appreciated 😉
If you are making a mosaic, chances are you trying to create the mosaic in one go from 100s of frames? If that's the case, then yes, it will take very long and it's not the recommended way. There is a much better and faster way to do it. Let me know if that's the case and I'll explain,
Yes, that was my expectation. Running 147 frames in a mosaic registration mode is overkill and not very efficient. Let me explain:
The mosaic registration mode will, for each frame to be registrated, try to succesfully register each frame to at least 10 other frames in the mosaic. That will give the needed information to automatically construct a mosaic, so the application learns how all frames are related to each other.
How is your mosaic composed ? Is it like a conventional mosaic, like 2x3=6 or 3x3=9 panels perhaps ?
The following workflow is more precise and much more efficient time wise:
1) first integrate the separate mosaic panels by using the normal registration mode. That will give you your mosaic panels and has dramatically reduced the amount of frames you need to register for the mosaic.
2) register and integrate the mosaic using the mosaic panels integrated in step 1. If it's a 3x3=9 panel mosaic, then at this step you only need to create the mosaic from 9 panels. Which should finish rather quickly.
Let me explain in more technical details:
if you run mosaic mode with 100 frames, then APP will try to determine registration parameters for a mosaic for all those frames all in once calculation, which is hugely complicated. If you use dynamic distortion correction, this means that APP will need to calculate 100 * 16 = 1600 registration parameters in one go... only do that if you actually have 100 mosaic panels for your mosaic. Then, yes APP will take considerable time, but it will still be much faster than having to this in other applications that can't construct the whole mosaic in one go.
If you run the mosaic mode only on previously integrated mosaic panels, then it shouldn't take much time.
If you don't have clear mosaic panels, but your images are just scattered across a big field of view by having shot the images at different sessions. Follow the same principle: first reduce the amount of frames considerably by making several panels and then create the mosaic from those panels.
Always use both LNC + MBB in integration of the individual panels and the actual mosaic. If you use LNC+MBB on the individual panels, chances are you won't need to crop any border of the individual panels due to possible stack artefacts. LNC + MBB will greatly reduce stacking artefacts.
Hi Mabula, as I understand, the "mosaic"-option in APP is not the same as the mosaic-option in "deep sky stacker". Now the registration has ended very fast. Thank u for your tip.
Hi Mabula, as I understand, the "mosaic"-option in APP is not the same as the mosaic-option in "deep sky stacker". Now the registration has ended very fast. Thank u for your tip.
Now I hope, the integration will run through 🤗
@bayjoe, indeed, there is some confusion in the community about what a mosaic technically is and what not I think.
DSS' mosaic function is really not a mosaic as far as I am concerned. It's a composition mode that just shows all pixels in the integration of all frames. But DSS makes no attempt whatsover to register a mosaic. It can't. The DSS mosaic setting has no influence on the registration so calling it a mosaic is bad naming I think. In APP this is called the full composition mode in 6) integration what is used by default.
Technically, a mosaic is a dataset that has some frames that have 0% overlap with the chosen reference frame. Then you can call it a mosaic technically and the registration can only solve that in the mosiac registration mode. A dataset like that can not be registered by DSS at all.
So if you have data that is spread over a large field of view, but where all frames have some overlap with 1 or more other frames, then this can simply be registered in the normal registration mode without using the mosaic mode.
Here is good example, this would be called a mosaic by DSS users, but it really isn't a mosaic and it was registered in APP using the normal registration mode.
It's data shot with a Nikon D5100 and a 50mm objective using a simple tripod without tracking. Iso 1600 and exposure of only 2.5 seconds.
So it's a wide field of view, a nice panorama, but all frames have overlap with the frames in the center of the field of view, so this is technically not a mosaic and approaching it as a mosaic will only complicate things without a reason to do so.
in 4) register, use,
same camera and optics on
dynamic distortion correction on
registration mode normal (so not mosaic!)
projective model
Registration is then fast, optical distortion correction is very accurate as well.
first image shows registration & integration of 20 frames of dataset, the other 2 of 200 frames.
It must be a bug in LNC then, I have never encountered it myself unfortuantely and you are the first to report it. Maybe some extra information is usefull so I can look into it.
How many frames were you integrating? Camera ? amount of pixels? Any information can be usefull 😉
I integrated 147 frames. The cam is a ZWO ASI 1600MCC, the frames have a resolution of 4656x3520.
The frames were calibrated, debayered and flattened with Pixinsight. The format is FITS 32 bit IEEE 754 floating point, so the range is from 0-1 (don´t know, if it´s important 😀 )
The frames were not aligned, so I registrated them with APP and saved the registrated frames. In the list of the lights the unaligned frames remained. I don´t know, if that´s the error, because when I exchanged the unaligned frames with the aligned, the integration run´s through.
The result of the first integration was a frame only with value 1 😆 , the name is
The frames were calibrated, debayered and flattened with Pixinsight. The format is FITS 32 bit IEEE 754 floating point, so the range is from 0-1 (don´t know, if it´s important 😀 )
Yes, thank you that's usefull information. APP is compatible with this dataformat and data range, APP uses the same for the 32bits data 😉
The frames were not aligned, so I registrated them with APP and saved the registrated frames. In the list of the lights the unaligned frames remained. I don´t know, if that´s the error, because when I exchanged the unaligned frames with the aligned, the integration run´s through.
Yes, if you save them then afterwards, remove the unregistered frames from the list. And load the registered frames as new lights. But you don't need to save them after registration, you could proceed directly to integration 😉
The result of the first integration was a frame only with value 1 😆 , the name is
Thanks, I am sure then it's a bug in LNC of the 8th degree. I need to have good look at it and I will. Thanks a lot.
