Gimel Studio: Non-destructive, 2D image editor
gimelstudio.github.io
gimelstudio.github.io
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.
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?
Maybe the devs were simply focused, on you know, making the image editing part work before working on quality of life improvements.
"here's my project i've been working on for 2 years, but don't tell me anything about what needs improving because i'm not done yet" it just farcical
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.
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.
If you think this feedback is genuinely helpful and valuable that’s cool. All I can say is yikes.
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.
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.
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.
It makes the problem simpler IMO, as then you get to iterate on the language and capabilities independently of the UI.
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".
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.
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.
Maybe that's not a requirement. Adobe products will export commands as JavaScript and you can (could?) script most of their tools.
https://helpx.adobe.com/photoshop/using/scripting.html
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.
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.
Perhaps someone could explain to me what abilities this unlocks compared to a traditional editing system?
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
[1] Gimel Studio community chat (Zulip, needs sign-in) -- https://gimelstudio.zulipchat.com/#narrow/stream/320145-intr...
Not that this is a bad thing. Blender's is quite nice.
Why not make this commercial though? I wouldn’t mind spending a small amount of money on such an editor.
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.
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.
Everyone Else: Oh, okay, you do you then
*I've been that dev (more than once)
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.
Whatever that is.
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.
1. Output an Imagemagick script so the same effects could be applied to images say uploaded from a website.
2. This form of node based editing applied to other tools (GStreamer springs to mind which has a very node oriented workflow)
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.
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.
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.
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?
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.
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.
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.)
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.
I've done something similar with an audio editor.
Personally, I love graph editors and find them intuitive and easy to work with.
Graphs imply branching and recombination, while this product home page just shows a linear series of operations.
Is there branching so you can apply different sets of operations, and then recombination happens with blending operations?
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.
Ive been wanting someone to tackle this on the 2D side for a decade now.
So yeah, I'd agree that because one is a nerd does not mean they are well versed in all things nerdy.
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.
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.