Siril 1.2.3

July 2nd, release udpate for macOS packages # A bug has been found in macOS versions preventing the use of multiple threads during calculations. Both packages have been updated to version 2 (build number 10977). We invite all our macOS users to download the new packages. This version # Although Siril 1.2.2 was released very recently, we have to quickly publish a new version, 1.2.3. Why? The explanation is simple: several very annoying bugs have been discovered.
This is a companion discussion topic for the original entry at
1 Like

Downloading it now! :+1:
Little bug in 1.2.2: the URL mentioned in the software update pop-up, gives a 404 Not Found error.
The URL given in that pop-up is

And another very tiny bug/change in comparison to 1.2.1 and earlier: SiriL doesn’t keep itself on the foreground anymore. For example: I open Windows Explorer and drag a FITS file on the SiriL shortcut. SiriL opens it but the Windows Explorer window stays in front of SiriL.
Or when using SiriLiC: after stacking, SiriL is started but the SiriLiC window stays in front of SiriL.
So, not a major issue at all, just a change I noticed with 1.2.1 :slight_smile:

Thx for your comment.

The url is now fixed :).

The link in the message box informing users of 1.2.3 availability contains a link to 1.2.1
2024-06-23 (2)

This is known.
1.2.2 and 1.2.1 have this issue.

1 Like

Hi! in version 1.2.3 I can’t change number of threads on MacOS (M1, Sonoma 14.5). It works in version 1.2.2

Indeed. There is a bug in the packaging. We will try to produce a new 1.2.3 macOS version asap

1 Like

Issue opened: macOS package has thread issue (#1333) · Issues · FA / Siril · GitLab

1 Like

MacOS packages have been updated.
Please update :). (It is always version 1.2.3)

the button seems to work fine now, thank you!

There still seems to be an issue with multi-threading on MacOS with Siril 1.2.3 in the latest version (dated June 29). I have Mac Studio M1 and MacOS Sonoma 14.5. For example, registering of 30 images takes 13.86 seconds with Siril 1.2.1, but the identical process takes 33.87 sec with Siril 1.2.3., almost 3x longer. It seems someone has forgotten to turn OpenMP back on after testing 1.2.3. For now, I reverted back to using v. 1.2.1.

1 Like

Show us a screenshot please of the whole app.
And the log of the startup too.

Hello, Thank you for getting back on this issue. There are three screenshots - 1) Conversion, 2) Registration, 3) Stacking. All are very slow. The log is also attached. All are in the zip file. (7.3 MB)

I’m sorry, but this is someting else.
The bug of threading issue is fixed: Global star registration: with the current memory and thread limits, up to 10 thread(s) can be used

Are you sure you downloaded the Apple Silicon version?

Yes. Please see the attached Info panel.

Hello, Additional information is that the same issue of very slow processing occurs on my M3 MacBook Air.

For me, from what I see, the package is as expected.

Hello, I don’t want to be stubborn about this issue, but I downloaded Siril 1.2.3 via Homebrew and then ran in from Terminal. All runs are on Mac Studio M1 with Macos Sonoma 14.5 and with the same 30 Fits files, in sequence Conversion, Registration, Stacking. The Homebrew version runs very fast, as expected, as fast as download v 1.2.1. The June 29 version of 1.2.3 from posted package is very slow. I am attaching 3 logs: 1) Log from Siril run to Terminal, 2) Internal log from Siril run done via Terminal on the Homebrew package, 3) Internal log from Siril run on downloaded version of the dmg package from website. The stacking portion on the Homebrew version took 17 seconds, on the dmg version 1 min 48 sec. >> I do appreciate your work on Siril! <<
1 Siril run output to Terminal.txt (50.3 KB)
2 Internal log from Siril started from Terminal.txt (33.1 KB)
3 Internal log from Siril downloaded from package .txt (33.1 KB)

I understand that you’re dealing with slowness, but the package as we’ve made it restores the previous bug that didn’t use openmp. So Siril only detected one thread. Here, in your logs, we can clearly see that this is not the case:
Global star registration: with the current memory and thread limits, up to 10 thread(s) can be used
So as far as I’m concerned, it’s definitely not from this. And apart from that, nothing has changed in the way packages are built.

So I don’t see what could be slowing down the application, apart from a (bad) interaction with your system? Especially since it seems to work with homebrew, and we haven’t had any other reports of slowness.
I’m sorry, we’re not macOS experts and I don’t have a solution. I’ll pass the message on to our macOS maintainer, but as I said: threads are detected, so the problem originally discovered in the first package of the version 1.2.3 is fixed.