Shaderblocks: Block-based image editing • Hacker News Board

Re: Shaderblocks: Block-based image editing

#21

Post by dleeftink » Sun, Nov 10, 2024, 1:43 PM UTC

donatzsky wrote: post #17

dabinat wrote: 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…

Oldie but goodie is Nodebox[0] and for data-driven/dynamic compositing see Cables.gl[1]. Kirell Benzi's work uses the latter and is nothing short of breathtaking[2].

[0]: https://www.nodebox.net/

[1]: https://cables.gl/

[2]: https://youtu.be/CltYdTVH7_A

Re: Shaderblocks: Block-based image editing

#22

Post by PaulHoule » Sun, Nov 10, 2024, 1:54 PM UTC

Note it almost works on an iPad. It seems that it should be possible to scroll the palette of blocks but I can’t. I had trouble with it loading the one that makes a circle, it displayed only a tiny piece for a few seconds before finally showing the whole.

Otherwise though it is most of the way there to being a really fun tablet app!

Re: Shaderblocks: Block-based image editing

#23

Post by dleeftink » Sun, Nov 10, 2024, 1:56 PM UTC

Keavon wrote: post #9

littlestymaar wrote: post #5

Earlier quoted context omitted.

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

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

Re: Shaderblocks: Block-based image editing

#24

Post by PaulHoule » Sun, Nov 10, 2024, 1:57 PM UTC

pentaphobe wrote: post #10

Lerc wrote: post #8

A couple of suggestions. A clearer mechanism to indicate when a dragged component will fit into a cell of another node. Quite often when you drag the highlighted drop area is obscured by the node you are dragging. pow(a,b) and abs(b), max(a,b), min(a,b) nodes would add a lot of functionality. Then you could do something like. (((1 / abs((((0 - (y-0.5)) * 6) - ((sin(((((x-0.5) * 6) + time) * ((cos(time) / 3) + 2))) /…

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.

Re: Shaderblocks: Block-based image editing

#25

Post by CyberDildonics » Sun, Nov 10, 2024, 2:42 PM UTC

dabinat wrote: 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.

Most of what people do in photoshop is easier in a node based system anyway since you can made a non destructive graph of operations. The biggest downside is that the best program is nuke, which is expensive, but anyone can use fusion for free or pay a few hundred dollars for a lower tier of houdini and use those image manipulations.

Houdini also allows vex shaders out of nodes, which is basically a more polished version of this interface where you can manipulation pixels more directly and make your own nodes.

Re: Shaderblocks: Block-based image editing

#26

Post by PaulHoule » Sun, Nov 10, 2024, 3:23 PM UTC

dabinat wrote: 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.

I’ve been interested in those “boxes and lines” frameworks for a long time. For instance numerous data transformation tools like Alteryx and KMIME and also LABView.

Node-based systems are used in music for synthesis and effects extensively and have been so since it was feasible to process digital audio in real time. In the 60s electronic music pioneers put together analog oscillators on a patchboard. Today musicians do the same in a screen with digital operators that are accurate and stable enough to build systems (like the Yamaha DX7) that couldn’t really be built from analog parts.

It is clear how to write a compiler for that kind of graph and probably less struggle than manually writing a “shader function”

   int16 amplitude(int32 time)

that composes a number of large-scale functions (resample, decimate, reverb, add, …) that are implemented using various strategies. Operator graphs can be compiled to target CPU, SIMD, DSP, MPI, GPU, Spark, etc.

The dominant paradigm in graphics is still shader programs, however.

Re: Shaderblocks: Block-based image editing

#27

Post by PaulHoule » Sun, Nov 10, 2024, 3:24 PM UTC

littlestymaar wrote: post #5

dabinat wrote: 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.

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

Could be a Photoshop killer.

Re: Shaderblocks: Block-based image editing

#28

Post by throwawayk7h » Sun, Nov 10, 2024, 3:44 PM UTC

dabinat wrote: 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.

I wish the GIMP offered something like this.

Re: Shaderblocks: Block-based image editing

#29

Post by yapyap » Sun, Nov 10, 2024, 3:54 PM UTC

dabinat wrote: 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?

Re: Shaderblocks: Block-based image editing

#30

Post by treflop » Sun, Nov 10, 2024, 4:08 PM UTC

dabinat wrote: 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.

Video consists of many frames and you have to apply the same but slightly different transformations to each frame. Building a pipeline (via nodes or not) to describe these repeated changes is worth the extra effort.

Outside of batch jobs, image editing tasks are generally one offs with image-specific actions and building a change pipeline is unnecessary work.

At the end of the day, both workflows are different tools, like hammer vs. mallet.