Call to integrate GEGL library as an MLT plugin

Dear Friends,

GEGL is an image processing library derived from Gimp work. The code was moved from Gimp to a library. It is heavily developed and well maintained. The library is on MLT to-do list and I just discovered it.

It offers the following features:
http://gegl.org/operations.html#cat_render

The important aspects:
* Color management:
color-temperature
cg2 (conversion to b&w)
grey
gamma
levels
monochrome mixer
remap
tonemap
whitebalance

* Light:
brightness-contrast
contrast-curve
darken
difference
hard-light
lighten
soft-light
stretch-contrast
threshold

* Effects:
box blur
gaussian blur
motion blur
dropshadow
fractal-explorer
invert
reflect
rotate
invert

The library also provides layers and processing graphs but I don't know wether this is of interest, as it is a core MLT feature.
I am mainly interested by colour and light management. Basically, it should offer the same features as basic Gimp light and colour setup. The effects are less interesting as some of them are available in Frei0r.

GEGL is able to degrate quality for fast processing during preview. It also offers a buffer. But I don't know how fast it is in the real world.

An example of integration in MLT is the frei0r plugins, which is only a few pages of code.
On Kdenlive side, the base mecanism to make dialogs exists and there is no real coding needed.

What is your opinion about GEGL? Do you think we should implement it in MLT? Who is interested to implement GEGL asap in MLT? For information, I am interested, but I am a poor coder and this will improve my skills. But if you are a brilliant coder, this could take only a few hours or days.

Kind regards,
Jean-Michel

Sorry, an answer was given by Dan on the ML. So I paste his reply to avoid double-posting:

**************************************************************

Well, I think you are understating the importance of UI in all of
this. Even the UI we have for existing effects needs more work not to
mention general keyframing support and the UI that will require. (I
mean, what is the deal with that little red rectangle widget? Why not
have a rectangle widget atop the preview monitor?)
Color correction requires a unique UI - something the simple, generic
UI for effect parameters does not provide. Furthermore, whoever takes
up the challenge of better color correction needs to do the research
to understand what exactly is required - both on the UI and the
processing. Even I do not know. I am skeptical that it can be learned
from user documentation and screencasts alone.
The value of GIMP (and GIMP Animation Package) is the UI it provides
in addition to the image processing routines because there are many
libraries and subroutines are easy to interface with MLT or frei0r. At
least with more streamline export along with proxy-edit or clip
substitution, then people can use the GIMP UI until MLT and Kdenlive
develop further. After all, there is still much work to stabilize and
address bugs. Same goes for audio, Jack, and Jack apps. Ultimately, it
better to not have multiple canvases and timelines, but where better
interoperability is "low-hanging fruit," we should pick it!

I do not want to discourage any would
be contributor that has an itch to scratch. I do not know the details
of a good way to integrate GEGL. I would suggest to a developer that
they take a look at the MLT frei0r filter and try to adapt it to GEGL
libs (or some higher-level lib that defines a set of GEGL operations).

I agree that a new dialog is needed in Kdenlive.
But first we need the "core" features to build the dialog on, like color grading and light.

I am not interested in the layer aspect of GEGL as this core feature is provided by MLT.
I am only interested in using Gimp original code provided in a library to correct colour and luminosity.

Correct me if I am wrong!

Okay, we could export to Gimp, but this would be a step backward in kind of interaction. Of course, for high-end users, it would be great. But not for the basic user.

IMHO, very active projects in the domain of image processing are quite "rare". If you take the example of Frei0r, although there are some discussions on the mailing list, the guys seem very offuscated when you point out a bug. Frei0r still does not compile on PPC and this does not seem to hurt much Frei0r maintainers who always run out of time.

So for all these reasons, relying more on GEGL would be great. This is core access to basic Gimp code. As such, it would be an error not to use it. I am sure that every bug discovered will get fixed ASAP and if we ask features, we will get them. It seems to be a complete different relationship.

To add to this, GEGL is designed to operate in different color spaces and depths. MLT supports both Y'PbPr and RGB at the moment and converts when needed, which causes degradation in performance and slightly in quality. Nearly all MLT native filters are in Y'PbPr whereas the frei0r effects are only RGB. So, it is also compelling to use GEGL to reduce the number of conversions. On that note, last I heard, GEGL is fairly slow with little attention paid yet to performance. One should compare with gavl, which also supports multiple color spaces, but with an emphasis on speed as well. However, maybe gavl has less interesting color and light filters. I dunno - only so much time for research!