Commons Machinery will be out in force at Libre Graphics Meeting in Leipzig next week. Grab us if you want to talk about metadata or sit down to hack stuff! We’ll also be presenting three sessions:
- April 2, 15:10: Jonas presents Commons Machinery and why it is important to retain the context of images and other works to be able to better relate to them.
- April 2, 15:30; Artem describes our experimental work in GIMP to handle metadata when creating and merging layers, and introduces librecontext which aims to simplify this for tool developers.
- April 4, 12:10: Peter and Artem host a BoF on the future of metadata in libre graphics tools.
The BoF will be an open discussion about why libre graphics tools should be good at managing the context of works, how it should be done, and the aim to come up with concrete improvements that should be done. If you care about making your projects and tools more useful for creators, you should come to this session!
As a starting point for the discussion we have reviewed the current support for context metadata – authors, artists, contributors, licenses, times, locations, etc – in some of the projects present at Libre Graphics Meeting. This is not an exhaustive list and may be missing some work in progress, so please tell us about stuff we’ve missed.
GNOME image viewer (eog)
eog can show full metadata in Image -> Properties, but is is lost if the image is manipulated (e.g. rotated) and then saved. JPG files only keeps the EXIF data and PNG files loses all metadata. (Tested with version 3.8.2.)
Much improved metadata support was added in the development version of GIMP in October 2013. This is based on gexiv2, a glib wrapper around libexiv2. A metadata dialog include separate tabs for EXIF, XMP and IPTC metadata, and the IPTC values are editable. This is metadata for the image as a whole, there’s no metadata on individual layers.
The discussion about this development here concluded that GIMP shouldn’t be a general purpose metadata editor, as there are other tools for that. General XMP editing is complex, so that could well be an area for a separate tool, preferably one that could be run as a plugin inside GIMP.
Testing with an IPTC reference image shows that all the metadata is visible in the dialog, but when exporting only the EXIF and IPTC sections are written to the file. The XMP packet isn’t written at all, despite ticking that checkbox. (Tested version 184.108.40.206)
In contrast to GIMP, Krita keeps track of metadata for each layer, but not the image as a whole. Unfortunately, flatting layers drops all the metadata for the affected layers, including the target layer, so it would be very easy to lose metadata while working on an image.
When exporting a file containing metadata Krita behaves similar to GIMP 2.9 above: only EXIF and IPTC chunkas are stored for JPG and PNG, while for TIFF only EXIF data is retained. (Tested version 2.8.0)
A number of ideas for a rewritten metadata handling, focusing on XMP, was written in 2010 for “Krita 2”, but no work seems to have been done yet.
MyPaint does not support metadata at all, as there are no dialogs for it and exporting strips any metadata present in the loaded image. (Tested version 1.1.0)
Inkscape uses SVG (with some extensions) as its file format. SVG has a very flexible support for metadata as any object can have RDF/XML metadata attached. The standard doesn’t specify any details on how that should be used, though, so it would be really worthwhile to discuss what should be best practice.
Meanwhile, Inkscape supports metadata only on the document level, and does not export any of it to PNG. Inkscape is also very particular about how the RDF properties should be structured, so it can only reliably handle metadata written by Inkscape itself. (Tested version 0.48)
Commons Machinery has done some experimental patches to keep track of metadata for parts of an image; you can find them here.
OpenOffice and LibreOffice
The ODF file format has a very powerful support for RDF, with quite tight semantics on how to associate metadata with objects in the documents. The support for this in OpenOffice and LibreOffice is limited to Writer for now, and only a subset of the objects that the format allow to have metadata. How this works, and a plugin from Commons Machinery that make us of this to automatically keep track of credits, are described and demoed in this blog post and film.
Video editors: Pitivi and Kdenlive
Video editors should have a large need for handling metadata to keep track of the credits for all the clips, images and sounds that go into nontrivial projects. But Pitivi only supports title, author and year for the project, while Kdenlive has general key-value pairs on the project as a whole. “Metadata” in these tools tend to refer only to technical metadata such as framerates.
What ends up in the file that Kdenlive renders depends on the file format. OGG Theora seems to be the best of the available options as it retains all the key-value pairs, while in other formats just the title or perhaps the copyright is included.
The architecture of the GNU Mediagoblin media publishing platform will allow it to understand and display any kind of metadata embedded into the files uploaded to it, as long as plugins are developed to do it. This is yet to happen, but the PD4PD project at the end of this page could improve matters.
Commons Machinery has also implemented an experimental plugin for SVG files produced by Inkscape
This is a new project that aims to help sharing and collaborating on creative projects, with an initial focus on SVGs produced with Inkscape. This is a young project, but that means its an excellent time to think about how to keep track of the context metadata that could be collected by the platform during the collaborative process and how to use that when publishing works.