Siril needs distortion correction in stacking

Here is a image made by taking 250 exposures at 5 sec each with a Canon R5 and Sigma 40mm f/1.4 ART lens at f/1.6.

The exposures were raw converted in a complex way because of lack of support for R5 - I went from CR3–> DNG with Adobe Raw Converter, then DNG–>TIFF with Raw Therapee using linear processing only, then TIFF–> FITS with Siril 0.99.6

Here is the final image, after processing with Startools.

Unfortunately, the stars in the lower left hand corner have been turned into short star trails. Here is a close up to show that.

r_milkywaynodistcor_stacked_proc_lowerleft

At first I thought this was due to coma in the lens, but that isn’t really the case. Here is an excerpt of a similar area from one of the sub-frames. You can see that there is some elongation of the stars, but nowhere near as much as in the stacked version.

So I tried to stack the same images using Astro Pixel Processor (APP), and here is a detail from the result

The stars are MUCH better looking in the APP stack than the Siril stack.

The stars are not perfect in the single frame image - at f/1.6 there is some stretching of stars, but it is quite small.

Here is what seems to be going on. The 40mm Sigma is an excellent lens, even at f/1.6, but there is inevitably some distortion caused by the lens between the center and the edges or corners.

Siril registered the images without a lens distortion model. APP registered with a distortion model.

I believe this is a fundamental restriction Siril has, but perhaps there is a way to get the distortion corrected that I am not familiar with - I am relatively new to Siril.

The lack of a distortion model means that Siril was stacking the frames off center from each other, as one would expect for a fixed camera. The registration was likely driven by the mass of stars near the milky way. When those are in the correct position, the distortion present in the

In the case of a tracked, rather than fixed camera this would not occur if you were stacking a single frame. However, it will occur in stitching any mosaics, in the overlap region. The degree of the problem will depend on the amount of lens distortion. The 40 mm Sigma is barely a wide angle lens - with a 24mm or 14 mm lens the distortion would be MUCH worse.

Siril is not going to be able to compete with APP until the distortion model is included.

That is a shame because Siril is much faster at registration and stacking than APP. The distortion model would take some computation, but even cell phone panorama stitchers do it, so it can’t be all that time consuming.

In principle it should also be straightforward to add - the lens distortion calculation of the sort necessary is already done by any panorama stitching program such as Hugin or PTools. That said, I am not familiar with Siril internals - it’s always easy for the uninformed to think something is “easy”.

Hi, what else can I answer other than: we know, that’s a limitation, and it’s not going to happen soon, it’s not even in the list of things to be implemented. But thanks for pointing it out with pictures.

Also, it’s not a competition, if other software can do it, good for them and that also explains a part of why they are slower.

1 Like

I should not have used the word “compete” - I meant it in the sense of “be in the same quality ballpark as”.

Any user has to ask themselves “what software makes my images look best?”. They might additionally qualify that with “and is easy to use”, or “and is free”, or “executes quickly”, but ultimately it is about the image quality.

Most astrophotographers use multiple software packages as a result.

The reputation that Siril has so far is that one of its strengths is in registration and stacking. The widely circulated galaxy photo with 18,000 images is a good example of that.

But, if Siril can’t handle wide field astrophotography properly, and is only capable of handling very narrow angle, high f-number images (which are less likely to have distortion), then that makes Siril much less useful, and perhaps useless, for a lot of astrophotographers.

It is particularly ironic to make stacking a strength and yet not do distortion correction which is very stacking related.

While it would be of course impact the performance of registration/stacking opertaion, it is far from clear that it would make it slow.

APP is slow in registration, but not for any reason related to distortion correction (it is just as slow with distortion correction turned off).

I’m a little out of my league with astro work, but is this a case where something like Hugin or even align_image_stack might help correct this? I’ve used it for stacking macro images before and it seems like it might be pertinent here?

On my windows machine, after installing Hugin, I’ve used:

C:\Program Files\Hugin\bin\align_image_stack -m -a OUT FILE1 FILE2 FILE3
1 Like

Hugin definitely has the ability to correct lens distortion at the same time that it aligns images.

However, whether that occurs automatically in align_image_stack, or not I don’t know.

Yeah, that’s what I’m not sure of. I believe you could also supply lens distortion parameters to hugin in the terminal/cli and get it to fix distortion first, then maybe a run through align_image_stack?

Addendum (resources):
http://hugin.sourceforge.net/docs/manual/Lens_correction_model.html
http://hugin.sourceforge.net/docs/manual/Fulla.html