7 ms·

Gimel Studio: Non-destructive, 2D image editor

178 points by lastdong 4y ago

breck 4y ago
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 https://ohayo.computer) and design a Tree Language (https://jtree.treenotation.org/designer/ 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.
- pronlover723 4y ago
  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".
  - TeMPOraL 4y ago
    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.
  - breck 4y ago
    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 https://breckyunits.com/user-methods.html), but was never crazy about that term.
    - pronlover723 4y ago
      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. https://helpx.adobe.com/photoshop/using/scripting.html 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.
kgeist 4y ago
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.
DoctorOW 4y ago
This looks really similar to Blender's node editor. Is there a relationship?
- lastdong 4y ago
  Hi DoctorOW, nicely spotted! 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-introductions/topic/introductions/near/295663993 https://gimelstudio.zulipchat.com/#narrow/stream/320145-intr...
  - SeriousM 4y ago
    Would you mind to post that short introduction here instead luring the interested reader into making an account on a chat platform, please?
- junon 4y ago
  My thoughts as well. Thought it might have been the same Node UI library being used, even. Not that this is a bad thing. Blender's is quite nice.
- mdre 4y ago
  Not just the UI, also the hotkeys! I immediately went for pressing Shift-A... awesome!
kybernetyk 4y ago
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. I've done something similar with an audio editor.
- programmarchy 4y ago
  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.
  - crazygringo 4y ago
    Forgive my ignorance, but what is the point of a graph editor in this 2D workflow, as opposed to a simple list of operations? 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?
    - underanalyzer 4y ago
      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
    - WastingMyTime89 4y ago
      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.
    - 4y ago
S0und 4y ago
2d image editor aka. node based compositor?
- dylan604 4y ago
  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. Everyone Else: Oh, okay, you do you then *I've been that dev (more than once)
  - doph 4y ago
    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.
    - themodelplumber 4y ago
      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.
- TeMPOraL 4y ago
  > node based compositor 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.
codetrotter 4y ago
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.
- dylan604 4y ago
  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?
  - WastingMyTime89 4y ago
    That’s UX improvement and we are taking about a v0.6. Maybe the devs were simply focused, on you know, making the image editing part work before working on quality of life improvements.
    - dylan604 4y ago
      But with enough prior research into what was there, this is the kind of thing that gets added to UX immediately, not in v1.x
      - Ralfp 4y ago
        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.
internet-mat 4y ago
Reminds me a bit of https://graphite.rs/ https://graphite.rs/
helf 4y ago
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.
- MrScruff 4y ago
  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.
  - helf 4y ago
    Ok makes more sense for film. Thanks for the info
- incrudible 4y ago
  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.
  - helf 4y ago
    I good I’ll give it a more in-depth study. Thanks for the info :)
- blacklion 4y ago
  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!
  - helf 4y ago
codesnik 4y ago
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.
blacklion 4y ago
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.
DethNinja 4y ago
This looks amazing. Lots of people complain about node based editor but there is a real need for non-destructive/parametric 2D workflows. Why not make this commercial though? I wouldn’t mind spending a small amount of money on such an editor.
jcelerier 4y ago
if someone is interested in similar concept but for real-time visuals, https://ossia.io https://ossia.io is starting to have a fairly complete real-time node-based shader pipeline, which uses https://isf.video https://isf.video as standardized shader format :) any feedback would be very welcome!
berkut 4y ago
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?
Rodeoclash 4y ago
Looks great, I wonder if it could: 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)
yterdy 4y ago
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.
- WastingMyTime89 4y ago
  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.
  - BizarroLand 4y ago
    My only reservation about this is that I don't quite see the appeal of node-based editing for static images. Perhaps someone could explain to me what abilities this unlocks compared to a traditional editing system?

178 points by lastdong 4y ago

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 https://ohayo.computer) and design a Tree Language (https://jtree.treenotation.org/designer/ 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.

pronlover723 4y ago
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".
- TeMPOraL 4y ago
  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.
- breck 4y ago
  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 https://breckyunits.com/user-methods.html), but was never crazy about that term.
  - pronlover723 4y ago
    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. https://helpx.adobe.com/photoshop/using/scripting.html 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.

kgeist 4y ago

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.

DoctorOW 4y ago

This looks really similar to Blender's node editor. Is there a relationship?

lastdong 4y ago
Hi DoctorOW, nicely spotted! 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-introductions/topic/introductions/near/295663993 https://gimelstudio.zulipchat.com/#narrow/stream/320145-intr...
- SeriousM 4y ago
  Would you mind to post that short introduction here instead luring the interested reader into making an account on a chat platform, please?
junon 4y ago
My thoughts as well. Thought it might have been the same Node UI library being used, even. Not that this is a bad thing. Blender's is quite nice.
mdre 4y ago
Not just the UI, also the hotkeys! I immediately went for pressing Shift-A... awesome!

kybernetyk 4y ago

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. I've done something similar with an audio editor.

programmarchy 4y ago
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.
- crazygringo 4y ago
  Forgive my ignorance, but what is the point of a graph editor in this 2D workflow, as opposed to a simple list of operations? 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?
  - underanalyzer 4y ago
    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
  - WastingMyTime89 4y ago
    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.
  - 4y ago

S0und 4y ago

2d image editor aka. node based compositor?

dylan604 4y ago
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. Everyone Else: Oh, okay, you do you then *I've been that dev (more than once)
- doph 4y ago
  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.
  - themodelplumber 4y ago
    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.
TeMPOraL 4y ago
> node based compositor 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.

codetrotter 4y ago

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.

dylan604 4y ago
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?
- WastingMyTime89 4y ago
  That’s UX improvement and we are taking about a v0.6. Maybe the devs were simply focused, on you know, making the image editing part work before working on quality of life improvements.
  - dylan604 4y ago
    But with enough prior research into what was there, this is the kind of thing that gets added to UX immediately, not in v1.x
    - Ralfp 4y ago
      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.

internet-mat 4y ago

Reminds me a bit of https://graphite.rs/ https://graphite.rs/

helf 4y ago

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.

MrScruff 4y ago
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.
- helf 4y ago
  Ok makes more sense for film. Thanks for the info
incrudible 4y ago
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.
- helf 4y ago
  I good I’ll give it a more in-depth study. Thanks for the info :)
blacklion 4y ago
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!
- helf 4y ago

codesnik 4y ago

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.

blacklion 4y ago

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.

DethNinja 4y ago

This looks amazing. Lots of people complain about node based editor but there is a real need for non-destructive/parametric 2D workflows. Why not make this commercial though? I wouldn’t mind spending a small amount of money on such an editor.

jcelerier 4y ago

if someone is interested in similar concept but for real-time visuals, https://ossia.io https://ossia.io is starting to have a fairly complete real-time node-based shader pipeline, which uses https://isf.video https://isf.video as standardized shader format :) any feedback would be very welcome!

berkut 4y ago

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?

Rodeoclash 4y ago

Looks great, I wonder if it could: 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)

yterdy 4y ago

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.

WastingMyTime89 4y ago
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.
- BizarroLand 4y ago
  My only reservation about this is that I don't quite see the appeal of node-based editing for static images. Perhaps someone could explain to me what abilities this unlocks compared to a traditional editing system?