G'Mic compatibility in the compositor
G'Mic website: gmic.eu/
There is likely a reason that this has never been suggested before, but the implementation of G’Mic for the compositor would be an absolute game changer; we’d have access to more accurate and flexible versions of inpaint, a massive increase in artistic filters, a possible cheapish form up upscaling content (even if most options aren’t DLSS or even FSR quality), so on. And (I might be wrong on this) it’d give programmers a chance to program post-processing effects directly since it’s a framework and not it’s own individual software.
I’m not 100% sure on the legal front of things, I’ve never been amazing with license and stuff admittedly but I’m fairly sure the license it’s under (CeCILL) is relatively like GNU except more french from a quick google, but again, I’m ultimately unsure. I know there have been a few attempts at G’Mic compatibility add-ons, but all the attempts I found are Linux based and dead.
1 Comment
License is compatible, but usecase doesn't match. Compositing isn't the same as image processing. As it is a framework it requires to replace Blenders' internal compositor. On first glance from user side you can expect why not. But that would lead to reimplemention missing nodes, and not the freedom to add new compositor workflows like the real-time compositor, cryptomatte, OIDN.
If image processing is your goal I would rather use one of the image processing applications out their that already uses this framework. If compositing is your goal I would rather stick to a compositor framework that would allow real-time workflows. For compositing performance is a big differntiator. How does this framework compare to compositing performance wise?