Leading items

DigiKam 4.0 highlights

The open source photo-management program digiKam is expected to reach its 4.0 release shortly, incorporating a number of updates and new features since our last look in January 2013. The updates improve on digiKam's core functionality: its ability to help the user track and sort a large library of photos. At times, improving organizational features can sound like a ho-hum task, but in the big picture, those features are what digiKam users rely on the most.

The series that will become version 4.0 is currently at its fourth beta release, which is provided as source packages from the KDE repository; unofficial builds, though, are frequently available for Linux, contributed by volunteers in various distribution communities.

Background elements

DigiKam point releases are a regular affair; since our 2013 look at version 3.0, there have been three intermediate updates that introduced either new features or important structural changes (in addition to several bugfix-only updates). The first was 3.2 in May, which added the ability to search for files or filter content based on aspect ratio, and which introduced a new list-based album display mode. The aspect-ratio searchability is arguably more relevant to searching for videos than it is for still images (where cropping is far more common that in is for videos), although for users with multiple camera formats, it can be useful in a pinch to restrict searches to one camera type or another.

The list display mode is considerably more important; without it, the only presentation mode for a folder of images is the familiar grid-of-image-thumbnails found in all image managers—which, while visually appealing, does not scale particularly well to thousands (or even hundreds) of images. The list view presents a file-manager-like list with columns not just for file-system properties, but image metadata as well. This lets one sift a collection more efficiently and is a welcome change.

The 3.3 release in August did not add user-visible changes, but it did debut a rewritten core for the face-management engine that powers the facial-recognition and face-based searching features. Face recognition is a sometimes controversial subject; many people react defensively to it when it comes up in the context of web-based services (for understandable privacy reasons) or government surveillance (for even more understandable reasons), but support for it in desktop software is a different animal. In one's own collection of images, it can simplify searching significantly, since "find person X" is a far more common task than "find images from some particular date" in the real world. There is, of course, a gray area in between, such as where interoperability with online services is concerned. DigiKam can import facial-recognition tags from Picasa (Google's photo service), for example; in the long run, making the feature useful but not worrisome is a balancing act.

Finally, version 3.4, from September 2013, introduced a new core for digiKam's fundamental collection-management routines. Specifically, the new core is designed to better take advantage of multi-threading on modern multi-core hardware. Here again, the main benefits go to users with larger collections, for whom searches take the most time (and who, naturally, are the users most in need of powerful search functionality). But few if any users have shrinking image collections; anyone with a modest image library today is merely a few steps away from having a large and unwieldy library tomorrow.

Foreground

The first beta for digiKam 4.0 appeared in December 2013, with subsequent beta releases appearing every three weeks or so. The main focus for this series has been merging in the work from digiKam's 2013 Google Summer of Code (GSoC) student projects. Several of these projects dealt with feature implementation, but several others were architectural projects paving the way for the project's transition from Qt4 to Qt5.

One of the biggest new feature additions is a tag-hierarchy organizer called Tags Manager. This is a utility that helps the user manage the assorted tags applied to images; while at first glance it might seem as though "a tool to manage the way you use a tool to manage your images" is too abstract for its own good, in practical usage it has definite merits. "Tags" too often means "unstructured series of text labels"—one can tag a photo with all sorts of metadata, particularly when trying to describe the content and significance of the image. As is the case with other photo-management features, taking the naive approach does not scale; at least with digiKam's Tags Manager, users can sort and rearrange their tags, even long after they were originally created.

That means that users can look at their tag collection, edit and rename tags, find related and complementary tags, and group tags together in a hierarchy—and perhaps most importantly, they can do so without trying to wrangle their image library at the same time. Mental work is still required of the user to find some order in the chaos, but separating the tags from the photos helps. Tags Manager uses the Nepomuk semantic organizer library from KDE, whose ontology is already used in a number of other projects like GNOME's Zeitgeist.

A related feature still in development as of beta four is an automatic tagger that tries to guess what tags the user would want to assign by looking at similar images; if it makes it into the final release it will be interesting to try. There are also several smaller improvements to image management, such as the ability to select and drag-and-drop multiple items in the Tags view, and support for saving face-detection rectangles in the right format for export to Microsoft's Windows Live photo gallery.

