In the demo, when they add a new node between two existing nodes, they first add the node then disconnect the two other nodes then connect the two others to the new node.
As others pointed out it looks similar to the node editor in Blender.
I am fairly certain that in Blender you can drag a node onto the connection between two nodes and it will be connected.
That makes adding nodes less tedious.
Does Gimel Studio support doing that also? If not, I highly recommend that said feature be added to Gimel Studio.
There are so many helpful node workflow conveniences that there really needs to be a standard for them IMO. Otherwise the default is to start with a layer of unnecessary tedium around the flexibility.
Something like an AI coding partner would also be super helpful with nodes, eg "suggested pattern: you're recreating this common image editing filter or one of these variations" and boom, all the connections fall into place.
(Dragging connections across the screen is fun until it's the same lines most of the time...have used a lot of different node workflows over the years)
Also I'm still hoping for a generalized node workflow desktop...but I guess I might settle for a text editor.
For example you see nodes for a timer/cron job to generate the first part of your markdown --> text editor node with your template (into which a markdown highlighting plugin is also plugged) --> Pandoc node --> separate nodes for HTML, LibreOffice output filtering --> (LO as a node would be cool btw) --> SSH file transfer (HTML) and Email (to someone) nodes --> various inputs to those, etc.
+1 for the really good suggestion. Not sure if it's common but definitely Blender has this feature.
Gimel Studio is on v0.6.0 pre-alpha 2, with just basic functionality and not feature complete obviously -- my bad, the title could be more explicit about the version.
A lot of improvements to be added.
Yikes! I can't imagine working like this. Every node based editing system I have used behaves exactly like you describe where adding/dropping a node on a connection between to existing nodes automatically connects the new node as expected.
The only time I've seen this add new, disconnect, make new connections are in chart/graph programs like Omnigraffle or similar programs people draw up database schemas and network topologies. Maybe the devs came from that kind of world?
This is an open-source project with 13 contributors and initial commit made two years ago you are talking about. Is it really fair to expect them to have everything from version 0.6? It's likely that they have 2137 other must-have features or blockers they have to divide their attention between.
If your biggest complaint is a relatively minor UX improvement then they're crushing it!!!
TBH, that's about the most shallow, surface level feedback that could possibly be given. This project is providing a pretty radically different paradigm for image editing. Is that a good paradigm? Is it useful? Does it allow novices and/or experts to do work faster? Are there things it can't do? What would it take to do those things? Does it need new nodes types? More options on existing nodes?
I don't know the answer. TBH it's a pretty hard sell. Either it works or it doesn't. A missing feature in the node editor is not in the Top 1000 most important things.
If your app slows down the user by having to make repetitive tasks because your UX is lacking, then there's a whole lot of no responses to your questions. Not really sure how that's hard to comprehend. Eliminating repetitive tasks is why we invented computers. Using a computer to create a new method of repetitive tasks is not good use of those computers or the user's time.
It's like the first gens of iOS that did not allow for copy&paste. Was that a shallow bit of feedback? No, because it's some of the most basic functionality a user would expect to be there. If iOS and no copy&paste was released in the 1980s, it might have been forgiven. Since it was released in 2007 after anyone using computing had seen/used copy&paste and the competing product did have that functionality, it was a huge slight against it. Was copy&paste the core functionality? Probably not, but it was a huge hindrance.
After getting past the fact this is node based editing, it's pretty much an image editor after that. Again, if anything you try to implement is less than pre-existing software, what's the point. So, when you present an application that is supposed to be paradigm shifting, you better be backing it up. Again, don't want public comments, don't post the software to public forum created solely for public commenting.
There’s an obvious difference between “save two easy clicks” (node graph) and “save dozens to hundreds, and sometimes thousands, of awkward taps” (iOS copy/paste).
If you think this feedback is genuinely helpful and valuable that’s cool. All I can say is yikes.
It's "two" clicks on a very simple node network: if you look at some of the > 1000-10k node networks used in VFX for things like compositing/image editing and see artists re-arrange networks, it all adds up cumulatively, and having a fluid and efficient workflow is critical.
Have you ever used a node based editor? You don't just make a single node. For every edit you do, you make a node. Resize? new node. Adjust RAW settings? new node. Isolate color to make a mask? new node. Apply blur? new node. I just don't know how you can sit there and say that you won't do this thousands of time in a session of image editing and be expected to be taken seriously.
If you can't drag-n-drop the node into a different order, that's also bad. why? It's just one of the advantages of node based editing, and part of that is the ability to quickly disconnect/reconnect/re-order the nodes. That's part of the UX that should be in first public releases. At the end of the day, you can skin something like ImageMagick to have a node based UI/UX and solve the majority of the things you seem to think are important as a first release. If you're releasing a node based image editor, I want to see how the nodes behave.
I've used many different node editors. I've even built some! I just double-checked and Unreal Engine's node editors do NOT support inserting a node into an existing link. Take from that what you will.
As much as I don't want to pile on complaints about UI ergonomics on what's clearly a pre-MVP alpha proof-of-concept (and which, IMO, has great potential) - since you brought up Unreal Engine, I feel compelled to agree with your parent poster here: even for casual user like me, the UE node editor (both in Blueprints and shaders) is the limiting factor in development/iteration/thinking speed. I love the hands-on, immediate, bullshit-free approach and discoverability the UE Blueprints offer, but from the first minute of playing with them, I found myself wanting to go back to code, because of all the low-level manual dragging and dropping involved. UE is a legitimate target to complain about, because it's been production-ready and sold for good money for a long time now.
Interesting! I've done some visual node based editors in the past. One design principle I might suggest: develop a DSL and have the editor just be editing programs in that DSL. You might be able to use Racket—not sure—but alternatively you could copy what I've done here (https://ohayo.computer) and design a Tree Language (https://jtree.treenotation.org/designer/).
It makes the problem simpler IMO, as then you get to iterate on the language and capabilities independently of the UI.
This is one of the things I used to like about Maya. It appeared to be a command driven editor and everything you did in the UI translated to a command line command. You could set it to show the commands and even capture them and use them as a start for generating a script
I don't know if it's still that way after the transition from Mel to Python. I haven't used Maya in 15 years
Even more, Maya also was like a 3D editor OS/Engine. The UI itself was written in the scripting language (~1500 melscript files) using the primitives from the "engine".
Never used Maya, but what you describe sounds like something that's common in CAD software. I imagine this was spearheaded by AutoCAD and is a natural consequence of using Lisp as the underlying command/extension language :).
Two other applications that may be structured similarly are GIMP and Audacity (the audio editor). I say may, because I never looked under the hood to check on the internal architecture, but both also ship with an embedded Lisp interpreter for automation and extension, that integrates deeply with the tool's features.
Interesting! This is how I design all of my software.
Do you know the term for this pattern? Is it simply the "Command pattern"? I called it "User Methods" once (https://breckyunits.com/user-methods.html), but was never crazy about that term.
It is the command pattern with the added stipulation that there must be some way to represent every command as a simple command line like expression. MelScript commands look a lot like shell commands.
Maybe that's not a requirement. Adobe products will export commands as JavaScript and you can (could?) script most of their tools.
The difference there is it's an afterthought vs Maya where the UI you interact with is literally implemented in this scripting language, all of which is editable if you want to customize it.
I'll be back in 5-10 years when the devs get over themselves and the application actually reflects the "simplicity, elegance, and usability" that it purports to.
This may come off as unfair, but I say it as an artist who vividly recalls the frustration of using Blender and GIMP in the 2000s - and, particularly, of trying to get contributors to understand that, actually, the industry standard software had it right, you don't have to change basic UX elements, you're making it more difficult for us to use this software (or, perhaps even more important, to convince colleagues/bosses/collaborators to use it).
I already see it in the comments here: users expressing their misgivings and others (admittedly, just one or two vocal individuals, for now) shouting down their concerns as stupid or irrational. My first impression was that this is unnecessary, though I'm coming around to the potential. If Gimel is destined to become a useful tool, I hope it's able to do so without the pain so many other pieces of software that are aimed at artists and designers that the devs won't listen to go through.
I personally mostly see the usual HN comments here of people presenting valuable work and commenters shooting it down either because they are unaware of where it comes from, it doesn’t perfectly conform to what they expect or it’s not to their standards considering its insane cost of free. Your comment is very much in keeping with the tradition if I may say so.
The original creator, Noah, has posted a short introduction in the community chat[1] where he highlights the influence of Blender 3D and the node-based workflow for the app
Seems a bit odd to have a 16-bit workflow (clearly not full float32 then?) if it supports EXR files, which natively support 32-bit float (in addition to half float)? Given they appear to be using GLSL for the pixel processing, surely 32-bit float would be trivial to support as well?
I once tried to make something similar, I used OpenCL for performance. But either my knowledge wasn't sufficient or the architecture wasn't properly designed, so on complex node trees the performance was pretty bad; if I remember correctly - because there was too much data being copied between RAM and VRAM back and forth and the engine was designed to be too flexible (for example, an arbitrary number of color channels) it harmed the performance. Eventually my enthusiasm faded and I abandoned the project. The original idea was to replicate Foundry Nuke's flow. Back then it supported GPU only for some of the operators.
I understand why this approach can be useful. What I don't like from first glance is screen space "wasted" to node graph. When I edit image (which can be much larger than 4K video frame, not to mention 1080p video frame) I want to spend my precious screen real estate for image's pixels. So, this software screams for two monitor setup, and no so useful on laptops...
On the other hand, if it (will?) be possible to work in several color models in one graph it will be very useful to implement Dan Margulis' color correction technics which require working with channels from different color models simultaneously.
Sounds to me a lot like people that have a narrow and shallow level of experience in the field they are diving into, so they keep bumping into the walls.
Dev: I had this great idea of making this new thing because I haven't seen it before
Everyone Else: Yeah, it looks like this or this or even that. Have you looked at what other people have done and the pain points they solve or cause?
Dev: Nah, this is a totally different idea that nobody's done before.
As a graphics professional who loves node-based workflows, I find the constant re-invention of the wheel pretty painful. With some coordination of this effort, Blender or Natron could be real open-source challengers to Nuke, but starting from scratch seems always to be more enticing.
The reinvention of the wheel with nodes is truly difficult to watch.
There are also very close cousins like Reason and its rack connections, which could contribute some nodes-101-level concepts to most basic graphical node workflows.
Based on replies in the subthread, I understand you mean that this obviously has been done many times before, and the authors didn't know, based on the naming. But let me offer a different perspective.
Gimel Studio looks exactly like what I was searching for. If I found out about it a month ago, I would hold off upgrading Affinity Photo to their newly released version 2, to get more layer-based non-destructive editing features, because Photoshop-style layer-based interface sucks (mostly it's too twiddly and requires too much high-precision mouse operations on a tiny side panel). I actually briefly looked for some 2D node-based image editors, and didn't find any. "Node based compositor" sounds like something from Blender or the film industry, so despite sort of being aware of this, it never occurred to me to search in this space.
Or, in short: for people like me, who are looking for software competing with GIMP, Photoshop, Affinity or Paint.NET, and not Blender or Houdini or whatever else VFX people use, "2D image editor" is obviously meaningful, "compositor" is not.
if someone is interested in similar concept but for real-time visuals, https://ossia.io is starting to have a fairly complete real-time node-based shader pipeline, which uses https://isf.video as standardized shader format :) any feedback would be very welcome!
What… is the point of node editing? Current image editing is only destructive if you save over the original file? What am I missing? This seems way more tedious than just making the changes like in Lightroom.
It is more tedious for simple stuff than layer stacks, but more complex stuff quickly becomes more tedious (or impossible) with layer stacks. Hence, node UIs have become standard with compositing applications that were not designed by Adobe.
Nodal based image editing is the standard in the film industry, though obviously there it’s predominantly used for sequences of images. Nuke is the industry standard, though there are a few others.
I would agree it’s pointless if you just want a simple linear set of image processing operations like Lightroom, but film based compositing is obviously vastly more complex than that.
Many Dan Margulis' tricks cannot be reproduced in Lightroom model. Especially tricks which need to work in different color models simultaneously. Even full Photoshop struggle to represent these tricks in non-destructive way!
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.
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.
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?
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.
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.
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.)
Simplicity? Well, if you're used to GNU Radio maybe ;)
The graph view on top will be very off-putting to normal users. It's even off-putting to me and I'm a huge nerd.
I'd rather hide the non-destructive nature in a normal graphical editor UI people are used to. So people can edit away and when they're happy with a version of the file they can just flag it. And then they can jump between those flagged versions or browse the whole history with instant revision switching.
> Simplicity? Well, if you're used to GNU Radio maybe ;)
The snark is uncalled for. You are just ignorant of the field you are commenting about.
This kind of interface is extremely common in software geared towards image correction in the video industry. That’s the standard for colour correction for example.
Graph editors are fairly normal in the design world. See Blender, Houdini FX, Substance Designer, Unreal Engine, etc. So maybe as a huge nerd you’re not a normal user.
Personally, I love graph editors and find them intuitive and easy to work with.
I would guess combining pieces of two images is a simple place where the graph could become non linear. Agree that if that is the case they should indicate it in their gifs tho
A node system can do everything a linear system can but also branch or send the same asset down multiple flows and back again without the linear workflow crutches for that (“smart objects”/“symbols”).
Ive been wanting someone to tackle this on the 2D side for a decade now.
It’s not a 2D workflow. Editing involves branching.
It’s usual to apply treatment to the image then merge it back using a special kind of merge for exemple to isolate a colour channel or to do things on the desaturated image to work on lighting.
> The graph view on top will be very off-putting to normal users. It's even off-putting to me and I'm a huge nerd.
What I believe is also off-putting to a casual user of image editors is... layer-based workflow. Layers are great as a concept. Effect / "live" / non-destructive transformation layers are even greater still. But the Photoshop-style UI everyone copies is just plain bad. I've recently been doing lots of non-destructive layer-based editing in Affinity Photo 2, and almost from the very start, I found myself dreaming about a node-based UI, or at least a layer-centric UI.
That said, looking at the screenshot, I'd probably make the node-based editor an overlay on top of the image that you can quickly (as in sub-100ms) toggle on or off, or at least have the interface split vertically (due to the market standardizing on those ridiculous ~16:9 aspect ratios).
> I'd rather hide the non-destructive nature in a normal graphical editor UI people are used to. So people can edit away and when they're happy with a version of the file they can just flag it. And then they can jump between those flagged versions or browse the whole history with instant revision switching.
That sounds like... pain, and eliminates a lot of the value that non-destructive editing brings when it's the primary philosophy and mode of working. The approach you describe reminds me of Microsoft Word - for at least 15 years (and probably more), it came packed with structural/semantic editing features, and nobody uses them anyway, because people still find it easier to "edit away" in immediate mode, and by the time they notice the problem, it's too much work to fix it.
As others pointed out it looks similar to the node editor in Blender.
I am fairly certain that in Blender you can drag a node onto the connection between two nodes and it will be connected.
That makes adding nodes less tedious.
Does Gimel Studio support doing that also? If not, I highly recommend that said feature be added to Gimel Studio.