Gallery Server has long been able to pull metadata out of photos and videos. And since 3.0 was released in 2013, you’ve been able to modify that metadata in your gallery. What’s been missing, however, is the ability to push those changes back to the original file. Gallery Server 4.0 now adds this support. It is available in all editions except for Gallery Server Free.
Why do you care?
Because you don’t want to lose your investment of time. Let’s be honest here. You may be using Galley Server today, but what about in 10 years? 50 years? You — or your children/coworkers — may have moved on to something else. By preserving metadata changes in the original file, that data becomes permanently embedded where it belongs — with the file, not in some third party database. That information can then be accessed by any software capable of reading metadata.
For example, let’s say you run a gallery with historical photos of your town. You use Gallery Server 4 to tag them and add titles and captions. When metadata writing is enabled, photos downloaded from your website will have that information built into them. And any software will be able to read that information, even though it is no longer part of the original Gallery Server gallery.
The importance of this cannot be understated. Embedded metadata stays with the file and travels with it. It lives beyond the file’s existence in a Gallery Server gallery. It can be read by other popular software, including Adobe Lightroom, Picasa, Windows Photo Gallery and others. In other words, you’re maintaining your images, not your Gallery Server gallery.
Enabling metadata writing
Gallery Server 4 gives you the option of writing the most common meta properties back to the original file. By default, this feature is enabled in new installations. When upgrading, you must explicitly enable it. You can adjust the settings on the Metadata page. Here we enable writing for titles, captions, tags, and ratings.
Notice some properties are not writable (these are the ones having a circle with a line through it). These are properties that typically either don’t have standardized meta locations or the .NET Framework does not support writing to. Here is the full list of properties that Gallery Server 4 can write to:
Currently metadata writing is supported only in JPG and JPEG files. Expect broader support — meaning more properties and more file formats — in subsequent releases.
Once a property has been made writable, any changes to that property are persisted in both the database and the original media file. The user interface doesn’t look any different — it’s all happening under the hood. But when you look at that file’s metadata with another program, you’ll see your changes. In the photograph of my grandparents’ wedding day shown at the beginning of this post, I updated three properties — title, caption, and tags. When you look at the properties in File Explorer on Windows 10, you see the new values:
Notice that the title we entered (Alfred and Wilma Martin) is written to both the title and subject properties and that there is no property named caption. Instead, the “caption” we wrote is shown as a comment. This is due to the unique nature of how properties are embedded in a file and how applications abstract that when they display it. Later on in this post I’ll talk more about this.
For a more under the hood look, a tool like ExifToolGUI shows a (mostly) unfiltered look at a file’s properties:
Batch metadata writing
Many of you have been editing titles, captions, tags and more long before 4.0 came out. We wanted to give you a way to push those edits into the file, so we came up with the batch metadata writer. You’ll find it on the Metadata page:
Each property has its own metadata writer button. When you click it, the gallery updates the metadata item in each media asset file with the property stored in the gallery’s database.
You can also use the batch metadata writer to push properties into optimized images created by the gallery. For example, Gallery Server lets you delete the original, high resolution version of a media asset as a way to free up disk space. In 3.x, you accessed this function by choosing ‘delete original files’ from the Actions menu. In 4.X, it’s in the ribbon toolbar:
While this can save a lot of disk space, the original file is deleted, along with the metadata it contained. However, since the metadata was previously extracted from the file and stored in the database, you can now push that data into the web-optimized file still in the gallery.
The metadata batch writer is available in Enterprise and higher editions.
A word of caution
It is obvious that writing metadata to your original media file permanently modifies the file. Less obvious is that doing so sometimes causes the image itself to be re-encoded and compressed, resulting in a slight loss of quality. This is an unfortunate side effect of the internal details of how metadata is stored. When a data value doesn’t fit inside the existing metadata space, Gallery Server must re-encode the image with additional padding to make room for the data. When this occurs, the image is encoded at the JPG quality setting defined on the Image Settings page (default is 95). This is a lossy process that causes a slight degradation to the image. It can also cause an increase in the file size of images that were previously encoded at a lower quality setting. For most users the change is not noticeable and worth the benefit of having metadata preserved in the original file. But if you find it unacceptable, leave metadata writing disabled.
The metadata sausage
You might think that writing a title and other properties to an image’s metadata would be pretty straightforward. But it’s a mess of various and competing standards, including EXIF, XMP, IPTC and more. Even within a standard, there are differences in how data is stored (ahem dates/times).
So when we set out to support metadata writing, we had to make some tough decisions. For example, if one updates a caption, where exactly do we write it? The closest match in EXIF is a field called XpComment. In XMP it’s description. In IPTC there’s one called caption. Should we support other standards? Does it matter if any of those fields already have data? If they do, and a user edits it in the gallery, should we write only to that one? What if those fields contain three different values?
In the end, we looked at each field and tried to make the best decision. For the caption, we write the value to the closest match in each of the three main standards — XPComment (EXIF), Description (XMP), and Caption (IPTC). Any existing data is overwritten.
Some properties, like the IPTC ones, are matched with a single destination. For example, if you enable the IPTC caption property and make it editable, we write only to the IPTC caption field and leave the others alone.
This leads to the potential for unexpected behavior. For example, if you make both the caption and the IPTC caption writable, changes to either of those properties will overwrite the existing IPTC caption field in the file.
This means that if the nuts and bolts of where the metadata are going is important to you, be sure to test. If you don’t like what you see, let us know. There is a lot of gray area, so we want to hear your thoughts.
There is a group of folks called the Metadata Working Group trying to make sense of all these metadata standards. They have a 73 page document called Guidelines for Handling Image Metadata that we have been trying to follow. It kind of makes your head spin but at least there’s a group trying to create a single set of standards that all applications can strive for.
While tag writing is supported, people tags are not. That’s due to a combination of no standardized place to put them and insufficient support in the .NET Framework for writing them. The closest thing to a standard is to define a region in an image and give it a region content type of ‘face’. I believe that’s what Picasa does although Microsoft Photo Gallery uses a proprietary schema that no one else uses (despite Microsoft being a member of the Metadata Working Group).
For the 4.0 release, we were able to support retrieving people tags that were written by Microsoft Photo Gallery. But we couldn’t pull in people tags written by Picasa. And .NET didn’t let us write people to the file in a way that both apps could recognize.
We believe it’s important to be able to write people tags to the file, so we haven’t given up. In fact, we have ideas for improving this, so stay tuned. For now, you may want to use the tags property to store people names. Depending on your workflow and requirements, you may want to do that anyway.