On nodes: we used to call the general structure Directed Graphs, not necessarily Acyclic. And each node can be a DG, of course.
I see no reason why nodes couldn’t use GPU, with images retained in GPU across the arcs between nodes. But I know almost nothing about GPU coding.
What I don’t like so much with node-based designed pipelines, is the fact that the usual constructs for flow control, that every programmer knows (tests, loops, conditional loops, breaks, …) become a pain to use with nodes.
For instance, doing a simple loop with a break inside will be translated into a very complicated graph of nodes.
To be honest, I must admit I’ve never seen the interest of node-based pipelines, compared to the use of a basic script language, where flow control is often straightforward.
In the late 90’s, we were taught image processing with a node-based graphical system.
It became hell, as soon as you wanted to do more than connect simple processing nodes together.
I’ve seen plenty videos of people using Blender, who design quite complicated effects using nodes. They really get huge graphs. I admire them for their patience 
But I don’t understand how they can manage/maintain that in the long term
(not even sure if we can add comments associated to each node).
that’s the structure in vkdt too. i allow cycles to process animations/temporal feedback loops.
yes.
indeed. i think nodes are fun for illiterate users who just want to quickly bash something together. they’ll leave the actual programming (inside the node) for someone who knows what they’re doing. that being said for a workflow-based application i’d probably want to hide as much of the graph processing as i can from users too, and just work with very coarse presets/fixed blocks/a set of expert-curated graphs to pick from.
the node processing maps 1:1 to gpu processing. every vkdt node has exactly one compute/draw shader and can have multiple textures bound as input and multiple storage images as output. the gpu texture unit does all the work managing pixel formats. to implement even slightly interesting control flow, as you pointed out above, i need quite a bunch of nodes sometimes. i hide these behind “modules” which are the thing that is exposed to a user currently. that would be something like “local contrast” that actually consists of some 20 nodes internally. on top of that there are “presets” and “blocks” which consist of multiple modules with interconnections which can be inserted into an existing graph as a whole.
the thing with gpu programming is that control flow/branches/complex logic doesn’t really work well there in the first place (because of the heavy SIMT processing and branch divergence as well as incoherent memory accesses). so usually i’d put my problem upside down to match a more simplistic processing logic before i even start putting it into code/nodes.
afaik most directed graph concepts let you put comments somewhere within/around the structure. Sure, code is more practical and efficient from a programming side.
I think there is a distinction between ‘regular usage of code’ for processing images and ‘developing efficient code’ for processing images.
A directed graph is leaning more into the ‘regular usage’ side with limited capabilities of ‘developing code’.
Since a node could/can (maybe must as a requirement) also contain code, I see no massive downsides to directed graphs and they would adress some/most of the stated issues that @mbs detailed.
A directed graph can be expressed in a structured text language, and a text language can be expressed as a DG (as a graphical image).
I last used DGs seriously about 30 years ago. They were invaluable for communicating complex technical relationships within engineering teams, and how those relationships changed as the project developed. They helped us understand how relationships could or should be rearranged for performance, system integrity and so on.
When flattened into stupidly large and complex graphics, we used them to impress, baffle and confuse senior management, ie project sponsors.
For reference, DaVinci Resolve already does this.
And it was my impression that vkdt was node graph based? (Edit: @hanatos confirmed that)
Last year I made a perspective matching system with Blender and Sverchok:
Keep in mind that both Blender and Sverchok are not my everyday thing.
But…, it does function. 
I could make this work without knowlege of complicated matrix calculations. I used a lot of nodes for translations and rotations ( especially the use of quaternions).
I would love to do something like this with G’MIC, but G’MIC is unfortunately too complicated for me to program in.
The most fun was to learn about this perspective matching and the use of the trirectangular tetrahedron therein.
That is what Olive video editor does (free/libre).
This is what audio video pipelines, like direct show, have been doing for years, and it works well! In this ecosystem, plugins are typically called codecs.
You have to be carefull on interfaces “contracts”, maybe define categories for example to ensure a kind of consistency. A well-thought framework is mandatory.
Gnu Radio is another very good example.
Wow, thanks for pointing that out! Finally, a FOSS video editor that isn’t using an int8 internal pipeline.
Well in the example given of vkdt module, it seems that it is almost a plugin.
The glsl code can be compiled by the program itself and passed to th gpu.
The interface seems to be described by simple text file, so vkdt would be able to read it an create the interface for the module, may be with some limits in funcionality, but enough for making tests.
As you say it would be great to be able to test some contribution like sigmoid without waiting for developers to add it to main stream (in case the do).
As long as you are using not supported plugin, any problem it could cause would not be attributed to main stream modules.
A way to envelope that plugins in a security shell and catch exceptions to tell the user the problem comes from that plugin would be needed.
Why not distribute the plugins along with the rest of the source code to help ensure compatibility?
Because it needs the approval of the devs and it will be then an official module and would have to be maintained by the team.
The problem with sigmoid, for example is that you cannot test it or use it if you like it, you have to download the fork, compile it (or get a precompiled version made by someone).
As you cannot be sure the version would be the same and ther would be compatibility problems with database, you have to use it with a subset of your photos and a separate database.
If there is a plugin mechanism, the developer of the plugin is responsible of distributing it and maintain it.
So you’ll need a group to test, curate, and maintain the list of plugins?
I don’t understand, the independent plugin would be curated and maintained by its programmer and tested by the users interested in it.
It would be much easier for users to install a new plugin than having to recompile a fork and deal with the fork and the main stream program.
There are many software that works with plugins in many fields (Photoshop being one in our field) and they are great for users.
I don’t know if developing a plugin interface for a raw developer would be more complicated, but from a user standpoint it will be interesting and usefull.
Yeah, that’s exactly the point.
That is exactly why I did not test sigmoid too much, but with a few images, and could not follow its evolution.
Gimp has plugins and has a ton of them. Finding them and the correct version (and a binary if you want any sort of speed) is a pain.
Having plugins scattered all over the place with varying levels of conformance will be a poor user experience.
That is not a reason.
If you do not want to find them, just use the provided ones.
There can be repositories of third party plugins and they can be incorporated to main stream as soon as they are stable enough and main devs consider them good enough.
A pain is having lots of modules obsolete and conserved just for compatibility.
If they were plugins they could be deprecated and added only when the user wants them.
A pain is having tons of different open source software for developing and having to seek for them and test them until you encounter what you like, but worse is not having them and not finding one that you like. That is the very nature of open source.