Hello,
I’m developing a new planetary alignment algorithm within Siril.
First tests are promising, but I got a question about coordinates.
Starting with my main alignment function:
int register_lena(struct registration_args *args);
I use here the args->selection to get the reference zone to use for alignment.
Yet, when I read pixel values like: in
WORD v = img->pdata[layer][x + y * img->rx];
I see that y axis is top-down - even when img->top_down is 0 (eg. when I include TIF into a sequence).
Do I miss something?
What is the correct “formula” to apply correct translation onto selection’s coordinates before getting my v variable?
Accordingly, should I change best shift dx/dy that algorithm finds before set_shifts() function?
Thanks for your help!
Hello.
No, it’s Siril’s curse :). In fact, there are several top_down flags with different meanings. Even for us, it’s … complicated. We’re working on some MRs to make things more consistent, but it’s not easy at all. [1,2,3]
But Siril always displays images with an inverted y-axis, which is how the image is displayed on screen.
One question, in planetary stacking, it is difficult to obtain good results without multipoint alignment. Is your algorithm multi points or mono point? I can’t imagine a monopoint algorithm giving good results, especially now with HD films.
[1] : Inverted images processing SER files (#1261) · Issues · FA / Siril · GitLab
[2] : Registration on SER has Y mirror (#1258) · Issues · FA / Siril · GitLab
[3] : Fix #1261 (!626) · Merge requests · FA / Siril · GitLab
You can read comments too.
Well, as you probably noticed from our previous discussions, I’m far from being an expert in alignment or related theories… I’m thus unable to state if the algorithm is multipoint or not; maybe you’ll be able to share your views after this short description of the algorithm:
- user is supposed to configure a selection zone (x, y, w, h), on which the algorithm (named LENA) will be applied,
- on the reference image, a threshold is considered; below it, pixels will be zeroed (as the result that we can get visually using the “cut” function from GUI),
- here, two fingerprints are computed. Both are one dimension array. The first fingerprint will be of len w, and item of index i within array will be the sum of non-zeroed pixels of “column” x+i within the selection. Conversely, second fingerprint’s len will be h, and each item i will here be the sum of the corresponding “line” y+i within the selection.
- for each image to be aligned, we re-compute the two fingerprints. But multiple times. For example, the “vertical” fingerprint will be computed with offset o varying from -dx to +dx. So that vertical_fingerprint[i] will be “column” x+o. We are then computing the difference between this fingerprint and the vertical fingerprint of the reference image ;
- Difference between fingerprints fp0 & fp1 is simply computed by adding absolute values of fp0[i] - fp1[i],
- Obviously, idea is to get minimal difference to get correct offset for a given axis; this will be the alignment’s shift on this axis.
To be clear, for such an raw image:
We may find & use following zones for alignment:
Assuming a threshold at about 70% of pixel’s max value. I would say algorithm is not monopoint thus - but it also depends of input images. I’m not sure I thus be qualified as “multipoint”.
Yet it gave quite good results for now:
Or:
And I may add too, as a novice’s remark, that multipoints’ algorithms are obviously stronger, but that I had many good results with KOMBAT (which is simple and NOT multipoints). Results that I couldn’t afford by running AS!3 and others tools - as my Linux box sometimes crashes using large SER with Wine, and also as, even if others non-native tools won’t crash, they are so terribly slow vs Siril that minor differences in final images do not worth the effort, at least with most of my data. To illustrate this, I’m allowing to join here my first mosaic (2-panels) aligned with KOMBAT:
Concerning my final question, I’ll keep with y-inversion as is and see later thus.
Well, in fact, too me LENA mimics the usage that we’re making of “manual registration” stuff.
