Makes sense. Still takes too many words to explain, meaning that it isn’t intuitive. What would make it better is train the user to take labeling seriously (I can think of several strategies but will let you think about it first) and make labeling clear and unique by default. E.g., input source as “previous” is not specific enough; I would prefer it to be the actual source’s label.
1 Like
I think making the mask input default to the L channel of the previous layer is a good idea - its what I would usually do anyway unless I was using a path or gradient mask.
As far as labelling the source goes, I think that the label should include ‘previous’ or similar to make it clear that the source layer will change if you reorder the layers (or add a new one), whereas if you specify a specific source layer it won’t.
I was considering to use the word “default” instead of “previous”, because it might not always correspond to the previous layer… I will also try to add the actual name of the default layer, if possible, something like
default ("layer name")
default works. Showing the name of the actual source layer is good too.
.pfi files:
Currently the source image for the Raw Loader is saved as an absolute path. I think it would be helpful if this was a relative path instead (relative to the .pfi file) - that way you could move the raw and pfi files together (e.g. with Play Raws) without the path becoming invalid.
1 Like
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
1 Like
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.
1 Like
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…