Live data from Hacker News

Shaderblocks: Block-based image editing

thejenkinscomic.net

31–40 of 46 posts

Re: Shaderblocks: Block-based image editing

#31
post #3

This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.

You can do all that with comfyui now

Re: Shaderblocks: Block-based image editing

#32
post #9

Earlier quoted context omitted.

Indeed, it's weird that nobody has brought node-based editing to regular image manipulation before our project, but that's our goal with Graphite. With the equally important goal of making the node aspect optional for users by building such capable tooling that it can abstract away the node graph for all conventional image editing use cases, allowing users to work purely with the WYSIWYG tools that secretly manage th…

I wonder, where do SVG filters fall on the vector/raster spectrum? I really like that I can tune them hands-on in Inkscape (e.g. fractal noise + displacement map), and then use it anywhere that supports SVG. A little interactive demo from a while back: [0]: https://observablehq.com/@dleeftink/svg-workbench#options

We will have a large variety of filters and a subset of them will be implementations of all the SVG filters. Separate to our regular raster render process that's used for displaying content to the screen, we'll have an SVG render process used for exporting the graph data to an SVG file. That process will be specifically designed to preserve the purity of the graph data representation such that it encodes all possible operations in the SVG format directly, and resorts to progressive degradation as required to approximate things SVG can't natively represent. That might mean rasterizing some unsupported raster filters, but the ones SVG supports would be used natively.

Re: Shaderblocks: Block-based image editing

#33
post #9

Earlier quoted context omitted.

Indeed, it's weird that nobody has brought node-based editing to regular image manipulation before our project, but that's our goal with Graphite. With the equally important goal of making the node aspect optional for users by building such capable tooling that it can abstract away the node graph for all conventional image editing use cases, allowing users to work purely with the WYSIWYG tools that secretly manage th…

I don't think Graphite is the first. Gimel and GIE already exist, and I think there are other more obscure ones.

First in the sense that there's nothing in the industry that's a real product. Certainly there are various experimental concepts people have made as a hobby in a limited capacity, but they don't really count as generally useful tool suites. There's nothing even from the commercial software side of the industry either, which I find surprising. But it gives our project an advantage.

Re: Shaderblocks: Block-based image editing

#34

Earlier quoted context omitted.

https://graphite.rs/ (still early in development) offers node-based editing, you may be interested in trying it.

Could be a Photoshop killer.

I believe that's plausibly within the range is possible outcomes— which isn't true for any other project like Gimp, which has had its window of opportunity rise and then set forever.

Re: Shaderblocks: Block-based image editing

#35

Earlier quoted context omitted.

https://graphite.rs/ (still early in development) offers node-based editing, you may be interested in trying it.

Wow, looking at the demos on the website, I am insanely impressed at just how fast the editor loads into them, and just how snappy the procedural editing is, on my mid-range smartphone no less. That's genuinely inspiring! As someone who this week has had the itch to A) learn rust, B) use webassembly for something, and C) pick up Svelte for something, this was a really cool thing to see this morning :)

Thanks, we'd love to assist you in getting involved with contributing to our project! It's something we take pride in, making it more accessible than most other open source projects to begin contributing to. Come join our Discord (link is on the website home page) and introduce yourself like in your comment here. Cheers!

Re: Shaderblocks: Block-based image editing

#36
post #29
post #3

This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.

forgive my ignorance but does what you’re talking about with the “node-based compositing” basically boil down to how blender does it’s editing in a way?

Nuke and DaVinci Resolve are the industry standards for compositing. Node based editing graphs are often called “non-destructive” or “procedural”. It’s basically pure functions in a programming sense.

Blender geometry nodes take this approach for modeling. The rest of blender is destructive in that any operation permanently changes the state.

https://www.foundry.com/products/nuke-family/nuke

https://www.blackmagicdesign.com/products/davinciresolve

Re: Shaderblocks: Block-based image editing

#37
post #3

This reminds me of node-based compositing, which is mostly standard in the film industry but, to the best of my knowledge, never made it to still-image editing applications. After doing things the nodal way, it’s hard for me to use Photoshop nowadays and have to bake-in certain changes.

There are actually a number of more-or-less node/graph-based image editors: # chaiNNer Fully node-based image processing. https://github.com/chaiNNer-org/chaiNNer # vkdt Node-based raw and video editor. Sort of the evolution of darktable, by the original developer. https://jo.dreggn.org/vkdt/readme.html # darktable The graph is strictly linear (single input, single output), but you can change the order of the process…

Natron is also pretty well-known, I think?

https://natrongithub.github.io/

Re: Shaderblocks: Block-based image editing

#38
post #20

Earlier quoted context omitted.

It's super awesome of you to take the time to provide detailed feedback for a random stranger's project - good on ya! A single suggestion: Try using "the critique sandwich" when commenting on people's hard work - can help them appreciate the effort you've put in rather than feeling too defensive

I don’t really see how Lerc’s comment would benefit from the critique sandwich (more commonly called the “shit sandwich”, in my experience). Lerc was providing thoughtful suggestions for features to add. That’s not a criticism of what’s already in the project.

Based on my comment's negative score it would seem you're not alone.

I agree the feedback was thoughtful (as acknowledged in my reply) and read no ill-will in it and meant none myself

At risk of flogging a dead horse, it can be nerve wrecking to share things (or raise your first real PR, whatever) so I try to respond with that in mind - especially since text-only comms can come off as harsher than intended.

Re: Shaderblocks: Block-based image editing

#39

Earlier quoted context omitted.

It's super awesome of you to take the time to provide detailed feedback for a random stranger's project - good on ya! A single suggestion: Try using "the critique sandwich" when commenting on people's hard work - can help them appreciate the effort you've put in rather than feeling too defensive

I thought about it and added something positive to my comment which was more of a bug fix than a feature request. Maybe it was an open face sandwich.

> open face sandwich

This is gold :chefkiss:

Re: Shaderblocks: Block-based image editing

#40
I am unable to figure out how to use this.

I move blocks around. Some blocks I can attach to the bottom of "run this program" block and they clearly run. But I was unable to add any more blocks that did anything.

The screen is two dimensional so I was expecting to be able to put processing blocks anywhere. Sure I can but they do nothing.

What's missing (for me at least) is an explanation of the user interface.

Post reply on HN