StarAlignment Compute Intersection

[ngc1535]

OK...this has been driving me crazy.
Is it possible I have found a bug?

Consider the situation:

1. The reference view has a preview.
2. Register/Match images is chosen
3. Mosaic Modes only: Restrict to Preview is checked (it is the default)

In the above case StarALignment uses the preview! However a Mosaic Mode was not selected.
This of course caused my registration to fail since it was only using a tiny preview to match stars and compute a solution.

If I remove the preview in the reference view... everything is OK. Is this the proper behavior? I would have expected the preview to be used ONLY if in a Mosaic mode.
If this is correct behavior and not a bug..I strongly recommend the default state of the SA process should not have this box checked. I happened to have a preview and did not
notice it was restricting calculations to it. It is indicated in the console...but because I was not expecting this...I didn't catch it.




P.S. If this is an issue/bug...it existed in the previous version.

[ngc1535]

I just want to follow up on this...
If you do not open the Star Matching panel/tab when using StarAlignment... you would never see the default selected restrict to preview checked. I had a preview on my view for a prior step and it was not intended to be used by StarAlignment.
-adam

[pfile]

i think it makes sense to restrict to preview even when not doing mosaics - for instance if you have a widefield image and a narrow image you may need to restrict the wider view to the FOV of the narrower image. it may work without it but especially when there are scale differences the preview restriction helps a lot.

rob

[ngc1535]

Rob,

I think that is fine... but as a default, if you happen to have a preview and did not notice it was using the preview for the star matching (because you did not open the Star Matching panel) it will cause all kinds of havoc. Items in the Star Matching panel "Under normal situations do not need to be adjusted."

Do you see my issue? If you happen to have a preview in your view from some prior step- and you assume that no parameters in Star Matching need to be adjusted (so you do not look there)- you might be surprised that it is using the preview since this was not intended. Would you not agree that forcing it to use the preview should be checked by hand whereas using the entire image is the default and expected behavior? I just think this should be something you turn on...not turn off.

In addition, the panel is not clear to me in the send that "Restrict to Preview" looks like an option for Intersections. I think a label of "Additional Options" or something for the following three check boxes would make things clearer.

Using a small piece of an image to compute a transformation for a wide field of view gives a much worse result. It seems that computing the average of distortions across the field (perhaps with the local computations of the thin plates) is much better.

-adam

[pfile]

yes i understand what you are saying, i guess i was responding more to your first post.

i think this is something that's rarely seen as when running exclusively on files (which is probably how people use it 99% of the time) the state of the checkbox is not relevant as there's no way to have a preview defined on a file.

i suppose it is confusing then when this happens.

rob

[ngc1535]

The reason I had to operate on views is because of the use of MURE denoise. I had binned data and you do not want to upsample the images (the files on disk) before applying MURE denoise. So I did MURE denoise to the combined RGB and then registered these views to the luminance view.

This isn't too rare- and to be honest, it could be the pitfall that causes people to not use MURE denoise. You will not be able to get a good result if you upsample binned data.

-adam

[Juan Conejero]

Hi Adam,

What you are describing is normal behavior, not a bug. However, I agree that this feature is too important and modifies SA's behavior in such a critical way, that it should be either more visible on the user interface, or its influence should be notified in a more clear and prominent way, to prevent confusion. I'll think about how this can be done in an update to the SA tool, thank you for pointing this out.

[ngc1535]

Thanks Juan. I appreciate your response.
I think that simply making SA alignment act on the whole image as a default is the way to go. (So an unchecked restrict to preview.)
One reason is that the whole image processing is what is expected based on on-disk file processing (as Rob notes which is 99% of usage).

The other subtle thing is that operating on/using a preview as a default breaks a kind of philosophical use of previews. Previews represent instantiations of the data...but not the actual underlying data itself. It makes sense, to me, that the default behavior for a process is to first apply to the actual data- with features or options to use instances of data subsets.
I see it kind of like the usage of previews to define the background for some of the color processes. You would not expect it to use the preview to define the background by default... instead you optionally force this to happen.

-adam