batch mode - windows 10 - PhotoFlow 0.2.8

[phweyland]

Starting the following command in the folder where the nef and pfp files are, PhotoFLow seems to exit without doing anything.

"C:\Program Files (x86)\PhotoFlow\photoflow-0.2.8\bin\photoflow.exe" --batch 20170715_Chartres_012.NEF default.pfp PFf\%name%.jpg

The following command opens the nef file.

"C:\Program Files (x86)\PhotoFlow\photoflow-0.2.8\bin\photoflow.exe" 20170715_Chartres_012.NEF

[phweyland]

My mistake ! exit without doing anything ... Yes, the command exits immediatly but Photoflow executes in background and the jpg is correctly created some time later. Will that work in batch loop on all images of the source folder ? Edit: Yes, in batch loop it works nicely too. Sorry for inconvenience !

[aferrero2707]

Looks like the processing thread gets detached from the main process... very strange, I will try to reproduce the problem and get back here as soon as I have some progress.

[aferrero2707]

I cannot reproduce such a behavior with wine under Linux... not having a Win10 system at hand, I'm a bit lost.

Could you post the full terminal output of the above btach command?

Thanks!

[phweyland]

Here is the output:

D:\Documents\Images\Photos\2010\2017\20170701_Chartres>"C:\Program Files (x86)\PhotoFlow\photoflow-0.2.8\bin\photoflow.exe" --batch 20170715_Chartres_002.NEF default.pfp PFf\%name%.jpg D:\Documents\Images\Photos\2010\2017\20170701_Chartres>

But the image is actually created:

Would that work with GBD ?J

[aferrero2707]

If I understand correctly, the program goes immediately in the background without producing any terminal output, right?

There might be some windows-specific thing I am missing...

[aferrero2707]

Wait a moment... I think I probably found the reason for this strange behaviour. I am compiling the windows version with -mwindows, which is fine for a GUI application but not for a CLI command (see here for a quick explanation).

Later today I will prepare a new package without -mwindows, so that you can check if the problem goes away.

The drawback is that a terminal will pop-up each time the GUI version (without --batch) is started, but this is a Windows limitation I cannot overcome...

[aferrero2707]

@phweyland Could you please try this new package and see if it fixes the problem with batch processing?

Thanks!

[phweyland]

I've tried this new package but the behaviour is the same (immediately in the background).

[aferrero2707]

My apologizes! I messed up with the commits, and as a result the new version was still compiled with the -mwindows switch!

Today I made yet another package that should finally be OK (at least the -mwindows option did not show up in the g++ invocation). Could you grab it from here?

Thanks!

[phweyland]

This time it is very verbose ! :-) I send you the output because, as the for the first run the image did exist any more, Photoflow crashed. I relaunched with an existing one, then it succeeded. Both runs are in the log file.

Photoflow 20180831.txt

[aferrero2707]

Thanks for checking! Do I understand correctly that, apart for the problem occurring when the input image does not exist, the batch processing works fine now?

[phweyland]

Yes, the batch run did run on the foreground.

[aferrero2707]

So I'm closing this issue and opening a new one concerning the improvement of the behaviour when the input file is missing.

Thanks!