I’m probably not the right developer to address this as you’re reporting it from Windows (also I don’t make much use of raw files myself) but I’ve highlighted it on our internal message channel.
I notice you’re using 1.2.0. That’s quite old now and there have been a signficant number of bugfixes in the 1.2.x releases since then. Please could you test with 1.2.3 and see if the issue is still there. You mention you hadn’t seen this degree of slowness before - please could you mention what version of Siril showed better speed, and ideally state what the time is to process 154 files using that version?
Well 1.2.0 is not that old. And a lot of new bugs where reported in that new version , so I like to stick with it till all issues are gone. I do not keep track of resukts of older versiojns the I got now. And 1.2.0 was always speedy enough.
And it is still running now. At 5.45 it finished the conversions. And proceeded with the rest.
This should not happen on any version wahet so ever. I am running startrails. and have still 350GB availkable.
5:45:21: Saving FITS: file …/process\light_00478.fits, 1 layer(s), 6024x4024 pixels, 16 bits
05:45:21: Saving FITS: file …/process\light_00477.fits, 1 layer(s), 6024x4024 pixels, 16 bits
05:45:21: Conversion succeeded, 479 file(s) created for 479 input file(s) (479 image(s) converted, 0 failed)
|
|
|
7:51:47: Bayer pattern found in header (RGGB) is different from Bayer pattern in settings (GBRG). Overriding settings.
07:51:47: Filter Pattern: RGGB
07:52:00: Reading FITS: file light_00296.fits, 1 layer(s), 6024x4024 pixels, 32 bits
07:52:00: Bayer pattern found in header (RGGB) is different from Bayer pattern in settings (GBRG). Overriding settings.
07:52:00: Filter Pattern: RGGB
1.2.0 is the first release in the 1.2 stable series. This is now up to 1.2.3. Unlike some software Siril’s micro releases do not introduce new features, only bug fixes. You should therefore always try to be running the latest stable version.
In this case, from discussion with one of the other developers it appears likely that this issue has been fixed in 1.2.1 and later - there was an issue with memory limits not being applied for file conversion with debayering, so your system is probably swapping like hell which explains the extreme slowness.
So, as I said, please test with the latest stable version to confirm whether that fixes your issue.
Ok I have installed the latest version now, restarted all and and will try again. Until yesterday 1.2.0 was very stable for what I did. So I was a little suspicious about the “try the latest version” answer. But since the slowness was noticed in more cases as you said, I give it a go. I was trying to make a startrial of 480 30sec subs. It has done 480 conversions now in 20 minute so that seems solved indeed. Is now running the registration etc. Thanks for looking into this.