Siril 1.2.o terrible slow in converting ARW to FITS, 156 files take 3 hours

Siril 1.2.0

21:15:09: Running command: cd
21:15:09: Setting CWD (Current Working Directory) to ‘E:\A6300\06-08-2024\lights’
21:15:09: Running command: convert
21:15:09: Convert: processing 479 files…
21:16:41: Decoding Sony ILCE-6300 file (ISO=800, Exposure=30.0 sec)
21:16:41: Filter pattern: RGGB
21:16:41: Reading RAW: file DSC08278.ARW, 1 layer(s), 6024x4024 pixels
21:16:41: Number of images allowed in the write queue: 17 (zero or less is unlimited)
21:16:41: Decoding Sony ILCE-6300 file (ISO=800, Exposure=30.0 sec)
21:16:41: Filter pattern: RGGB
|
|
|
00:00:05: Filter pattern: RGGB
00:00:05: Reading RAW: file DSC08430.ARW, 1 layer(s), 6024x4024 pixels
00:05:29: Saving FITS: file …/process\light_00154.fits, 1 layer(s), 6024x4024 pixels, 16 bits
00:05:29: Saving FITS: file …/process\light_00153.fits, 1 layer(s), 6024x4024 pixels, 16 bits
|
|
|
|

After nearly three hours only 154 files converted to .fits.

Disk is Samsung T7 fast SSD on Lenove Ideapad flex5 Intel Core i5 16GB RAM

Never seen it so slow. Why?

Hi,

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?

Thanks,

Adrian.

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

IT is still running now at 7.52 next morning??

I agree with Adrian.
Please test last version before reporting bugs.

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.