That sounds great !! 
Thank you Carmelo
Just tried the today ppa photoflow-git:
20170716 Photoflow stable.txt (44.4 KB)
My last working install has been done on 30/05/2017.
Before installing a new version, I save the entire VM. Is there an quicker way to revert back to the previous PF install ?
Not to my knowledge… maybe @Dariusz_Duma knows a way to revert to an older package version from his PPA?
@phweyland the crash you are reporting looks very much like the same issue I have under windows… and seems to have been introduced by the last update of the RawSpeed library from Darktable.
Could you maybe give the AppImage package a try? You can get the latest one from here (grab the package with the most recent date, 20170702 at the time of writing). I do not have a good internet connection at the moment, so I cannot do any debugging before a couple of weeks…
@Dariusz_Duma would it be possible for you to provide a debugging version of the photoflow-git package in your PPA? The cmake build configuration provides a standard RelWithDebInfo target for this purpose. That would greatly help to debug this kind of issues.
@phweyland if the debug package becomes available, then a GDB backtrace would be really helpful.
With the today appimage : 20170716 Photoflow.Appimage.txt (60.8 KB)
About GDB, is that the same syntax as under windows ?
Looks like the same problem as the PPA version… which Linux version and CPU do you have?
The gbd syntax should be the same under windows and Linux.
Ubuntu 16.10 (as VM / Windows 10 host) & i5 760
I have prepared a new appimage package, compiled with -march=nocona and -mtune=generic
Could you eventually check if this solves the illegal instruction issue?
Thanks!
@phweyland short update: I think I have found the place where the RawSpeed library sets the target architecture, and how to tell it to compile for a generic one. It seems one needs to set
BINARY_PACKAGE_BUILD=ON
in the cmake configuration (@houz might be able to confirm this) .
Consequently, you should grab the latest AppImage package from today (20170718) if you have the possibility to run some tests, as all the previous ones were most likely compiled with -march=native for the RawSpeed part (and this would explain the illegal instruction crashes you got).
Thanks!
This one fails:20170718-1 Photoflow.Appimage.txt (61.0 KB)
But this one works fine with 3 images opened.
Well done !
Edit: when do you think ppa will be updated with this ?
Yes, without BINARY_PACKAGE_BUILD you will get this:
1 Like
You might get an updated package in 1 or 2 days, meanwhile the appimage is probably a decent replacement.
Thanks for checking so quickly!
Sure ! what I miss here is the “open with” from Digikam. Would you know which the linux settings to tie “open with” and photoflow.appimage ?
You need a proper .desktop file… the appimage should create it automaticall, but it doesn’t work for photoflo. I will investigate next week…
Does work ! Thanks !
Trying to use the appimage in batch mode … Should it work ?
Batch file (the first one works, not the second one):
#!/bin/bash
default=$HOME/.photoflow/presets/default.pfp
photoflow=/usr/bin/photoflow
# photoflow=$HOME/Downloads/PhotoFlow.AppImage
for i in $1/*.NEF
do $photoflow --batch $i $default $1/PFf/%name%.jpg
done
It stops there:
/tmp/.mount_PdbCCx/usr/bin/photoflow.real --batch ./test.NEF /home/weyland/.photoflow/presets/default.pfp ./PFf/%name%.jpg
exePath: /tmp/.mount_PdbCCx/usr/bin
dataPath: /tmp/.mount_PdbCCx/usr/bin/../share/photoflow/
localePath: /tmp/.mount_PdbCCx/usr/bin/../share/locale
memory: high-water mark 0 bytes
It should work… could you open an issue on github, so that I do not forget about this? I will try to look into this problem sometimes next week.
I’ve just copied a default.pfp file into a presets folder (just beside the config folder) in AppData/Local/photoflow, but it seems it is not seen by PF. Maybe it is not the right place ?