- This topic has 9 replies, 2 voices, and was last updated 9 years, 1 month ago by
.
-
Posts
-
So I made 11x 15 min H-Alpha subs last night, I have some 15 min darks and a BPM. Flats I didn’t make yet. I wanted to do a “quick” stack to see how it looks like. I switched off “same camera and optics” as my coma shifts slightly in seperate sessions. Registering is taking a very long time and seems to be stuck at “calculating multiple view complex model”, CPU isn’t really active either. It’s been like this for 30 min now until I cancelled it.
Turning on “same camera and optics” and it’s done within a minute.
Hi @supernov,
Probably, this is an error in the complex model regression, where the regression keeps iterating and so seems to be stuck… My guess would be that between your subs you have very little difference in Field Of View? So all images have more or less the same Field of View? What amount of dither do you apply? If this is only a couple of pixels, then I would advise to use more aggresive dithering. this will improve the distortion correction as well.
Anyway, If you send me those 11×15 min sub, I’ll try to fix this error ? probably you are triggering some exception in the complex multiple view regression algorithm.
Oh yes the FOV is exactly the same and I’m dithering a couple of pixels. Good suggestion to do this more aggressively, it might in some spots even help reducing the coma just a tiny bit if the shift is large enough.
I’ll send the subs.
Great, thanks @supernov, I’ll post my findings when I am finished with your data ?
I was wondering, maybe it’s simply better to use “same optics and camera” for 1 session and then when I register 30s, 180s and the H-Alpha to switch that off and switch on MBB.
Good and correct thought ?
Indeed, data of one and the same session should be registered with the “same camera and optics” setting. If you combine data of different sessions. The “same camera and optics” is also to be advised if you know that the optics and camera haven’t changed fundamentally. So for optics that have undergone a change in collimation or for instance an adjustment in the reducer/ flattener/ corrector distance should be registered without this setting for the most optimal results.
With the “same camera and optics” setting on, the distortion model is only calculated once and will be identical for all the frames that you register. It you turn “same camera and optics” off, APP wil calculate distortion correction models seperately for each frame ? So it should only be used when it’s needed. The registration RMS in the registration column will indicate if turning the setting off is beneficial for your data. So by all means, experiment and check the registration RMS values per frame. If you notice significant differences in the RMS values with the setting on and off, you’ll know if it’s needed ? Lower RMS value is better.
The MBB setting has nothing to do with registration. It will however remove the seams in your data if you combine data with different Field Of Views. So yes, for combining data of different sessions, I would always advise to turn MBB on. As a matter of fact, in almost all cases turning MBB on is to be advised ? It will reduce stack artefacts at the borders of your stack.
Hi @supernov,
Okay, I have been testing your data. My findings:
if we don’t use distortion correction, the registration RMS is already very good considering this is debayered H-alpha data.
Using distortion correction with the “same camera and optics” option turned on, gives a slight improvement in precision.
Using the distortion correction with the “same camera and optics” option turned off, triggers an exception in the multiple view regression algorithm. It keeps finding better solutions, but the solution becomes “unstable” due to the fact that all images have almost exactly the same field of view.
For distortion correction to work optimally, it’s better to dither more aggresively, the distortion correction will be of better quality and this exception won’t be triggered. But I need to catch this exception properly off course and prevent it from happening.
If only one of the frames to be registered has a field of view that is different by for instance 50 pixels, this exception won’t occur. So I think i can prevent this from happening by checking the homography parameters (i.e. the coordiante transformations with scale, rotation, perspective, translations between the frames) and check if all frames have parameters relative to the reference which are really similar to the identity matrix… if so. The complex model shouldn’t run.
Another solution would be to let the complex model run, but detect the solution from becoming unstable.. which would also be based on the homography parameters.
To be continued…
Solution becomes unstable indeed, the center of distortion drifts away to a value which can’t be accepted.. (Normally the center of distortion correction is near the center of the sensor)
So I’ll fix this ;-)
I at least can tell now that the use of “Same optics and camera” per session, followed by switching it off when combining all of them works amazingly well! If I don’t do it like that the stars in my coma-rich corners are misaligned by “miles”, but almost perfectly on top of each other when calculated per frame (which I hope means I can also collimate pretty well). ;)
- You must be logged in to reply to this topic.