Hello everyone, I am Madhav Goyal.
Final year Undergrad student from India, studying CS. I am interested in contributing to Blender’s compositor by implementing new compositor nodes. I feel this project is well suited to me as I have previous experience with OpenGL and GLSL from personal projects.
I have been poking around with Blender’s source code to figure out the working of it’s compositor. From my reference to Blender’s source code and manual, I have compiled a list of nodes that I think would be a great addition to Blender compositor.
Here is my draft proposal for GSoC 2025. I am still working on writing my Schedule and formatting, but the project details are there. I’d be happy to receive any feedbacks or questions regarding this
Synopsis (verbatim from the proposal)
This project aims to expand Blender’s compositor functionality by implementing new nodes, adding specialized filter nodes (Dither, Halftone and Swirl) and utility nodes (Min/Max and Halation), this project will enhance Blender’s image manipulation capabilities.
Duration of project: 90 - 175 hours
Deliverables
Compositor Filter nodes:
Bayer Dither
Halftone
Halftone Dots
Circular Halftone
Swirl
Utility nodes:
Min/Max node
Halation
Some other ideas (not necesarily part of GSoC)
Implement a feature that allows the user to see CPU compositor output in real-time as it gets processed, while not affecting performance drastically.
Implement more types of noise/grain shaders.
Work on performance of blur node (I am not sure about the implementation for this, but I would like to work on it)
I think the suggested new nodes are interesting, especially the half tone node. However, I think the scope is too large for 90-175 hours. I would suggest to focus on one node with multiple variants, e.g. dots and circular half tone.
Also, don’t forget to include the PRs you submitted in the proposal.
Thank you very much for the review. I’m glad to see that you like my ideas.
I appreciate your feedback regarding the scope of the project, but I believe that the proposed nodes can fit within the 90-175 hour timeframe as I have a detailed plan for the implementation of most nodes already mapped out in my mind. I am confident I can manage the complexity and deliver quality results within the proposed hours.
However, if it could negatively affect the chances of acceptance, I could shorten it.
@thorn-neverwake thanks for advice. Could you please expand a little on why you think the CMYK conversion node could be difficult? Any references you could provide would be really helpful for me to understand the potential challenges better.
There’s not one simple equation for RGB → CMYK. The conversion is both complex and extremely subjective; getting a color match between the two depends on the printing process, ink types, paper composition and coating, apparent brightness, and thickness of the paper.
Yes. You’re absolutely right. From what I’ve studied, it doesn’t seem like CMYK to RGB is even possible, since CMYK represents a bigger color space. My only intention of adding RGB to CMYK conversion node is to give the artists another option to experiment with. Since I discovered that Halftone uses CMYK color space, I thought there might be other image effects someone might want to use, but would need to emulate CMYK color space from RGB. That’s why I have decided to use this formula to provide the artists with a simpler option.
The thing I immediately thought was color profiles. SWOP vs Euro vs Japan vs all the rest of them, including printer-specific profiles. Conversion from RGB can be a complex process, and as it is a destructive result - it needs to be correct.
If it’s not, the user would have been better off rendering RGB and converting in a dedicated image software.
ETA: CMYK is not a larger color space across the spectrum. It’s not even as large as Adobe 1998.
I apologize. I think I have made a huge mistake in my explanation.
I think it got interpreted as introducing a node that would convert RGB colors to CMYK and then displaying those as a proper output.
(I’m not experienced with this topic, so please pardon my limited vocabulary)
But, what I really meant was to create a node that can output separate color masks of each of the C M Y K color channels. (Something like Separate Color node)
For example, if we use this image as input
the RGB to CMYK node’s C output would look something like:
Blender is recently going into the direction of implementing new simple functionality using node groups as opposed to built-in nodes. I am concerned that your proposal can mostly be replicated using simple node groups.
Halation seems to be pretty much what Glare does.
Min/Max already exist in some forms in the Mix Color and Clamp nodes. Maybe the clamp node could be extended to support color as well as an alternative?
Swirl is a specific effect that could be achieved using a node group.
Halftone is a simple effect that can be achieved using node groups.
Bayer Dither I could see as a node that could be implemented as built-in, but it seems too small for a GSoC project as is and it is a bit limited as a node. For instance, I would have expected something like Floyd–Steinberg dithering or one of the noise-based methods.
I would keep in mind that 90 hours is just a little over 2 weeks of full time development, including code review, end user documentation and possible iterations after user feedback
In the previous version of this draft, I did have the Floyd-Steinberg node as part of the dither node. I removed that to keep the project within the time duration of 90-175 hours.
I seem to have miscalculated the size of my project. So, I’m thinking I’ll make 1 Dither node, with an option of Bayer Dither and Floyd Steinberg node.
