Python Siril ConvertRaw - Strange Log and StartIndex behaviour

Software Siril
1

Hi there,

I’ve been using Siril now for coming up to a year, most of my processing is done in it and I’m really enjoying the output -thanks for the software it is awesome.
I understand that there are script options to automate the conversion, pre-processing and conversion within the Siril Gui scripts menu, so the Manual Pre-Processing as described in Siril Tutorials is not absolutely necessary. However, I’m really enjoying the extra control this gives.
I have decided to turn the Manual process in the tutorials into a python based automated one to cater for some specifics I do every time.
This is all good and albeit I have coded some years ago I have never touched python until now but I think I am making a reasonably good go at it.

Now the question…
Within the python script I am converting my source files. While I test this I have a directory with 2 FLAT *.cr2 files.
my python looks something like:-
cmd.convertraw ( ’ flat’, out=process_dir, start-seq_start)

This generates me 2 files converted to fit. in my <process_dir> directory. All good, however the command window tells me:-
Processing 2 flats

cd ‘/Volumes/Samsung_T5/Siril_Test/FLAT’
: log: Running command: cd
: log: Setting CWD (Current Working Directory) to ‘/Volumes/Samsung_T5/Siril_Test/FLAT’
[status: success]
convertraw flat -start=1 -out=/Volumes/Samsung_T5/Siril_Test/process
: log: Running command: convertraw
: log: Conversion: processing 4 RAW files…
: log: Decoding Canon EOS 600D file (ISO=800, Exposure=1.3 sec)
: log: Filter pattern: GBRG
: log: Reading RAW: file FLAT_2022-09-24_10-53-39_1.30s_l-enhance_0003.cr2, 1 layer(s), 5202x3464 pixels
: log: Number of images allowed in the write queue: 3 (zero or less is unlimited)
: log: Saving FITS: file /Volumes/Samsung_T5/Siril_Test/process/flat_00003.fit, 1 layer(s), 5202x3464 pixels
: log: Decoding Canon EOS 600D file (ISO=800, Exposure=1.3 sec)
: log: Filter pattern: GBRG
: log: Reading RAW: file FLAT_2022-09-24_10-54-48_1.30s_l-enhance_0010.cr2, 1 layer(s), 5202x3464 pixels
: log: Saving FITS: file /Volumes/Samsung_T5/Siril_Test/process/flat_00004.fit, 1 layer(s), 5202x3464 pixels
log: Conversion aborted, **2 file(s) created for 4 input file(s) (2 image(s) converted, 2 failed)
[status: success]

status - Success! So this seems good and I do get 2 converted files, but this seems a strange log output telling me I have 4 files to process and abandoning 2 of them. In addition, although I set the start index in this case to 1 the numbering of the 2 fits files starts 3 - as if the 2 source files are being counted - this is consistent if I process raw 4 files then the numbering starts 5 irrespective of the start Index.

I’m running this on a 2015 Mac Book Pro. I’d really like to get the start Index correct as I aim to use this script to automate my multi session processing which I separate using groups of Index numbers (night 1 - give 00000-00199; night 2 - give 00200 to 00399…).

Any suggestions or comments from the wider group would be appreciated.

2

Hi, are there other files in the /Volumes/Samsung_T5/Siril_Test/FLAT directory than the two cr2 files? I could not see a problem with this command with the development version, even when there were other files in the directory. But this surely looks like a bug, are you using version 1.0.5?

3

Hi Vincent,
Thanks for the reply.

I’m using 1.0.5. No other files in that directory just 2 .cr2 files.
image

4

It seems that often there are some hidden files along the image files in mac os directories, this is probably the issue here. Can you check if it’s the case?

5

Vincent - thanks a bunch, genius!

You are correct, for reasons unknown there are bunch of 4kB files starting ._* duplicating each of the image files.

Hidden Image Files

A little digging on the back of what you said…

Seems like for good or bad they are here to stay. I suppose I could delete them (not sure of the impact of doing that) but it would be better if they were ignored by the library. Is this also related to why the start index does not work as expected?

6

Thanks for checking it out and for the report in the first place! Don’t bother deleting them, we will just make a fix to ignore them, we had a similar report for live stacking actually, that’s what made me think it could be the issue here. It’s indeed probably why the index is wrong. Error management in the conversion process is not ideal, but at least now we know what to fix.