Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Gimel Studio: Non-destructive, 2D image editor

gimelstudio.github.io

Post reply on HN
Print view View original

51–60 of 64 posts

Re: Gimel Studio: Non-destructive, 2D image editor

#51

Post by forrestthewoods »

dylan604 wrote: post #50
forrestthewoods wrote: post #48

Earlier quoted context omitted.

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 t…

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…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#52

Post by yterdy »

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#53

Post by berkut »

forrestthewoods wrote: post #51
dylan604 wrote: post #50

Earlier quoted context omitted.

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…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#54

Post by dylan604 »

forrestthewoods wrote: post #51
dylan604 wrote: post #50

Earlier quoted context omitted.

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…

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.

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#55

Post by forrestthewoods »

dylan604 wrote: post #54
forrestthewoods wrote: post #51

Earlier quoted context omitted.

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.

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 in…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#56

Post by WastingMyTime89 »

yterdy wrote: post #52

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, yo…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#57

Post by GuB-42 »

somat wrote: post #39
codesnik wrote: post #26

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?

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…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#58

Post by somat »

GuB-42 wrote: post #57
somat wrote: post #39

Earlier quoted context omitted.

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…

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 funct…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#59

Post by TeMPOraL »

forrestthewoods wrote: post #55
dylan604 wrote: post #54

Earlier quoted context omitted.

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 in…

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.

Re: Gimel Studio: Non-destructive, 2D image editor

#60

Post by TeMPOraL »

pronlover723 wrote: post #41
breck wrote: post #2

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…

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 ed…

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.

Post reply on HN