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.


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):

Same issue here.

I tried to do the lens correction in Darktable after pre-processing the lights in Siril, and re-importing the corrected lights into Siril, but ran into some issues with keeping everything linear, since:

  • Darktable doesn’t read FITS files
  • Siril can export FITS to TIFF, but it doesn’t keep them linear, it exports it to sRGB…
  • I haven’t found any other software that can do lens correction on FITS directly, or convert FITS to TIFF in the correct colour space. I tried ImageMagick’s convert, but it also changes the brightness.

We know about it. However distorsion is not an easy issue. If lens can be easily characterized it is not the same for telescopes.
So we know about it, but it is not a priority.

That’s strange, I have done that many times to create a DNG after doing average stacking without alignment (which preserves things as being Bayer-mosaiced)

Convert most definitely does not change the data. Most likely the problem is that convert does create a TIFF without any embedded color profile, and you need to add an appropriate ICC profile or software will assume it’s sRGB. (Almost all software assumes no profile = sRGB transfer function and gamut). I think dt allows you to override the input profile that is assumed/detected, it has been a while.

Darktable assumes Linear Rec709 RGB when no embedded colour profile is found.

I might be doing something wrong, but I simply used convert -format TIFF output.tiff on the pre-processed lights, and after importing them in Darktable it is clear that something went wrong because the image is way too bright, and if you try to apply the lens correction it massively overcorrects vignetting.

Importing the TIFFs as exported by Siril looked OK in Darktable, but after exporting (as Linear Rec2020 RGB TIFFs), and re-importing them in Siril, registration failed, which I assume is because Siril exported the TIFFs in sRGB.

I only notice it now, but the TIFF that convert outputs also lost color. It’s monochrome.

Interesting. Maybe that’s part of why I had no problem - I had the siril pipeline set up such that the output was still Bayer-mosaiced and Bayer data is the same as a monochrome image.