I give lots of feedback because I want PhotoFlow and other apps to succeed. I would do more if I had more time. Doesn’t mean that I am hardcore; being a minimalist, I only use 1-5% of what most apps here have to offer.
Due to the recent changes in the way interactive tools work, you first need to make sure that the RawDeveloper module is in editing mode, by checking the small pencil-like icon near the layer name:
If it is greyed out you need to enable the editing mode by either clicking on the icon or pressing CTRL+e.
Please let me know if this solves the problem…
Hi @Carmelo_DrRaw - I want to try the new CDL code, so I updated PhotoFlow with no problem. But I’m having trouble installing the plug-in. This isn’t the same trouble as I mentioned above wrt to PhotoFlow plug-in and GIMP-2.99 from git.
FWIW, GIMP-2.10 from git installed in a prefix starts and runs, and PhotoFlow intalled in /usr/local also starts and runs, - both work just fine when started independently of each other.
Anyway, after updating the PhotoFlow plug-in and trying to build, the “make” process stops with this error:
[ 25%] Building CXX object CMakeFiles/phf_gimp.dir/phf_gimp.cc.o
In file included from /home/elle/code-install/gimp210/install/include/gimp-2.0/libgimp/gimpui.h:24:0,
from /hdd/data1/code-build/gimp210/build/PhFGimp/phf_gimp.cc:6:
/home/elle/code-install/gimp210/install/include/gimp-2.0/libgimpwidgets/gimpwidgets.h:78:10: fatal error: libgimpwidgets/gimpspinbutton.h: No such file or directory
#include <libgimpwidgets/gimpspinbutton.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/phf_gimp.dir/build.make:63: CMakeFiles/phf_gimp.dir/phf_gimp.cc.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:68: CMakeFiles/phf_gimp.dir/all] Error 2
make: *** [Makefile:130: all] Error 2
Here’s the lines I used to update and install the plug-in:
cd /hdd/data1/code-build/gimp210/build/PhFGimp
rm -r build
mkdir build
cd build
git status
git pull
export PKG_CONFIG_PATH="$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig"
export LD_LIBRARY_PATH="/usr/local/lib:${LD_LIBRARY_PATH}"
export GI_TYPELIB_PATH="/usr/local/lib/girepository-1.0"
PREFIX=$HOME/code-install/gimp210/install
cmake -DCMAKE_BUILD_TYPE=Debug -DCMAKE_INSTALL_PREFIX=/home/elle/code-install/gimp210/install ../
make VERBOSE=1
make install
GIMP-2.10 is installed in $HOME/code-install/gimp210/install.
The file “/home/elle/code-install/gimp210/install/include/gimp-2.0/libgimpwidgets/gimpwidgets.h” does list “#include <libgimpwidgets/gimpspinbutton.h>”, but this file is not in the “/home/elle/code-install/gimp210/install/include/gimp-2.0/libgimpwidgets” folder. Even so, GIMP runs without any problems.
Copying the “libgimpwidgets/gimpspinbutton.h” from the build folder to the “include//gimp-2.0/libgimpwidgets” does allow the PhotoFlow plug-in to build and install and GIMP sees the plug-in.
Should I/where should I file a bug report?
Hi @Elle,
I get the same error in my Travis CI builds, this looks like a recent GIMP bug (the official 2.10.8 code is OK in my case). I will report this upstream.
Anyway, let me just mention that you are not really obliged to re-compile the plug-in whenever wither GIMP or PhotoFlow are updated. The plug-in is completely independent from the photoflow code (it just calls the photoflow executable to perform the image processing, but it is not linked agains the photoflow libraries). Moreover, the GIMP libraries in the 2.10 branch should be binary-compatible from one version to the next. Hence, it is very likely that a plug-in compiled against GIMP 2.10.6 will still work perfectly OK with GIMP 2.10.8, without any need of recompiling it.
All-in-all, I think you only need to recompile the PhF plug-in when the code of the plug-in itself is changed, or when going from GIMP 2.10 to GIMP 3.x
Hi @Carmelo_DrRaw - thanks! for reporting the bug.
Normally I don’t recompile the PhotoFlow plug-in, but I had just updated Gentoo. So to prevent the “doesn’t run anymore because compiled against different library” issue, I also updated and recompiled all the “from source” software installed on my system. Though I’m guessing the PhotoFlow plug-in doesn’t have a lot of dependencies apart from GIMP.
1 Like
If I start GIMP-2.10 using my usual script which sets some variables, GIMP finds the darktable, RawTherapee, and PhotoFlow plug-ins.
If I start GIMP-2.10 by dragging an image file to my newly-created GIMP desktop file, GIMP finds the darktable and RawTherapee plug-ins, but not the PhotoFlow plug-in.The same is true if I start GIMP-2.10 by navigating to the prefix “bin” folder and clicking on the executable - GIMP finds the darktable and RawTherapee plug-ins, but not the PhotoFlow plug-in.
Is there a way allow GIMP to find the PhotoFlow plug-in while dragging/dropping to the GIMP desktop file (and/or by clicking directly on the GIMP executable?
I suspect that your RT and DT are installed in “official” places and can started without setting additional environment variables, while PhotoFlow is installed in a custom prefix, right?
Which variables do you set when launching GIMP with your script from the command line? I guess you should set the same variables when launching GIMP with the desktop file, otherwise the environment is not the same.
Actually RT, DT, and PF are all compiled from source and installed in /usr/local. But the PF plug-in software and GIMP are both installed in a custom prefix.
The usual “comple in a prefix” lines. But those lines aren’t actually needed to run GIMP installed in a prefix. It’s sufficient to just do “/path/to/gimp-prefix/bin/gimp-2.10” for RT and DT, and also valgrind and gdb don’t need the script.
Checking, it seems the only script line that PhotoFlow needs is this:
export LD_LIBRARY_PATH=$HOME/code-install/gimp210/install/lib:$LD_LIBRARY_PATH
Is there any way to add the above export command to the desktop file? I tried but it didn’t work.
I suppose I could add the above export command to one of my startup scripts, to run when starting “X”, but I’m not sure what that would do for running different versions of GIMP installed in different prefixes.
Is there a way you, or else the person compiling the plug-in, can add the LD_LIBRARY_PATH information to the plug-in code or compile switches so it gets compiled right inside the plug-in? I compile and install the PhotoFlow plug-in separately right inside each GIMP prefix, and I think this is necessary, yes?
This explains the sometimes mysteriously missing ability to use PhotoFlow from within GIMP - once I realized the script wasn’t necessary to start GIMP I’ve only used the script somewhat randomly 
This is indeed what I was expecting. Concerning a possible solution, I need to think about it.
Could you post the terminal messages you get when you run GIMP on the command without a script? I guess the PhF plugin will complain about missing libraries, and then I will have maybe a better clue of how to fix that…
Thanks!
Starting with the script:
$ code-install/gimp210/rungimp210
phf_gimp::query() called, exec_path=photoflow
stdout:
this is photoflow 0.2.8
Starting without the script:
$ code-install/gimp210/install/bin/gimp-2.10
/home/elle/code-install/gimp210/install/lib/gimp/2.0/plug-ins/phf_gimp: error while loading shared libraries: libgimp-2.0.so.0: cannot open shared object file: No such file or directory
code-install/gimp210/install/bin/gimp-2.10: LibGimpBase-WARNING: gimp-2.10: gimp_wire_read(): error
/home/elle/code-install/gimp210/install/lib/gimp/2.0/plug-ins/file-photoflow: error while loading shared libraries: libgimp-2.0.so.0: cannot open shared object file: No such file or directory
code-install/gimp210/install/bin/gimp-2.10: LibGimpBase-WARNING: gimp-2.10: gimp_wire_read(): error
Thanks! for checking into this. FWIW, the “gimp_wire_read” errors don’t keep GIMP itself from running properly.
I didn’t check but
When I open photoflow-w64-20181118_2031, nothing bad happens, but I noticed a lot of these messages.
@afre @phweyland
I had to update my Windows build environment last week, and got stuck with a stupid library inconsistency problem until yesterday… now I am back into business and I hope to provide a new Windows version for testing by tomorrow.
@afre do you have special characters in your file/folder names when you see those messages?
2 Likes
Nope. Just -s and_s at most. Windows hates special characters!
Yeah, Area WB is definitely wonky. When I open a raw file and go straight to the selection, the pencil is already enabled and it works as expected. Any other time, including revisiting the file via a PFI, the box is either invisible or not interactable, or one corner node is visible at the top-left corner of the preview image.
I have found a bug in the way the corners of the Area WB rectangles were saved in the .pfi files, which explains why upon re-opening a file the rectangles were not visible or behaving in a strange way.
I still have to do more extensive tests of the rest, but maybe you can already provide me feedback wether this specific problem is fixed or not for you?
Meanwhile, I have added two more tools to the PhF arsenal:
- a random noise generator, that can create a perceptually flat random distribution of pixels even when working on linear RGB data. It is found in the “Color” group
- an implementation of the “guided filter” derived from RawTherapee. which allows to efficiently do edge-preserving preudo-gaussian blurs. It is found in the “Details” section.
2 Likes
It isn’t fixed yet. There are many cases where it doesn’t work as expected. E.g., if I use samplers, it doesn’t work.
Could you describe the problem better? I have tried to reproduce issues with AreaWB + samplers, but in my case everything seemed to behave as expected…
Thanks!
I have just committed an improved version of the local contrast tool.
This new version uses the guided filter as the blur operator to extract and enhance the high-frequency details.
The new version has three controls:
- amount: adjusts the strength of the local contrast enhancement/suppression. A value of “0” gives the blurred image, “100” gives the original image, values <100 give an image softer than the original, and finally values >100 enhance the local contrast
- radius: the radius of the underlying guided blur
- threshold: the threshold of the guided blur to distinguish between strong edges and fine texture. The lower the value, the finer are the textures that are preserved
The suggested workflow is the following:
- set amount to “0”, and adjust the radius and threshold until you see smooth textures but at the same time the strong edges (for which you do not want visible halos) are not blurred
- set the amount to “150”
- adjust to your taste around this value
Used with moderation, I find that this tool can give a significant “pop” to some pictures without creating “fake” results. I have for example used it to enhance the fur of the jumping spider in my most recent picture.
Suggestions are welcome as usual!
1 Like