Here is a list of all numbers for all Gimp only blend modes so they can be called in GEGL.

In example

47 is the Grain Merge Blend mode.


39 is HSL Color



60 is the Gimp Split Blend mode.



57 is the Color Erase Blend mode.






These operations will not work outside of Gimp but they are very useful for plugin development.


62 is Gimp's replace blend mode that I failed to list. My list ends at 61. lol

Liam's GEGL plugin development guide with extra notes that isn't included on the website, its still 95% similar to the website

PDF documenting the most common reasons why my plugins will break in the future. NOTE ONE OF THEM IS GIMP'S TEAM ADDING A NEW BLEND MODE. This is for future maintainers. I don't expect this to happen anytime soon near future.

Souless Tree already made two node chaining type GEGL plugins but doesn't plan to make anymore. ( I asked him)
https://github.com/soulless-tree/soulless-gegl

BarefootLiam made one that calls the Pango Markup language, this is not a node chaining type plugin like I make.
https://gitlab.com/barefootliam/gegl-pango-markup

I made over 50 GEGL plugins, all of them are based around node chaining, but now as 2023 is in its later parts I have to wonder if the entire year will end with no other third party GEGL devs? Hopefully by the end of the year Gimp 3 is released and someone else considers making a GEGL plugin. I've been begging for this to happen for a long time to no avail.

If I wanted to create a GEGL plugin, where would I find the current guide to setting-up the tools on Windows for compiling the plugin?

Kevin

Install this
https://www.msys2.org/

Use Windows 64 bit and install install GEGL, Meson and Ninja afterward
https://packages.msys2.org/search?q=gegl

If you can compile one of my plugins on Windows with those listed mysys2 tools. You have everything you need to develop a new plugin. So that will be the confirmation test.

I just repeated this process today because my virtual box Windows 7 broke.

Install MySys2

Run the Application MSYS2 MINGW64

Run this command inside MINGW64

This will install EVERYTHING NEEDED

If something unknown happens, it will only allow to compile plugins in this folder.
C:\msys64\home\USERNAME

but in most cases it will compile anything system wide.
Then opening the build_linux.sh files in MySys2 will compile my plugins. If you can compile my plugins you can compile your own.

The entire development of a GEGL plugin was documented in this thread.
viewtopic.php?f=9&t=20579&start=0

It is almost 2024 and I am at the point where I am literally integrating AI in my GEGL plugins and others have yet to make a single GEGL plugin, and based on view counts of threads on Gimp Chat it seems people are far more interested in calling GEGL From python then chaining GEGL nodes inside GEGL composers like I do.

GEGL from python will do interesting things but I beg the community to make a GEGL plugin the way I do. Its hard to believe I am still the only one doing this.

I don't know too much details about actually writing a GEGL plugin but I think the main reason for interest is ease of use.
if GEGL plugin involves having to compile then I think that's why people are hesitant at least it is for me.
I am guessing it's written in C? If so if there's a way to make a plugin in C that accepts dynamic chains in some format that and expose that to Python Fu.
Then Python Fu can call that and it could chain it dynamically then I guess there would be way more interest.
I don't know just my take on it.

I showed a Gimp dev your message and he told me it is possible to pass python stuff to GEGL, but didn't explain how. Remember I make all my GEGL plugins not by "coding in C via knowing the math of pixels" but just chaining GEGL nodes and GEGL composers in a designated area I dub "the playground".

This is "the playground" template where GEGL nodes and GEGL composers are orchestrated. It involves no math or no advance programming skills.

I asked GPT and it said that we can compile the GEGL plugin into an .so file and put that in the plug-in folder
and that once that's successful it's registered in the pdb.
Then python fu can call it.
It's the compiling something in c that is proper format that I am unsure about.
But if that's done. Then it's a matter how we want to design the communication from python fu to that registered pdb call.

wow, the AI was correct on that. MySys2 is how you compile my plugins on Windows. I'm sorry they are much harder on Windows. On Linux they compile so much easier. Also it is likely chatCPT got that information directly from me and my post scattered throughout the internet.

I asked ChatGPT about dynamic c code execution and it said that it's slightly slower due to overhead in having to compile the code at run time. but its advantage is it can be dynamic. That was what I aiming to get at. It mentioned LLVM (Low Level Virtual Machine).
What I really wanted was some way for me to just change code on the fly without having recompile.
So even if a C plugin can accept this dynamic code from python which is also C code then it'll be a good interface for playing more because then Python can be changed without having to recompile that C plugin ever again. But ChatGPT also mentioned about security risks exposed because python can pass bad intent code... well that was expected. But I mean python code can already do harm on its own since it's runs code on your computer. But if python can change what kind of C code it passes into this C plug-in then we have something that's sort of like C scripting since it can be changed without recompiling the C plugin...

Chat GPT Gave me all this just in case anyone wants to venture into compiling a C plug-in that executes dynamic code:
1. Install LLVM:
Ensure that you have LLVM installed on your system. The steps for installation depend on your operating system.

