Registration Exception - Index -6 out of bounds

A couple of updates on this. My rerun encountered the same problem again, so I went back to reproduction on smaller datasets.

I found it's actually fairly easy to trigger this problem and it doesn't appear to be very dependent on which frames I choose. I might be able to get it down to 4-5 frames. Let me know how to upload if you'd like to run it in a debugger.

1) The exception is always due to index -6, regardless of which - or how many - frames are used. Hopefully this is a useful clue.
2) The problem does not occur if the only change made is switching the registration model from 'calibrated projective' to 'projective'.
3) It doesn't matter whether the calibrated projection method is rectilinear, equirectangular, or mercator - the exception still occurs.
4) For some datasets, the problem does not occur if the distortion margin is set very high. In this case, registration for all frames is successful.

Thanks for the elaborate explanation! For us to be able to see where the problem lies, we would need your data as well (the small dataset where the issue occurs would be nice). Are you able to upload those? The username and password are NOT those used on this forum, but simply: upload

Uploaded 7 frames.

Repeatable with the settings I described above, but use distortion margin = 0.005, and set the reference frame to DSC_2474_REFERENCE.NEF.

Thank you for taking a look!

Thanks, we'll have a look and see if it is a data issue or bug.

So I tested registration with the files, without changing any of the standard settings (star count at 500), they all registered fine in the first try. Then after that it failed on 2 frames (but not with an error). I do see that the stars are very elongated in some of them, was this without tracking?

Yes untracked.

If you use star count 500 it may converge, but to a really bad RMS error (7.0+) I think?

I increased the star count incrementally after seeing the RMS error. At around 3000 stars the RMS error is as low as I can get it (when paired with high scale stop and high distortion margin, projective mode), ranging 0.25 to 0.65 across all 1021 frames. If you can do better than that I would like to know what settings you are using but I feel like I have tried every combination. The frames I gave you are obviously the 'hard' cases, but about 30-40% of my data is equivalent so tossing them is a pretty massive sacrifice. (If you think that's just what I have to do though, tell me)

I was able to get through the whole integration with projective registration, but cannot with calibrated projective. I wanted to use the calibrated projective mode because in tests with a subset of my lights, it showed better RMS error compared to 'projective'. The problem is, the algorithm crashes with the out of bounds error when used on my full set of lights.

I am wondering:

1) Does high distortion margin and scale stop cause problems with images that have significantly different views/orientations (i.e. the Milky Way is sometimes a little more horizontol in the frame, sometimes a little more vertical). In my stacked images, I think (but will have to check again when I get a chance) there was more star elongation in the top right / bottom left corners when compared to the individual subs.

2) Why is the out of bounds error happening?

Ah yes, it may get better, but the RMS will also be rather high because of the differences in elongation. If the stars differ quite a bit between subs, that won't help getting that down much.

1) It may very well, I don't have very deep knowledge about the algorithm used here, so if you want I can ask Mabula for specifics. Having better data does make it much easier for the algorithm though.

2) Good question, that we should investigate here. My suspicion is that the statistics are getting hay-wire for some reason, perhaps by it not able to fit the data properly.

Thank you Vincent for the input.

1) I tend to agree, though I'm realizing I can probably run some tests to answer my own question. If I find anything I'll share for anyone reading in the future (might be a week or two as I'm moving).

2) Probably. It would be nice if it simply 'failed' to register some frames so I could cherry pick those out and continue. But ultimately I'm just trying to improve the stack with the stretched stars and I now think I need to focus on (1) for that, so unless someone else runs into this error too I probably wouldn't spend much time on it.

Yes I agree we could use some better error messages in these cases. Let me know how your investigation goes.

To follow up on what I said I would, I did not really find any improvement or anything really interesting by using different scale stop and distortion margin values. Star elongation doesnt really change with those settings, although it does seem that star elongation is a little worse in the stacked image compared to the subs. I am not entirely sure why other than simply not having great data (I did the absolute best I could without a tracker), putting a limit on how good the registration can get. The best RMS errors I was seeing ranged from low 0.2s to high 0.6s, across all 1023 frames (shot over two nights with same optics and settings). This required maxing out scale stop and distortion margin as mentioned before, but lower distortion margins worked too - they just did not change registration results after a point.

One thing I did find was I had to pick a reference frame that had the Milky Way oriented how I wanted it in my final image rather than letting APP pick the reference frame. Letting APP pick the reference frame did not work well because in some of my subs, the Milky Way is just above the horizon - and APP wants to use one of those. Using such a sub as a reference coupled with a UWA lens led to poor registration and/or distortion in the regions of my desired view that were not in the APP-selected reference frame.

Thanks for the follow up! Yes I think the quality of the data without tracker (although very good for not using one) is still not good enough to improve registration much, which would make sense. Indeed being able to set your own reference frame is why we have that option, APP chooses the best quality frame otherwise.