New kipi-plugin: Automatically remove red-eyes (in batch mode)

Some years ago, we had an addition to our family and I took a lot of photos in that time. During the months I had taken nearly 2000 images of the newborn, but most of them had red-eyes on it.
This happens quite a lot with little children since their pupils don't close that fast and the light of the camera flash is reflected by the eye.

new batch red eyes removal tool

It always annoyed me to remove the red-eyes by hand, although most image software can do this with a single click in the defective image region. One day I had to correct hundreds of images to
sent them to a printing service, and that was the day I decided that I need something that can remove red-eyes all by itself.

I found the tools I need in the OpenCV image library and trained an eye classifier that works quite well in most situations. I used a predefined classifier before, but it was only trained to
track eyes from a webcamera output, which didn't work that reliable. With the trained classifier, I'm able to find eyes in a photograph and create a mask from those regions that will be used in the final correction process. For the mask creation I use the additional Blob Extraction Library for OpenCV.

The plugin works quite well with high-res images that are not too blurry, so portraits like the one in the screenshot above are good candidates for it.

To use it select the images you want to be corrected and start the plugin. A good practice is to add only images that contain red-eyes, you can for sure add a whole folder and see what will happen, but then most of the time the false-positive rate is too high. The plugin has two modes, a testrun to test the settings for the imageset and the final correction mode, where the images are corrected and saved.

The plugin just made its way into KIPI SVN and will be released with the next version.

This is a great feature. In

This is a great feature. In the example image it looks as if there was an inaccuracy of 1 px though (like a grey afterglow of the red eye). Or am I imagining things?
The other thing is, couldn't you improve the false positives by checking for the color of the retina? (and/or checking the shape?)

I don't see a "afterglow"...

I don't see a "afterglow"... what do you mean by that?

If you zoom in on the example

If you zoom in on the example picture there is a grey circle on the iris which certainly isn't a reflection?

Still don't know what you see

Still don't know what you see here. If you mean the gray "border", this can also be found in the original image. I don't overlay any color nor do I paint something here, the plugin just removes the red by reducing the red channel and mixing it with the green channel...

Sure, that is what I'm

Sure, that is what I'm talking about. In the original, the border is inside the red eye, so I guess it's either from the lense or because of the curvature of the retina, and is actually part of the red eye effect.

Well the plugin isn't

Well the plugin isn't finished, like every piece of software :-)
This is just a first try and by far not perfect, so development goes on. The next steps will be to make the correction faster (if possible) and more reliable. It works quite well though, at least for my image collection :-)
This plugin started out as a fun project and I never thought that it will become serious some day. Now that it is I will check for additional ways to ensure the correct eye detection.
The images are not overwritten with the default settings, but saved in a subfolder. You can also add a custom prefix to the images or, if you are brave, overwrite them.
I tested this plugin with a folder of 120 images, 116 were correctly modified and 4 images where not detected. This is quite good I think.

Andi

Thank you!

Dude, that's brilliant, thinking to use the OpenCV libraries. I can't wait to try it in the next version of KIPI plugins. Even if it is unpolished, I think it's awesome that you're willing to share it with the rest of Digikam users!

How about a way to quickly do comparisons afterwards?

This is a great idea, and just another example of the fast pace of innovation that can be observed in open source software.

A thought on comparisons:
I get that originals are preserved and the modified images are saved in a subfolder. But how do you speed up the inevitable comparisons you have to do later? Ie. how do you enable the user to quickly compare original with modified images and verify that the red eye removal was correct?

I'm thinking that the best way to do that is by being able to browse through the images and see the original and modified side by side.

Alternatively, if the modified images were saved in the same folder, but with a modified filename (ie. "-edited.jpg") it would at least be easy to browse through all images quickly, and flip back and forth between original and modified versions.

With the modified versions saved to a separate subfolder, you'd either have to view all originals or all modifieds...

You can add a prefix to the

You can add a prefix to the modified files if you like, so that you can save the images in the same folder.
There are three types of correction:

1. Save in a subfolder (choose you own name for it)
2. Save with a prefix added (choose your own name for it, filename becomes image01_XXX.jpg for example)
3. Overwrite images (should never be used :-))

You can watch images side by side with digiKam lightTable. If you use another application like gwenview, it will be best to use the second correction mode.

I tested the classifier on another image set and I'm getting disappointed by it :-( I think I need to train another one that works better.
Since the final KIPIplugins release will be in February I guess (KDE 4.2 release), I have some time left.

Andi