Stacking artifacts in latest development version

I have been having issues with my latest images (since about 2 weeks ago), where I see artifacts (the kind I believe you would get without dithering) on the stacked results. I first thought that was a mistake on my end, so I reprocessed some older data, and the same issue occurs. I believe this all started when Siril switched to 32 bits (I’m on Linux Mint 19.3 and installed Siril from the PPA), although it might not be related to this specific change.

The first image below is what I get in the latest version. The second image is what I obtained 2 months ago with the then-latest version. They are both stacked in the exact same way, except for the reference image for registration.


On an unrelated note, I shoot from KStars/Ekos, and when I open my picutres in Siril, they are mirrored vertically, is this normal behavior?

This issue is because you need to do dithering during your captures. I don’t think that is a bug in Siril, but maybe now it is more visible.
I use this version almost everyday with no stacking issue.

We can see that the problem is in the two images. More visible in the first maybe because rejection was not identical, or other things different.

Now that you mention it, it is quite visible as well in the older version. I was dithering when I captured this target, though, maybe I need more distance between each picture? From what I can see, I have roughly a 10-20 pixel shift between exposures, is that not enough for a DSLR?
If increasing the dithering distance is enough to solve this, then I’ll just have to capture more data and play around with the dithering settings.

Edit: Okay so I just stacked another set of pictures and had no issue with it, I must have messed something up in Ekos in the recent pictures. Sorry about all this. Still, do you have any idea what could cause the dither pattern to be that much more visible in the newer version on Siril? I never change the sigma values in the rejection settings, so I doubt that’s the only difference.

Yes KStars creates images upside-down unfortunately…

Maybe there is an issue in the new version, maybe rejection changed or rendering of the image changed? Can you make sure you use the same reference image?
I’d say 1 or 2 pixels is enough, the goal is not to have stars aligned exactly at the same sub-pixel value; they look like a Gaussian and we align the peaks together, the peaks can be at for example coordinates (50.17, 120.52) for a star in one image, if it becomes (50.83, 120.08) it’s already good I believe.

Some bugs have been fixed, so for a same sigma the rejection may change. But I don’t think there is an issue right now.

Okay, so I tested stacking some more pictures today, and going back to the one I posted above, and… well I can’t even see the dither pattern anymore, so I must have done something very very wrong without realizing it last time. Again, sorry for what was most likely just a silly mistake on my end. Here’s what I got in the end:

Just a quick question as it happened to me earlier and I haven’t checked the issues on GitLab: is it a known bug/issue that converting images sometimes fails for some pictures? I had to click convert 4 times to get all 60 pictures in the sequence, as it would randomly fail and convert only 12, 20 or so pictures. Here’s part of the console’s log:

19:17:17: FITS error: failed to create new file (already exists?):
19:17:17: Reading FITS: file M 42_Light_028.fits, 1 layer(s), 6000x4000 pixels
19:17:17: FITS error: Light_00016.fit
19:17:17: Error while converting to FITS (no space left?)
...
19:17:22: Conversion ended with error, 12/60 input files converted

This can happen on the first try, when no file already exists in the folder, and while I have hundreds of GB of free space.
And after clicking Convert again:

19:19:25: Conversion succeeded, 60/60 input files converted

No it’s not a known issue. But are you converting a FITS to a FITS? That may be a cause to it, there’s probably no need to do this.

I thought doing this was the only way of generating a sequence (since it does also support importing FITS files). Is there another way to create a sequence directly from the FITS files? That would surely make things easier and faster.

Yes, when siril looks for a sequence in the current working directory, it looks for files with a name ending with a number and the configured extension (by default .fit). If it finds several numbers with the same beginning of name, it’s a sequence.
So basically, name_010.fit and name_020.fit are a sequence.

If your acquired files don’t follow this scheme, you can simply rename them (or make symbolic links). Conversion should not be done for FITS.

I see, I actually never changed the default .fit extension, as I thought that was just Siril’s export format. Thanks for the tip!