Studying Digikam color and light tools


Digikam offers great integrated tools for easy correction of photos. Maybe we should study the interface of these tools:

The manual:

Section 2.3.4 teaches color correction:

The section explains how to read color curves. Color curves show the distribution of RGB colors. When flat colors are well distributed and the photo is well exposed. When over-exposed, the curves have a right distribution.

Section 3.2 photo workflow
1. Exposure: White Balance
2. Color: White Balance
3. Black and white points: White Balance or Adjust Levels
4. Contrast: Adjust Curves
5. Saturation: White Balance or Vivid or Hue/Saturation/Lightness
6. Resizing (interpolation) : Change Size
7. Sharpening

The process is the same for video adjustment.

Also digikam uses liblensfun, a library to correct lens errors. I don't know how it implemented in the interface, but many cameras suffer from lens distrotion. The interface seems to be described in Perspective Adjustment, section

All that needs to be implemented at MLT level. GEGL could provide the underlying treatment for MLT. I had a look at digikam SVN. It seems very actively developped and very well organized in code. I will ask advide to digikam developers and will get back with the URL of the discussion.

Here is my post on digikam ML. You can follow discussions:

It seems reasonable to believe that we could use some of Digikam dialogs and that we may link MLT to Digikam too. This is only a first approach. All this needs to be studied in details.

Gilles Caulier pointed out the existence of a common image editor and processing tool called "showfoto", which is also available as an executable and shared lib.

It is part of Debian. I installed showfoto and it completely rocks. The tool was designed for easy use and with professional options. Everything is at hand. I will make a screencast tomorrow.

It would be a complete loss of time to re-invent the wheel and work out of this project. At least for the UI.

The difficulty comes from the large number of bindings for showfoto. It really offers everything, including lens correction! So of course, there are many bindings.

I proposed Gilles Gaullier that he could use MLT as an image processing program. This would allow to store images using two PNG layers: the source, the MLT code used to process the image and the target modified image.

Too much for my head.

If you can have a look at showfoto (it is in Debian) and tell me your impressions, it would be a good start.

The frei0r balanc0r filter that I made uses Digikam's code. Yes, showfoto looks nice, but I have think more about how we might collaborate with this project.

I made post today on Frei0r ML to introduce showfoto.

IMHO, showfoto could use MLT to process layers and effects,
given that showfoto effects are ported to Frei0r.

A little bit complicated, but this would completely rock.

IMHO, digikam developpers are open to anything interesting.

Digikam leader is Kdenlive former leader.
Just for the info!

Why would showfoto use MLT? The former Kdenlive leader is Jason Wood. Gilles was a contributor.

This was jus a guess that Showfoto could use MLT to process photos. The MLT code would be kept in metatags of each photo. This would allow to keep the original photo untouched. The photos would be processed only during export. Just like in video editing. There was no reply to this idea.

Original : JPEG photo (stays unmodified)
Color and light grading : MLT processing code stored in meta tags
Exported as : Modified photo


I tried Showfoto and his color correction tools... and I think that Kdenlive absolutely need these tools to attract professionals!
They will answer most needs in television production.

You should just add a osciloscope / vectorscope in addition of the histogram in order to not too upset habits of video editors.

I will talk with various video editors to know what they think about these tools ...

Best regards

I also opened a discussion of FFmpeg devel to ask their plans about libavfilter. They started a new Google summer of code project arount libavfilter. They plan to add mplayer and Gimp plugins support. It seems that only a few files need modification:

FFmpeg will accept patches and include them in the new libavfilter code base. I have no idea when the new livavfilter code will be available.

On my side, I would prefer to use showfoto code, because it is developed with the idea of professional photography and we may share a single code base. It works well, it is fast and well maintained. If MLT can have a showfoto plugin, it could be the easiest solution.

So to my point of view, it look like:
* Base libraries:
** Option 1: FFmpeg libavfilter (port mplayer and Gimp plugins) + MLT
** Option 2: showfoto library + MLT.
* User interface : Showfoto.

This is probably something that needs to be studied in details.

this is defiantly an essential element if kdenlive is going to be taken seriously. my two cents is that we will need to be able to add bars in preferable from a drop down list. these of cause need to be correct for the medium PAL/NTSC/HD ect.

I haven't had a chance to test the above mentioned software but you back and whites need to be maintained. the color curves must not crush your deep blacks or bright whites or we will have probles lifting dark scenes extra.

limiters, as a second filter, to cut excess blacks and whites, TV safe in other words.

if this works correctly we should be able to do a pull in of video or tiff (DPX if that not aking to much) and export with out loosing color space especially in the highs and lows.

thanks to everyone.


I'm just bumping up this thread to know if there has been any news on the ffmpeg side, or any progress in the integration of advanced color correction tools in Kdenlive.

Advanced color correction is to my mind one of the most needed features to make Kdenlive competitive with apps such as Vegas Studio or Premiere Elements, which I consider to be in the same league as Kdenlive. (Well, that and keyframable effects, but one thing at a time ;)

No, there is no progress, and I do not expect it for a long time because we have too many bugs and simpler improvements to work on.