Under the hood, some digiKam components were refactored into Qt's model-view architecture, which will simplify eventually transitioning the GUI to Qt5. The final piece was the built-in image editor, which still used some old Qt3 components. There is not a date set (yet) for the Qt5 porting effort; the beta four release notes indicate that the project is waiting for KDE to stabilize parts of its API first.

The release notes also point out several smaller enhancements that users will be grateful to see. For example, the photo import tool used to indicate when image files on a connected device had already been imported in a previous session, but that feature broke several releases ago; it has now been restored to working order.

All in all, digiKam 4.0 is shaping up to be another solid release. There may not be much in the way of flashy features this time around, but the better organizational tools are a valuable addition—even if they remain unsung heroes. It is comparatively easy to attract eyeballs when advertising exotic new image effects, but in the long run, what makes digiKam a useful tool is how it enables users to keep track of their ever-increasing assortment of digital photos. As is the case with rewriting core components to prepare for Qt5, building a solid base for managing images is what users really need from digiKam, even if that work can seem mundane at first glance.

Comments (2 posted)

New projects at Libre Graphics Meeting 2014

Libre Graphics Meeting 2014 kicked off in Leipzig, Germany on April 2. Now in its ninth year, the annual conference and workshop attracts developers from virtually every major open source creative graphics project. The list of participating teams is an ever-growing one, and the first day of LGM 2014 included the announcement of several new projects, in addition to some interesting commentary about the future of some well-known open source projects.

In fact, the number of participating projects has become so large that this year's first session was dedicated to a "what's new" overview of the recent work in many of the mainstream, established projects (GIMP, Inkscape, Blender, Scribus, and so on). The purpose, of course, was to free up some additional session slots for more in-depth topics and less familiar projects that might require more introduction. Øyvind "Pippin" Kolås from GIMP and GEGL acted as emcee for the overview.

The fresh

In addition to the "regulars," four new projects were presented on the first day of the event. The first was Roman Telezhinsky's Valentina, a cross-platform pattern-design application. As Telezhinsky explained, Valentina allows users to design and adjust garment patterns based on parametric measurements of the wearer. Such measurements (limb and torso length, various widths, etc.) are simple and linear, but adapting them into the un-folded and un-cut pattern segments that need to be made in actual cloth requires a fair amount of math. There is very little open source software that addresses pattern-making, so Telezhinsky had to define his own file format, but he is hopeful that the application and the ability to easily share patterns will be valuable to the design community.

Jonas Öberg and Artem Popov spoke about another new effort, Commons Machinery, which is writing tools to preserve and propagate attribution metadata in digital files. Primarily, this attribution metadata refers to the original creator(s) of an image file and perhaps when and where it was created or published. The current lack of a way to preserve this information, they said, is what leads to the proliferation of vague attribution notices like "Photo from Wikipedia"—a statement that, while true, does not help the reader find the original. The project's first work has been extensions for GIMP, LibreOffice, and Firefox that preserve attribution information in RDFa format, but there is more substantial work still to come, such as a distributed attribution database that will soon go online at Elog.io. There is still more to do, they said, but their code can already handle some complex scenarios, like merging the metadata of multiple files that are combined into a single image.

A surprise on the schedule was the announcement of the Document Liberation Project, a spin-off of the LibreOffice project's file format reverse-engineering and conversion work into a standalone project. Team members Fridrich Strba and Valek Filippov had presented their work at LGM 2013, but at that time it was formally tied to LibreOffice. By making it a standalone project (though still one under the governance of The Document Foundation), Strba said, it would be easier to get developers to contribute code without feeling like they were defecting to LibreOffice. The move also acknowledges the reality that many other applications already use conversion libraries created by the team, and it will allow the team to focus more fully on building good cross-application code. In addition to the announcement, Filippov provided an overview of recent work by himself and the third co-presenter David Tardon, such as support for the Adobe Pagemaker and Apple Keynote file formats and improved reverse-engineering tools like a binary diff viewer.

The last new project on the schedule was Lasse Fister's Multitoner, a GTK+ application for working with multi-tone images. The most familiar multi-tone images are duotones, but the general term encompasses tri-tone and quad-tone images, too. All of these images are ways of reproducing a grayscale image with multiple colors of ink mapped to different portions of the black-to-white gamut—in a sense, an extension of the "sepia tone" effect. The difference, naturally, is how many colors are used. Although popular in Adobe Photoshop, there has never been a free software multi-tone tool before, so Fister reverse engineered the Encapsulated PostScript (EPS) files produced by Photoshop and wrote his own. He is in the midst of preparing a printed book of multi-toned photographs with the results.

