3 ms·

I've never understood the need for 2d schematic editor when a ordered list of filters would suffice. Do you like to move pixels around that much?

ookdatnog 4y ago
An ordered list of filters would limit the user to providing one input image and producing one output. Using a schematic editor allows for combining multiple inputs and perhaps even producing multiple outputs from one schematic (the gif on the home page doesn't show this so I don't know if they support this). Of course you don't need a schematic editor for that, you could also use an expression language with variables. But for people not used to programming that tends to be a bit intimidating.
blacklion 4y ago
Did you read Dan Margulis books on color correction and photo editing? Some of his tricks needs forks in processing graph for sure, and is not expressible in Photoshop Layers in non-destructive, configurable way. Channel extraction and replacement after some processing like blurring and masking, for example. Sometimes in different color models, like replace RGB Red channel with CMYK Magenta one, blurred and masked with Black.
somat 4y ago
you may need a complex graph of filters, However I suspect you will never want a full graph and a tree of filters will suffice. You will have to ask the math boys about that. My main problem with node editors is that I wish the layout were better managed, let the machine handle it. There is something that feels awkward about node editing to me, but I am not smart enough to come up with an alternative. A tree browser perhaps, Or something like the scratch programing environment? https://scratch.mit.edu https://scratch.mit.edu
- GuB-42 4y ago
  What you need is a DAG (directed acyclic graph), a tree is not sufficient, and allowing cycles would be messy. DAGs are also the fundamental structure of git commits, and this is what you will see if you do "git log --graph" as well as in most graphical tools. The advantage of letting a user do the layout manually is that he can reorganize nodes the way he wants, for example grouping together subgraphs that are functionally related. It doesn't exclude an auto-layout option if the user doesn't want to micromanage his graph.
  - somat 4y ago
    I thought DAGs were trees, or was that the other way around? I may also be getting DAGs confused with merkel trees(which I also thought were the sameish thing). My laymans understanding is that once you cut the cycles off your graph(to turn it into a DAG) it now structurally is a tree.
    - TeMPOraL 4y ago
      DAGs are a superset of trees. All trees are DAGs, but not all DAGs are trees. One way of looking at it is: you a non-tree DAG if you allow the tree nodes to have multiple parents. One of the reasons trees are so popular in software development, despite the fact most problems being solved with them factor into DAGs much more naturally, is that trees can be rendered nicely in plain text, while DAGs in general can not. DAGs are really the fundamental structure of almost everything we work with. Git commits are arranged in DAGs. But so is code we write itself - think of a function A, called by functions B and C, both of which are called by function D and E; that's a DAG right there. Even the "abstract syntax tree" is, in a way, planarizing a DAG (it's tree-ish only because you duplicate symbols that are, in fact, a single entity). Filesystems look like trees, but the moment you add support for symlinks, they become a DAG (if you allow symlink loops to form, then it's not even acyclic anymore). Inter-module dependencies of your software form a DAG. Etc. (Some things are even more naturally represented by a directed graph with possibility of cycles, but we try to avoid that as it's hard to deal with - a cycle is like an infinite loop if you try to step through it, so to handle it statically, you need to be able to compute a stable state of the entire cycle in one go - and if you have time/external input component, then you now have a dynamic system that you'll most likely have to simulate, and something that's tricky to reason about without control theory background.)

ookdatnog 4y ago

An ordered list of filters would limit the user to providing one input image and producing one output. Using a schematic editor allows for combining multiple inputs and perhaps even producing multiple outputs from one schematic (the gif on the home page doesn't show this so I don't know if they support this). Of course you don't need a schematic editor for that, you could also use an expression language with variables. But for people not used to programming that tends to be a bit intimidating.

blacklion 4y ago

Did you read Dan Margulis books on color correction and photo editing? Some of his tricks needs forks in processing graph for sure, and is not expressible in Photoshop Layers in non-destructive, configurable way. Channel extraction and replacement after some processing like blurring and masking, for example. Sometimes in different color models, like replace RGB Red channel with CMYK Magenta one, blurred and masked with Black.

somat 4y ago

you may need a complex graph of filters, However I suspect you will never want a full graph and a tree of filters will suffice. You will have to ask the math boys about that. My main problem with node editors is that I wish the layout were better managed, let the machine handle it. There is something that feels awkward about node editing to me, but I am not smart enough to come up with an alternative. A tree browser perhaps, Or something like the scratch programing environment? https://scratch.mit.edu https://scratch.mit.edu

GuB-42 4y ago
What you need is a DAG (directed acyclic graph), a tree is not sufficient, and allowing cycles would be messy. DAGs are also the fundamental structure of git commits, and this is what you will see if you do "git log --graph" as well as in most graphical tools. The advantage of letting a user do the layout manually is that he can reorganize nodes the way he wants, for example grouping together subgraphs that are functionally related. It doesn't exclude an auto-layout option if the user doesn't want to micromanage his graph.
- somat 4y ago
  I thought DAGs were trees, or was that the other way around? I may also be getting DAGs confused with merkel trees(which I also thought were the sameish thing). My laymans understanding is that once you cut the cycles off your graph(to turn it into a DAG) it now structurally is a tree.
  - TeMPOraL 4y ago
    DAGs are a superset of trees. All trees are DAGs, but not all DAGs are trees. One way of looking at it is: you a non-tree DAG if you allow the tree nodes to have multiple parents. One of the reasons trees are so popular in software development, despite the fact most problems being solved with them factor into DAGs much more naturally, is that trees can be rendered nicely in plain text, while DAGs in general can not. DAGs are really the fundamental structure of almost everything we work with. Git commits are arranged in DAGs. But so is code we write itself - think of a function A, called by functions B and C, both of which are called by function D and E; that's a DAG right there. Even the "abstract syntax tree" is, in a way, planarizing a DAG (it's tree-ish only because you duplicate symbols that are, in fact, a single entity). Filesystems look like trees, but the moment you add support for symlinks, they become a DAG (if you allow symlink loops to form, then it's not even acyclic anymore). Inter-module dependencies of your software form a DAG. Etc. (Some things are even more naturally represented by a directed graph with possibility of cycles, but we try to avoid that as it's hard to deal with - a cycle is like an infinite loop if you try to step through it, so to handle it statically, you need to be able to compute a stable state of the entire cycle in one go - and if you have time/external input component, then you now have a dynamic system that you'll most likely have to simulate, and something that's tricky to reason about without control theory background.)