Maybe I miss something but I don’t see why PhF’s approach is expected to be slower when more and more gestures are added. If you maintain a cache of the output of the clone/stamp layer and update it after each time that the user added a gesture, then adding a new gesture requires only a single update to the cache. Consequently, adding the 2nd gesture or the 20th gesture shouldn’t make a difference at all - in each case there is a single update to the cache of the previous sequence of gestures. So the only time when the number of gestures should make things slower is when all gestures need to be replayed, like when the PFI file is opened, because then the whole chain of gestures needs to be applied from the first to the last.
The fact is that there is no cache of the clone/stamp output. The pixels are re-computed each time something changes (a strokes is modified/added or one of the underlying layers is modified), so the complexity of the computations depends on how many strokes have to be rendered.
The issue with caching is that as soon as you have a relatively large number of layers, it requires quite some memory. At that point, you need to swap to disk, and deal with all the thread synchronisation issues when accessing the cache in read/write mode.
PhF approach (but this is really the approach of the underlying VIPS processing engine) is to limit as much as possible the amount of caching, and instead let the CPU re-process the pixels when needed. So the goal will be to make all tools as fast as it is reasonably possible, and to re-computation in most of the places.
Still, some “slow” tools like the RAW processor keep a cache of their output, which gets computed in the background. This cache is either kept in memory or on disk, depending on the size (I have a 500MB threshold for this, although is memory cannot be allocated the system falls back to disk caching anyhow).
However, the cache is only accessed when its processing is completed, so that there are no read/write synchronisation subtleties to take care of…
I have a bug with Uniform Fill layers. It seems that I can save a preset and when loading it again, the colour of the layer is correct, but the GUI hasn’t been updated:
so If I want to adjust the colour, I have to start from the beginning again.
@paynekj Hi Kevin, thanks for catching this! It should not be too hard to fix, will look into that as soon as I manage…
@paynekj Hi Kevin, could you test this new version and check if the problem with the uniform fill tool is solved for you as well?
Thanks!!!
I’ll try it this evening from home, Firefox is complaining about filebin.net’s security certificate and there’s corporate security getting in the way as well.
I’ve tried the version 20170227 on windows 10.
It crashes sometimes.
I’ve attached the gdb messages. But maybe you need only them starting backtrace command ?
Fail20170315-2.txt (231.2 KB)
Thanks for testing! I made a new package, with some additional checks and console outputs. This should allow to more easily identify the buggy piece of code.
If this new version crashes again, could you please send me the corresponding console messages (not the gdb backtrace), to see where exactly the code has failed?
THANKS!!
Unfortunately, the new log file does not provide more informations… here is what I propose:
-
run the 20170315 version without gdb, and redirect the output to a log file:
photoflow.exe > log.txt, and then send me the log.txt file after the crash -
get the latest version I prepared this morning, which is compiled with debugging symbols (that’s why the package is twice as big), run it through gdb.exe and send me the backtrace, which this time should show the exact line number at which the crash occurs…
THANKS!!!
I’m trying to install PF under the last Debian.
PPA doesn’t work (apt-get update fails).
And I’m stuck with the build script at VIPS step (I’ve got the version 7.x but 8.x is required).
Any suggestions ? Thanks !
I have no idea what is happening with the PPA… I will reach the maintainer to see if we can help.
Have you tried with the PhotoFlow/build/build_all.sh script? It should also automatically download and compile the git version of libvips, and compile photoflow against it.
The script was exactly meant for compiling photoflow on systems that do not provide a recent enough version of VIPS…
run it through gdb.exe and send me the backtrace
Fail20170316.txt (123.9 KB)
But … that doesn’t fail at the same time. The previous scenario the failure occurs during the calculation on the third image. This time it fails just when I open the second one.
The problem is definitely memory allocation… it seems that the program is not able to allocate enough memory for the second or third image:
Saving raw data to buffer...
Raw buffer allocated: 0
There is a pointer to a temporary memory buffer that is NULL, i.e. the memory cannot be allocated.
I think this is due to the fact that my windows executable is 32 bits, but I cannot exclude a memory leak somewhere, as I don’t expect the memory allocation to be so large as to hit the limit of 32 bit executables.
Until this is not solved, you will be limited to only one opened image…
Thanks!
Yah … that makes progress 
But I still have a lot to learn, sorry if my issues are stupid things… Thanks for your help !
I still have some missing packages :
– package ‘fftw3>=3.0’ not found
CMake Error at /usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:341 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
CMakeLists.txt:36 (pkg_check_modules)
– checking for module ‘libxml-2.0’
– package ‘libxml-2.0’ not found
CMake Error at /usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:341 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
CMakeLists.txt:38 (pkg_check_modules)
– checking for module ‘libexif’
– found libexif, version 0.6.21
– Could NOT find Exiv2 (missing: EXIV2_LIBRARY EXIV2_INCLUDE_DIR) (Required is at least version “0.12”)
– checking for module ‘gexiv2’
– package ‘gexiv2’ not found
CMake Error at /usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:341 (message):
A required package was not found
Call Stack (most recent call first):
/usr/share/cmake-3.0/Modules/FindPkgConfig.cmake:395 (_pkg_check_modules_internal)
CMakeLists.txt:44 (pkg_check_modules)
and the build ends failing:
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
EXIV2_LIBRARY (ADVANCED)
linked by target “pfbatch” in directory /home/weyland/PhotoFlow/src
linked by target “photoflow” in directory /home/weyland/PhotoFlow/src
– Configuring incomplete, errors occurred!
While it seems the package are there:
$ dpkg -l |grep ‘fftw3|libxml2|libexif|exiv2’
ii exiv2 0.24-4.1 amd64 EXIF/IPTC metadata manipulation tool
ii libexif-dev 0.6.21-2 amd64 library to parse EXIF files (development files)
ii libexif12:amd64 0.6.21-2 amd64 library to parse EXIF files
ii libexiv2-13:amd64 0.24-4.1 amd64 EXIF/IPTC metadata manipulation library
ii libfftw3-3:amd64 3.3.4-2 amd64 Library for computing Fast Fourier Transforms
ii libfftw3-double3:amd64 3.3.4-2 amd64 Library for computing Fast Fourier Transforms - Double precision
ii libfftw3-long3:amd64 3.3.4-2 amd64 Library for computing Fast Fourier Transforms - Long precision
ii libfftw3-single3:amd64 3.3.4-2 amd64 Library for computing Fast Fourier Transforms - Single precision
ii libxml-libxml-perl 2.0116+dfsg-1+deb8u1 amd64 Perl interface to the libxml2 library
ii libxml2:amd64 2.9.1+dfsg1-5+deb8u4 amd64 GNOME XML library
ii libxml2-utils 2.9.1+dfsg1-5+deb8u4 amd64 XML utilities
ii python-libxml2 2.9.1+dfsg1-5+deb8u4 amd64 Python bindings for the GNOME XML library
ii python-lxml 3.4.0-1 amd64 pythonic binding for the libxml2 and libxslt libraries
Don’t worry, we have all been learning at the beginning… and the issue here seems to be actually quite simple: you need to install the *-devpackages, like you already did for libexif-dev.
The normal packages contain the runtime libraries, but they do not provide the header files needed to compile other programs against such libraries…
Hope this helps!
Thank you for encouraging, I continue then :-)… and sometimes also lib*-dev …
Going further:
In file included from /home/weyland/PhotoFlow/src/external/rawspeed/RawSpeed/AriDecoder.cpp:1:0:
/home/weyland/PhotoFlow/src/external/rawspeed/RawSpeed/StdAfx.h:109:23: fatal error: pugixml.hpp: Aucun fichier ou dossier de ce type
#include “pugixml.hpp”
^
compilation terminated.
The only not found notice is about 'gimp-2.0>=2.9.0'. I’ve not found any other error. What should I look for ?
Just install the libpugixml-dev package… I have not yet found a reliable way of testing for it’s presence in the cmake configuration, that’s why cmake did not complain.