ART-cli takes a long time to run if there are RAW files in the working directory

[Matthew Arnison]

If I run ART-cli from a working directory that contains RAW files, then it takes a long time to run, even if it hits an error such as an input filename that doesn’t exist.

E.g. in a folder containing 25 large RAW files, this ART-cli command takes about 18 seconds to exit with an error if I give it a nonsense input filename.

$ ART-cli -V -Y -t -o temp2 -c iamnothere.ARW
...
ART, version 79158603f, command line.
"iamnothere.ARW"  doesn't exist!

The -V verbose output contains these lines indicating that all of the RAW files in the folder are being read:

SONY ILCE-7RM4A   100ISO 0.005s: MEAN of
    DSC01981.ARW, DSC01984.ARW, DSC01980.ARW, DSC01982.ARW, DSC01986.ARW, DSC01985.ARW, DSC01987.ARW, DSC01988.ARW, DSC01991.ARW, DSC01989.ARW, DSC01992.ARW, DSC01990.ARW, DSC01993.ARW, DSC01996.ARW, DSC01994.ARW, DSC01997.ARW, DSC01995.ARW, DSC01998.ARW, DSC01999.ARW, DSC02003.ARW, DSC02001.ARW, DSC02002.ARW, DSC02000.ARW, DSC02004.ARW, DSC01983.ARW,
SONY ILCE-7RM4A FE 85mm F1.8   85mm F16: MEAN of
    DSC01981.ARW, DSC01984.ARW, DSC01980.ARW, DSC01982.ARW, DSC01986.ARW, DSC01985.ARW, DSC01987.ARW, DSC01988.ARW, DSC01991.ARW, DSC01989.ARW, DSC01992.ARW, DSC01990.ARW, DSC01993.ARW, DSC01996.ARW, DSC01994.ARW, DSC01997.ARW, DSC01995.ARW, DSC01998.ARW, DSC01999.ARW, DSC02003.ARW, DSC02001.ARW, DSC02002.ARW, DSC02000.ARW, DSC02004.ARW, DSC01983.ARW,

If I run the same command in a folder without any RAW files, it exits with the same error immediately.

[agriggio]

From your output, it seems that ART is interpreting the raw files in the current directory as dark frames, from which it computes a “master” dark frame by averaging several ones. What is the value of the DarkFramesPath entry in your options file? Try setting it to a non-existing directory and the problem should go away

[Matthew Arnison]

That’s a great work around, thank you. I’m using it and it’s a big time-saver.

Would it be helpful for new users to change the defaults to avoid this behaviour? Custom dark frames and flat fields are a very advanced and niche use case, while running ART-cli from inside a folder full of RAW files will happen very often. It is off-putting to have the ART-cli command take 10 s just to say file not found, and to have a 15 s raw processing operation take 60 s instead. On top of that, if it’s somehow actually applying the dark and flat fields automatically based on whatever RAW files in the current folder, that could cause unexpected problems.

[agriggio]

do not scan for dark frames or flat fields if the relative entries in options are empty

See #231

→ <<cset 229f3071844d>>

[agriggio]

I’ve changed the default behaviour. Thanks for the feedback!

[Matthew Arnison]

I've confirmed that with the default empty settings for those entries in the options file, all RAW files in the working directory are no longer read in and the CLI runs much faster than before.

Much better now thanks!

[smartintech]

This is my first contact with Bitbucket and I hope this is the right spot:

I have downloaded ART 1.15 for Windows and it runs fine, except ART-cli.exe that is crashing immediately when started (in cmd console).

After searching here I found this issue and tried to setup the dark frame folder in the options DLG of the ART.exe gui. That works and my CR3 files were converted to JPGs.

But the ART-cli.exe crashes again after the converted file is written.

Same when just calling it in the command box:

C:\Program Files (x86)\ART\1.15>ART-cli.exe
ART, version 1.15, command line.
Terminating without anything to do.

→ then there is the windows crash dialog.

Any ideas what to do?

[smartintech]

I can be more specific now:

When setting Verbose=3 in the [General] tab of my options file and calling

ART-cli.exe -V -V

I get a ton of verbose info.

The last lines are:

Add camera constants for "ZEISS ZX1"
ART, version 1.15, command line.

and then it crashes.

Windows points to mimalloc.dll with exception c0000005 which is access violation.

I hope that helps to find, whats going on.

Let me know if this is something new/different then this issue title here and I will post it again at the right location.

[agriggio]

hi,

From your description it looks like a different bug. Can you please open a separate issue? I only have a phone with me right now, but I'll take a look when I have the chance. Thanks in advance!