2. Write a C Program:
c
Copy code
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <llvm-c/Core.h>
#include <llvm-c/ExecutionEngine.h>
#include <llvm-c/Target.h>

int main() {
// The C code to execute
const char* cCode = "int add(int a, int b) { return a + b; }";

// Initialize LLVM
LLVMInitializeNativeTarget();
LLVMInitializeNativeAsmPrinter();

// Create an LLVM module and JIT engine
LLVMModuleRef mod = LLVMModuleCreateWithName("dynamic_module");
LLVMExecutionEngineRef engine;

char *error = NULL;
if (LLVMCreateExecutionEngineForModule(&engine, mod, &error) != 0) {
fprintf(stderr, "Could not create execution engine: %s\n", error);
LLVMDisposeMessage(error);
exit(1);
}

// Generate a simple function with the provided C code
LLVMValueRef mainFunc = LLVMParseBitcode(mod, (const uint8_t *)cCode, strlen(cCode), NULL, NULL);

// Execute the function (if it exists)
if (mainFunc != NULL) {
LLVMGenericValueRef result = LLVMRunFunction(engine, mainFunc, 0, NULL);
printf("Result: %lld\n", LLVMGenericValueToInt(result, 0));
} else {
fprintf(stderr, "Failed to parse C code\n");
}

// Clean up LLVM resources
LLVMDisposeModule(mod);
LLVMDisposeExecutionEngine(engine);

return 0;
}
3. Compile and Run:
Compile the program and run it. Ensure that the LLVM libraries are linked during compilation.

bash
Copy code
gcc -o dynamic_execution dynamic_execution.c -lLLVM
./dynamic_execution
This example dynamically executes the C code int add(int a, int b) { return a + b; }. Note that this is a simple example, and you would need more sophisticated error handling and validation for real-world scenarios.

Keep in mind that dynamically executing arbitrary C code poses security risks, and it's crucial to validate and sanitize input thoroughly to prevent code injection attacks. Also, ensure that you have proper error handling in place for various stages of the dynamic code generation and execution process.

Gimp nor GEGL can't read GEGL .c files. Only binaries are accessible. In the future I hope they can read .c files instead of binaries only, as that is the spirit of FOSS

But isn't .GEGL files in c and compired using C? so if you make it dynamic and just include dynamic code as specified then compile it then when it runs it reads the dynamic code? Not sure.

Update:
does C have eval function like python
ChatGPT
No, C does not have an eval function like Python.

In Python, eval() is a built-in function that takes a string and executes it as Python code. This can be very powerful but also potentially dangerous, especially if the input is not sanitized properly, as it allows arbitrary code execution.

C, being a compiled language, doesn't have such an eval function because it doesn't interpret strings as code at runtime like Python does. C code is compiled into machine code before execution, so there's no direct equivalent to eval in C.

However, C can achieve similar functionality using techniques like dynamic loading of shared libraries or embedding interpreters like Lua or Python into C programs. These techniques allow you to execute code dynamically at runtime, but they are more complex and less commonly used than eval in Python. Additionally, they come with their own set of security considerations.

I don't think its possible because Gimp's core libraries for GEGL use binaries too to load native GEGL filters. I sent your message to a gimp dev to see what he says. I too hope in the future it is possible to run GEGL plugins through .c files instead of binaries, as that is more transparent and in the spirit of open source but right now in this part of history it is likely not possible.

In the mean time while we wait for the day that GEGL can read .c files, we should occupy more important things like studying GEGL node chaining in Gimp's GEGL graph and making very simple basic GEGL plugins based on the graphs we find.

said Gimp dev responded

C files do indeed need to be compiled, and a compiler is a major piece of code. There are C interpreters, but they run very slowly (probably between 10 and a thousand times more slowly than compiled C for image processing) and aren't really designed for this sort of use.

GEGL plug-ins are indeed shared libraries (.so files, or .dll) that are loaded dynamically.

So yeah... it looks like it could be done but it would be 10 to 10000 times slower. I don't even know how to do it btw.

Last week I made a new discovery on making GEGL plugins, and apparently someone from GNOME knew this trick back in 2013. Despite any public documentation of it.

I looked at the source code of GEGL's Gaussian Blur filter, something I had done long before.
During my previous look at gegl:gaussian-blur 's code I knew it was based on two gegl:gblur-1d being set horizontal and vertical. The stuff about gaussian blur is irrelevant to my discovery.

However just a few weeks ago I realized the nodes in the .c file were only listed once instead of twice. I didn't know this was possible. So in my latest filter that applies on a layer mask. I took note of gaussian-blur's .c file and made it where the code in my new filter only list nodes once instead of twice.

Example of required GEGL nodes being listed once (new discovery)



Example of GEGL nodes being listed twice. (The way I've been doing things)




What is the major difference?


is put in front of every filter instead of a list like


This means it is EVEN EASIER to make a GEGL plugin.