Registered Member
|
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 |
Registered Member
|
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). |
Registered Member
|
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. |
Registered Member
|
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!
|
Registered Member
|
I made a post on GEGL to take advice:
http://www.mail-archive.com/gegl-developer@lists.xcf.berkeley.edu/msg00746.html They say they will address speed issues. |
Registered users: Bing [Bot], Google [Bot], Yahoo [Bot]