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.

Any update on this? Still haven’t found a good way to go about this.

I’m not necessarily asking for a lens correction feature in Siril (although that would be optimal), just for a (linear) workflow.

To recap, the issue is that no image processing software I know that features lens correction can read FITS, so I need to convert the pre-processed images from Siril to e.g. TIFF. However:

  • Sequence export to TIFF in Siril converts the colorspace to sRGB
  • ImageMagick doesn’t seem to understand the RGB FITS files, converting them to a TIFF with 3 greyscale images.


No, we are not working on it and it is not scheduled.

I get that, but I don’t understand why Siril exports TIFFs in the sRGB colorspace. Why is that? Isn’t Siril geared towards a linear (scene-referred) workflow?

If I understand correctly, if you keep the entire processing in Siril, everything is kept linear. The TIFF export is the exception to that. Why?

Moreover, when exporting a single image to TIFF, Siril warns you that “what you see is not what you get” when the viewer is not in a linear mode. This suggests to me that Siril does (mean) to export images in a linear colorspace. Is it actually doing that, and just setting a sRGB color profile in the TIFF erroneously?

The Tiff file is intended to be the last step of the process. Once the image has been delinearized. Moreover, it is not mandatory to save the ICC sRGB profile.

It is true for any file format. This is just to warn the user that the viewer is not set to linear. Nothing more.

I’m not sure what you mean by “it is not mandatory to save the ICC sRGB profile”. Is there an option to not do that? Regardless, I don’t see what the point of that would be. If the image during export is (forcibly) converted to sRGB, why would you not want to attach the ICC sRGB profile?

What would make more sense, is an option whether or not to convert to sRGB in the first place.

Okay, but the message implies to me that the export is supposed to be linear (while the editor is not), but maybe I’m misinterpreting it.

So glad I came across this post.

These images are exactly the kind of weird distortions I end up with when processing my 13mm images. The “square stars” (which my brother found hilarious and had never seen in his own astro work before), weird and inconsistent star trailing … often within the same image, on images that shouldn’t have any star trailing at all, are all here in your example images as they have been all throughout most of my wide field processing in Siril.

I thought it was the lens I was using but when I tested the lens it out specifically for these distortions they weren’t there. Even more folks typically pointed out how very low the distortion in the lens is as compared to many wide angle lenses and yet there I was: square stars and all.

So this is definitely a thing.

And since it appears that wide field stacking is not a Siril development priority and probably won’t be anytime soon that leaves me a tad frustrated at the moment, tbh.

Not so much regarding the lack of priority since priorities are what they are. But, more that I have been using SIril pretty much exclusively since I started this journey about a month ago. And it seems that so many of the issues I have been running into, and that I have spent north of a hundred hours working on because I just assumed my ignorance was the problem, have instead ended up as, basically, “Siril is no good with wide field substacks and probably will never be; shoot longer lenses or use something else”.

I’m not upset about this as a reality of the program but I am frustrated that nothing in Siril ever told me that. Nothing in the tutorials ever pointed this out. I have only discovered this as a truth built into the fabric of Siril, and its development priority scheduling, by finally giving up in frustration and scouring forums. It is only through those posts that I have come to see the many “don’t use wide field” as an implied, or occasionally explicit, refrain to folks asking for help.

Siril works fine, for the most part, for my 100mm+ substacks taken on my Nikon. It even has done ok with my Sigma 18-50mm lens on shots taken around 50mm. But my 13mm has been a miserable experience thus far and given that that lens was built, among other things, specifically for astro photography I have been very confused why my results have been so bad.

Not sure what to do, honestly. I like Siril and have learned a ton on it but at least half of the images I take are intentionally wide field and will continue to be so.

I don’t know.

Maybe I’ll try to figure out the other programs and generate a workflow I need to automate all the pre-Siril work that is required to help Siril produce what I know it is capable of producing. I’m on Linux so it isn’t like I have too many choices, here, that I know of but I pretty sure I have more than enough available to me to cobble something together.

Pixinsight works on Linux but trying to acquire an evaluation license from them is, ironically, how I landed on Siril to begin with. I’ll try them out and see if they are any better but I have no reason to believe they are, one way or the other. I’ll look into some of the other programs mentioned in this thread and see what can work and what can’t.

I’ll figure out the workaround but maybe Siril can, for now, post a warning in the application that many of its features will fail, or work sub-optimally, on lenses below “insert focal length here” so new users can at least have a heads up on this. It is not a problem that Siril doesn’t cover these focal lengths well, it is what it is, but it might help out those that don’t know that it is a thing so we don’t waste so much of our time trying to get results out of Siril that it just can’t, and maybe never will, be able to give.

I am a very stubborn person when it comes to learning things I’m interested in but even I have been starting to reach the point in this journey where I’m questioning if I’m actually good enough to do any of it given the crap results I have been getting. I’d hate to think that I might have walked away from all of this cool astro photography work thinking myself simply incapable when it was actually the software that I was using, not me.

So maybe help us newbies out with a well delivered heads up?

1 Like

Siril only appends the sRGB color profile to the tiff file but it does not transform the image data accordingly. So as long as you didn’t apply a non-linear processing step to your data in Siril then the image data will still be linear.

1 Like

Thanks a lot for this, interesting. I have a question though: why? That doesn’t make any sense whatsoever if the image is not actually converted into sRGB. It will only cause other software opening that image (Darktable in my case) to misinterpret the image, since it is not actually in sRGB.

Next question: what is the correct colorspace? Rec2020 linear, Rec709 linear, or something else even?

Siril gives you the option to write a tiff file with or without appending an ICC profile. However, Siril is not color managed so appending an ICC profile to the image data does not make much sense IMHO. I think you might find this discussion helpful Siril Colour Management

Right, a color managed application like darktable will apply the sRGB TRC to the data accordingly even though the data is not sRGB. In addition, Siril does not apply the display transform to the image data rendered in the preview. Therefore, the Siril preview image is not actually linear.

The raw image data loaded into Siril will be in (linear) camera RGB. Siril does not apply a color correction matrix (CCM) like other raw converters such as darktable. Therefore, if you are only applying calibration frames (darks, flats etc) and staking lights then the final staked image will remain linear camera RGB. However, applying operations like photometric color calibration or a histogram stretch will shift the data into a different (local) color space - but most likely not sRGB.