Proposal for hybrid Texture / Shader node graph

A feature that I notice a lot of users requesting is the ability to "edit," images and textures directly from within the shader editor, such as blur, apply filters, and so on.

From an artistic viewpoint it's perfectly understandable why they would expect these features to exist. I mean, we can already "edit," them by adjusting brightness and saturation, so why wouldn't we be able to apply filters?

Now the more technical among you might know the reason why this isn't possible / is really difficult, but I will provide a quick overview here just in case: Shaders work by processing every pixel in parallel (at the same time), so any calculations need to be able to be done without knowing the pixels around it. Things like brightness and saturation work because all you need to do is take the brightness and multiply it by a value (IE: currentBrightness * 2 in order to make it twice as bright) which can easily be done in parallel. Things like blurring on the other hand require us to know the value of the pixels adjacent to the current pixel, and therefore it makes it a lot more difficult or even impossible to calculate depending on the system.

While it would certainly be possible to bring back an updated version of the "Texture nodes," that we had in previous iterations of Blender, it would add another layer of complexity and inconvenience to the end user. I propose a hybrid system that would would actually combine both Shader and Texture nodes into a single graph in a way that would be transparent to the end user, and provide a more fluid workflow.

My solution would to implement any nodes that require CPU processing as their own separate category, but let them be added in along side standard shader nodes. Most of these effects could be run pretty quickly on a modern day CPU, so similar to how Eevee rebuilds shaders when the file opens, Blender could process and "bake,"/ "cache," these image effects into generated textures on launch, and then use standard texture mapping techniques to apply them to the shaders. A simple checkbox could also allow these textures to be cached to disk to avoid a rebuild unless they are changed.

Most shader node trees which use textures are usually split into two "halves." The half on the left usually does texture manipulation, which then gets plugged into the half on the right which does shader manipulation. Excluding Eevee's "Shader to RGB," node, there really shouldn't be any cases where that case is reversed, meaning this implementation should be possible from a technical standpoint.