[HN Gopher] Gimel Studio: Non-destructive, 2D image editor
___________________________________________________________________
Gimel Studio: Non-destructive, 2D image editor
Author : lastdong
Score : 156 points
Date : 2023-01-08 09:39 UTC (13 hours ago)
(HTM) web link (gimelstudio.github.io)
(TXT) w3m dump (gimelstudio.github.io)
| codesnik wrote:
| 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?
| blacklion wrote:
| 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.
| ookdatnog wrote:
| 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.
| somat wrote:
| 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
| breck wrote:
| 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.
| pronlover723 wrote:
| 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".
| S0und wrote:
| 2d image editor aka. node based compositor?
| dylan604 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| > _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.
| jcelerier wrote:
| 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!
| codetrotter wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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.
| dylan604 wrote:
| Don't post your not ready for prime time project to the
| public if you're not open to public opinion.
|
| "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
| themodelplumber wrote:
| 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.
| lastdong wrote:
| +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.
| kgeist wrote:
| 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.
| blacklion wrote:
| 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.
| helf wrote:
| 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.
| blacklion wrote:
| 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 wrote:
| Thanks I'll look up that stuff. Thanks for the response :)
| MrScruff wrote:
| 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 wrote:
| Ok makes more sense for film. Thanks for the info
| incrudible wrote:
| 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 wrote:
| I good I'll give it a more in-depth study. Thanks for the
| info :)
| kybernetyk wrote:
| 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.
| WastingMyTime89 wrote:
| > 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.
| TeMPOraL wrote:
| > _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.
| programmarchy wrote:
| 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 wrote:
| 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 wrote:
| 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
| whywhywhywhy wrote:
| 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.
| WastingMyTime89 wrote:
| 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.
| dylan604 wrote:
| Resolve and Nuke are also node based
|
| So yeah, I'd agree that because one is a nerd does not mean
| they are well versed in all things nerdy.
| DethNinja wrote:
| 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.
| internet-mat wrote:
| Reminds me a bit of https://graphite.rs/
| berkut wrote:
| 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?
| DoctorOW wrote:
| This looks really similar to Blender's node editor. Is there a
| relationship?
| junon wrote:
| 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 wrote:
| Not just the UI, also the hotkeys! I immediately went for
| pressing Shift-A... awesome!
| lastdong wrote:
| 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-intr...
| SeriousM wrote:
| Would you mind to post that short introduction here instead
| luring the interested reader into making an account on a chat
| platform, please?
___________________________________________________________________
(page generated 2023-01-08 23:00 UTC)