First appearances

In addition to the four projects discussed above, all of which were launched over the past year or so, there were several other projects that, while a bit older, were presented at LGM for the very first time this year. Dialogue Maps, for example, is the product of a university research project to create interactive visualization diagrams. Presenters Arno Sagawe, Rüdiger Heins, and Janis Bullert compared Dialogue Maps to the familiar Sozi presentation tool, although it incorporates organizational ideas akin to other topics like mind-mapping as well.

Christian Stussak presented SURFER, a real-time ray-tracing application tailored for algebraic surfaces. SURFER was originally intended as an educational tool—hence the focus on mathematical objects rather than general-purpose rendering—but Stussak said that artists soon began designing purely aesthetic creations as well. In an interesting bit of history, he also noted that SURFER was inspired by the mathematical designs that used to accompany SUSE Linux releases; those forms were created with an older open source program that has long since fallen out of maintenance, which provided a good excuse to create SURFER.

David Tschumperlé, Patrick David, and Jérome Boulanger presented a talk about G'MIC, the image-filtering framework most often seen as a GIMP plugin. But there are other ways to use G'MIC's vast collection of image filters, they said, including a C++ library, a command-line tool that functions similar to ImageMagick, and the newest addition, an online editor. They demonstrated several impressive G'MIC filters, including several that were developed as part of the project's intentional effort to work with artists to build real-world tools. Examples of that included a collection of several hundred analog film-simulations developed by David (a professional photographer), and a colorizing filter developed for comic book work in conjunction with Krita's Timothée Giet and David Revoy.

The Magic Lantern project, which creates open source replacement firmware images for Canon digital cameras, was introduced in a talk by Michael Zöller and Alex Dumitrache. Zöller provided an overview of the project and its history, including how volunteers start and maintain each individual camera port—using a model similar to the one used by the mobile phone jailbreaking community. Dumitrache then explained in more detail the process that led to the widely reported dual-ISO shooting feature in mid-2013. Although the initial goal was to figure out a peculiar quirk he encountered with still images, debugging that quirk led to the discovery of the dual-ISO capabilities of the hardware, which ultimately opened the door to other new features like recording uncompressed raw video at HD resolution at high frame-rates. Those features make Magic Lantern significantly more powerful than the stock firmware from Canon, and competitive with professional products like Red Digital Cinema cameras.

Last but certainly not least among the newcomers was Entangle, the tethered camera control application written by Daniel Berrangé. First, Berrangé explained the background of the project, which initially aimed to reproduce the feature of proprietary software from Nikon and Canon that lets users focus and shoot their cameras from a computer connected via USB cable. That sort of functionality is useful in a lot of situations, he said, such as macro photography (where the camera LCD screen is too small to assist in fine-tuning) and astrophotography (where the camera can be attached to a telescope in physically inconvenient orientations). As one might expect, however, there have since been other uses found, such as stop-motion animation. Berrangé noted that stop-motion animators had been a valuable resource and had provided lots of new feature ideas and feedback.

There are still three more days to go in LGM 2014, so there may be many other new projects making their debut over the course of the week. That can make for a lot of new information to take in, but it certainly bodes well for the state of free software graphics.

[The author would like to thank Libre Graphics Meeting for assistance to travel to Leipzig for LGM 2014.]

Comments (1 posted)

The most powerful contributor agreement

James Bottomley is perhaps best known as the maintainer of the SCSI subsystem in the kernel. But, he said in his 2014 Linux Foundation Collaboration Summit talk, like most free software developers he tends to run across licensing issues frequently. Developers often respond by becoming armchair lawyers, and, by his own admission, James is no exception: armchair lawyering on the topic of contributor agreements was just what he was offering to his audience — though the presence of Linux Foundation attorney Karen Copenhaver, who is well versed in these topics, in the first row of the audience presumably served to keep him from going too far off track.

There are, he said, three important components to any contributor agreement: an assertion that the contributor has the right to contribute the code, a statement of actual contribution, and consent that the code may be distributed under the project's licenses. Not all contributor agreements have all three parts, James said, but they really should.

All projects should have some sort of contributor agreement. Outsiders looking at the free software world often see something that looks like a free-for-all, with code flying in all directions and little attention to legal details. But the potential for trouble is always there, and projects need to protect themselves. Every project, he said, should be able to prove that every line of code it distributes was intentionally contributed. A project can't just pick up patches off the street and hope that all will be well; if the code was not overtly contributed, the author could always try to revoke the project's right to the code, leading to trouble.

