That is actually already implemented. If the input file is not found in the provided absolute path, it is searched in the same folder as the .pfi file.
If that does not work for you, then it’s a bug…
The only issue I have at the moment is when files are exchanged between *nix and Windows systems, in which case the absolute paths are not interpreted correctly… I am working on a proper fix.
Sorry its taken so long to reply…
I’ve done some testing on macOS:
.pfi files will find the RAW file if it is in the same directory.
.pfi files with a Windows style path won’t open on macOS unless I manually change the path to a POSIX style one
This may be an idea too far:
The processing model for VIPS is a graph, not a linear pipeline. You can build a graph structure in photoflow with the use of clone layers to join branches together, but it gets confusing fast.
How about a node / graph based user interface instead of a stack of layers?
Also, it would be nice to have more than one input to a node (for example, a Guided Filter where you could specify the image and the guide from diffferent sources).
What I really want is an open source version of Quartz Composer…
That’s something I have in the back of my mind since long time. You are right, photoflow is really a node-based editor, and layers are just a simplified representation of the pipeline that works best when the processing is “almost linear”.
However, I have no time to code a node graph view from scratch. I have been looking for some existing UI widgets that allow to represent and display node graphs, but I have not found anything so far. If you have some ideas, I would be very much interested!
Adding a node graph view would make photoflow much more unique in the image editors family, so it make a lot of sense to put some effort into it…
This is actually supported by the underlying pipeline, but not exposed in the UI. The guided filer is a good example of a filter where this would be helpful. I think I will include some work in this direction in the simplified-pipeline branch, where I am anyhow re-arranging the way node inputs are selected, and how they are handled in the UI.
Isn’t this what Natron does? I haven’t looked at their code, but the GUI organization might be a basis for a node-based PhotoFlow…
Natron uses QT and Python, and photoflow uses GTK.
I would appreciate a graph based view as well. It would make so much more sense to me as I am far from a linear thinker.
I’m probably going to re-write rawproc from wxWidgets to Qt in the coming year, probably with the same gImage image class. The processing architecture and the GUI don’t have to be too closely coupled…
Certainly they don’t have to be closely coupled, I totally agree! But the representation of the nodes in Natron is in QT, which means it is not directly usable in GTK.
Hello @ggbutcher
I’m probably going to re-write rawproc from wxWidgets to Qt in the coming year
Wow. I am really interested in your decision about moving your software to Qt!
Why not opt for the GTK toolkit, for instance (such as Gimp, Darktable, RawTherapee, Photoflow etc)?
As for me I only know a bit of Python (no C++, Java etc).
For my very little needs, as a “programmer”, I have always preferred the QT toolkit instead of the out of the box TK (toolkit Tkinter) libraries available with Python (there is no match IMHO, since QT wins hands down).
Most of the softwares I work with leverage the QT libraries (Krita, Shotcut, QGIS, Freecad-Qcad etc) and I have always read very good reviews about it. Especially, if you are going to aim in the future the Android system (thanks to the additional QML toolkit).
Thanks a lot in advance for any insight about your decision 
Hello everyone
As regards Qt, there is also Olive video editor, if you are interested [1]. It is actively developed on github and open source.
Right now, there is also an upcoming feature [2] consisting in Node-based structure/effects, which, I surmise, it is inspired by Natron or Blender. IMHO, this might be a game changer compared to other open source editors such as Shotcut - Kdenlive (Qt as well).
Maybe I am totally wrong, but from my personal perception, it does look like most of the new graphical softwares are developed through the Qt toolkit. G’MIC was eves recoded from scratch from GTK to the present Qt version.
In the past I have even read that even Andrea Ferrero, for PhotoFlow, was considering moving to Qt 
[1] https://www.olivevideoeditor.org/
[2] https://www.patreon.com/posts/olive-roadmap-26853206
Remember that there’s a distinction between Qt Widgets and Qt Quick.
Filmulator uses Qt Quick.
Silvio,
At this point, it’s all just musings of a warped mind…
Truth be told, I’d prefer to just stick with wxWidgets. It really does make the Windows/Linux UI transparent to my endeavors. If it only did high-bitdepth displays… (and there might be a way, I just haven’t dug into it yet.)
Qt stuck out for its apparent multi-platform support. I’ve tried to do “stupid pet tricks” with wxWidgets to support touchscreens, but it just doesn’t work nice.
Another key consideration is my customer base. Me. That’s it, to my knowledge; if others are actually using rawproc, I don’t specifically know it. The 8-bit monitor I’m staring at now will probably be the one I take to the nursing home, and I much prefer a mouse to work with image manipulation softwares, so my current environment well-suits the “customer base”… 
The node-based softwares are interesting, but I haven’t dug into their specifics to pass judgement on their efficacy for single-image processing. It does seem a waste of screen real estate to depict a processing graph, when my inclination is to a layer paradigm. rawproc is a more rudimentary implementation of a layer paradigm than PhotoFlow; I had the command-line string of operators presented by G’MIC in mind when I cobbled together the first iterations. Indeed, unless I find out something compelling about nodes and graphs, rawproc-next will have a tree-based layer organization for image operations, just as it has now.
Thanks for asking; really, these musings were just wafting through my noggin, and you’ve given me the opportunity to make complete sentences out of them for consideration…
Hello @ggbutcher
Thanks a lot for your reply!
I’ve tried to do “stupid pet tricks” with wxWidgets to support touchscreens, but it just doesn’t work nice.
Well, I am not a programmer but I am confident you will be pleased to try the Qt Quick Toolkit (the same of Filmulator) which is strongly oriented towards touch screen devices.
The 8-bit monitor I’m staring at now will probably be the one I take to the nursing home
This joke made me laugh
Since you are planning your change well ahead you might also consider to aim to the Qt 6 release:
It goes without saying, but there is no need to change if you are fine with the wxWidgets. However, trying new things keeps your brain alive and kicking…
Indeed, indeed! In that regard, this past weekend my neighbor introduced me to a volunteer opportunity at a ‘model railroad museum’, where they operate trains prototypically using a realistically-behaving signalling system. I thought I knew how those things worked, but dealing with it in ‘real-time’ taxed bear-of-little-brain here… but my wife still does not see how such brain exercise will help me remember our anniversary…
I suppose it is a good way to review your work rather than setup and configure your modules if that makes any sense.
Visual-wise, it would save space and be rad if we got an overlay of the node map, just in time for the AR/VR revolution.
Indeed, I plan to do that at some point, for three main reasons:
Hello @Carmelo_DrRaw
I hate GTK3, so I will probably invest time in the Qt migration as soon as I will need to abandon GTK2.
Your opinion does not surprise me even though I am not a programmer by trade and I am completely unable to judge the question properly…
“I’m beginning to think GTK exists only to make Qt shine” was a similar opinion expressed by Aurélien Pierre in another topic of this forum (“New Interface in darktable 2.7 - dev” on May 22 - 2019).
For my fumbling attempts with Python I have chosen the Qt toolkit for the GUIs because It is superbly documented (books, tutorials etc).
On Linux I have always preferred the KDE desktop (Kubuntu and the like) and therefore I am totally biased as regards my personal preferences…
Maybe the upcoming GTK 4 version will improve things for the better
I have the hope that Qt does not suffer from the color management limitations of Cairo under MacOS.
As regards this topic I am pretty sure you can gather some information from the Krita folks [1].
From what I have read in their forums they are “less than pleased” about the Apple attitude of “forcing” the open source developers to adopt their own proprietary toolkits (Metal etc). But really I do NOT want to start an additional flame about this
[1] Krita 4.2.0: the First Painting Application to bring HDR Support to Windows | Krita