So, James said, every project needs a contributor agreement, but does that agreement need to take the form of a contributor license agreement? The agreements developed by Project Harmony did take this form, but if the project distributes code under the same license that covers incoming code, there is no need for a separate license agreement. Indeed, having contributor agreements be licenses can add a significant amount of complexity. A license must be signed, and it has to be carefully reviewed to be sure it does not conflict with the project's license. But, most importantly, any contributor agreement must preserve equity between all project participants, and complex agreements may not do that.

Equity is one of the fundamental principles of the free software community, he said; it is important that everybody meets on an equal basis. But, when company lawyers sit down to write a contributor agreement, they will naturally write that agreement to favor their employers; that is just part of what lawyers do. The result is inequity, and that destroys communities. This has been seen so often that many developers will now refuse to sign inequitable contributor agreements on principle. According to James, that is now happening with the Openstack project; many developers who have been told to work on Openstack by their employers have refused to sign the associated agreement. As a result, they are unable to contribute patches and are restricted to doing associated community work within the project.

Some companies will argue that a complex contributor agreement is necessary to give the project legal protection. But it is worthwhile to think about what a contributor agreement needs to protect a project from. One potential problem is revocation, where the owner of some code attempts to back out of a contribution or claim that the code was never contributed. Another threat is a bad actor trying to push problematic code into a project; a patent troll trying to get a project to distribute encumbered code that it could sue over later would be an example. There are also occasional problems when a good actor accidentally contributes bad code. The important thing to bear in mind, James said, is that a complex contributor agreement cannot protect a project from any of these threats. It might give the right to sue a bad actor, but, by then, the damage to the project has already been done.

The only real protection a project can have from these threats, he said, is not a license agreement with contributors. It is, instead, the ability to track code contributions and to remove bad code from the project once its nature is known.

There are other problems with license agreements. You have to keep them somewhere; the Free Software Foundation, for example, has a room full of file cabinets holding signed agreements. There has to be a mechanism for enforcing the contributor agreement rule; before accepting a patch, maintainers must be able to verify that an agreement has been signed. The need for a signed agreement makes contribution especially hard for "drive-by coders," who, James said, are the source of many interesting contributions to many projects. He cited some work he contributed to Android; he had one specific itch to scratch, contributed three patches, then moved on. That contribution would have been painful if he had needed to sign a real contributor license agreement; in many cases, developers just don't bother.

Finally, more complex agreements are more likely to run into a veto from corporate legal departments. And, James pointed out, for most of us who are employed, our employers own the code we write and must sign the agreement before we can contribute that code.

If a project needs a contributor agreement, but a complex contributor license agreement is not suitable, what should a project use? The key point of James's talk is that the kernel project found the correct answer to this question nearly ten years ago in the form of the developer's certificate of origin (DCO). It is a simple certification — the entire text fits (legibly) onto a single slide. The DCO, when combined with a strong source code management system and proper procedures, is all that is needed.

The DCO contains the three elements described by James at the beginning of the talk: the assertion of the right to contribute the code, the contribution itself, and the agreement to the project's license. Developers indicate their acceptance of the DCO with the Signed-off-by tag attached to every patch merged into the kernel. Every developer who handles a patch up to the point that it gets into the git system will attach a Signed-off-by tag, providing a clear trace of the path by which the patch got into the kernel. Should some code turn out to be problematic, it is trivial to find out which patch added it, determine who contributed it, and remove it from the kernel.

Agreement to the DCO is thus transmitted with each patch. There is no need for filing cabinets or complicated verification mechanisms. Patches can be left in bug trackers or transmitted by whatever means works, and the agreement travels with it. The DCO also, by design, does not specify a license; instead, patches are contributed under the license that applies to the file(s) being modified.

In short, James concluded, the DCO offers everything that a project needs for a contributor agreement. He has not yet seen any other agreement that comes close to the power of the DCO. A number of other projects have started using it, but James would clearly like to see that list grow. The more projects that use this agreement, the easier it will be for developers to contribute code to projects on an equal basis without the need for undue paperwork.

[ Your editor would like to thank the Linux Foundation for sponsoring his travel to the Collaboration Summit. ]

Comments (21 posted)