Sagittarius is out!

The first aplha of the Sagittarius XMP metadata editor is out.

It can be downloaded from sagittarius.vokod.com.

Much of the planned features is still under development, but it can edit metadata

It reads and writes the XMP-IPTC metadata of jpeg,tiff,png, dng files, both in single and in batch mode.

The main window shows a directory tree and a preview on the left, photos of the currently selected directory in the middle, and XMP-IPTC meteadat on the right.

It shows a (live resizeable) preview of the currently selected photo, and displays (resizeable) thumbnails of the other photos of the directory. Beside the thumbnail it shows some basic information of the picture file (name, dimensions, size and IPTC caption. On later versions, the information displayed will be user selectable from the file properties, EXIF and IPTC tags.)

It shows all the XMP-IPTC fields of the currently selected photo (later versions will display EXIF as well)

Sagittarius does not overwrite your original files. It creates a backup copy of them (actually it is the default functionality of Exiftool, the module Sagittarius builds upon. In later versions, backing up will be user selectable).

In a separate dialog (in later versions it will be integrated to the metadata-display side panel on the right) you can edit each XMP-IPTC field of one or more photos. User can select which field to edit or leave as is.
If the user selects more than one photo, and for a certain metadata field the values are different, then a value of “Multiple values” will be shown to the user in the dialog. The only exception is the keywords (IPTC Subject) field. In the case of the keywords, Sagittaris gathers all the keywords of the selected photos. If a keyword is common (is presented in every selected photo), it will be displayed as is. If it is not common (only a few (at least one) photo has it), it will be displayed with a * as its first character. If the user does not remove the star (or the keyword), than this keyword won’t be applied to all the selected photos.

1.0 will have…

• EXIF support. I mean XMP-EXIF support. Changing of the EXIF fields will be limited to date and GPS fields (why would anybody change the other stuff anyway?).
• No metadata editor dialog boxes. Metadata edit will be done in the right side metadata panel.
• Metadata templates. User can create and apply metadata templates to batches of photos. For example, one template for copyright fields, one for creator, and so on.
• More sophisticated keyword handling. Keywords will be saved to a tree hierarchy, from what user can select which keyword to apply to photos.
• User selectable info fields in the thumbnail view. There will be up to 8lines of information beside each thumbnail. The user can select what information is to be displayed from all of the EXIF and IPTC fields, and file properties.
• For all the IPTC fields that have closed vocabularies the IPTC standard vocabularies will be implemented.

DigikamDAM

On the KDE Wiki there is an article about digital asset management with Digikam. It is quite long and covers general DAM topics as well and their realization with Digikam. From image downloading from cameras through sorting, rating, captioning, geotagging and cataloging, to archiving and backing up. It discusses the features of back-up medias and the main causes of data loss as well.

It covers both theory and practice, and is an interesting article to read, not only for Digikam users.

Part I

PartII

Sagittarius - my ExifTool GUI

A few months ago I mentioned that I was learning Python in order to write a GUI for ExifTool. Since then I abandoned Python, when encountered with mono . Mono is the os equivalent of the .NET runtime. And I had some previous experience with c# anyway, so I decided that my ExifTool GUI will be a mono app.

I worked on it in november for a a few weeks and in the last week, and it is slowly taking shape!

Sagittarius (this is the name of the app) will focus on XMP, XMP-EXIf and XMP-IPTC to be proper.

It can load the content of a directory (yet it only can show files tha ExifTool can read and write, later I want it to be able to show files Exiftool can only read), can show thumbnails (even of raw files) , can show the metadata of a file in a notebook widget and a preview as well.

It will be able to edit multiple files (yet it can only edit a single file at a time) and to apply metadata-templates to image files. It is far from being released, but i can show you a few screenshots. Although it is on a very early stage, the code is already a mess. Well I’m not a developer. So before continuing the work on it i will rather focus on coding techniques and oo-development in general. So far it was just a try from my part, but now i really think that i will be able to finish it. I hope that in two months i will release a 0.1a. Stay tuned!

Xmp manager

A very good little piece of software is XMP manager from grigio.org.

It is a GUI to manage XMP metadata on Gnome. It is actualy a Nautilus extension. Only a few hundred lines of code, a Glade interface and exiftool, as backend. Simply, elegant, usable.

By default it only offers a few fields to edit, but what makes it more interesting, that the user can add custom fields! And it can edit multiple files.

It is an excellent tagging application! So simple, yet so powerful (exiftool can handle almost all image formats).

Writer’s block

It’s been long since my last post. I was busy with other things and, to tell you the truth, i haven’t find anything to write about.

Let me explain this a bit. When i started this blog my intention was to write about solutions. Color management was a grateful issue. The idea is simple yet the implementation is very complicated. I tried to synthesize all the information i found on the web and in books, and write a guide that has the necessary technical background, but in the same time is easily understandable. I don’t know if i succeded or not, but the articles were read quite a few times.

And that is what i tried to do with other things as well. The geotagging, and the panorama posts were not howto-s, but rather reviews or short guides. I don’t want to write howto-s or step by step tutorials for certain software, becasue i neither like to read nor to write them. Naturally i read them sometimes when i’m searching for a solution to a particular problem, but i better like to explore things myself. (Beseides, a month ago i found Joel Cornuz’s blog, who is writing excellent howto-s and application reviews reguarly, about just the same software i would write about, if i would.)

My intention was to guide the attention of the interested people to certain areas and let them find the solution that fit them best by themselves.

But on the other hand i can only write about things that interests me. The problem occured when i tried to port my workflow to linux. My former workflow consisted of theese few steps: selection, metadata-editing, developing, rating, cataloging, archiving and printing. On linux i only found a few suitable software for selecting and developing. I googled a while for finding software for the above mentioned tasks, but failed.

My cataloging and archiving method relies on metadata. When i wanted to find a certain photo, i entered a few keywords, people i was looking for, event, or whatever. So what i was looking for is a metadata-editor that focuses on IPTC and XMP, and can handle DNG files, has a gui and shows at least thumbnails. Further i was looking for a cataloging application, that is customizable, focuses on IPTC and XMP metadata, can handle DNG files. And preferably theese two shall be separate applications.

I always enter metadata to the DNG-s, to avoid editing metadata twice (for original and derivative files). This is the first step (ok, the second, after trashing the photos that worth no more than that). So i was not able to port the first step. For developing raw files and postprocessing images there are quite a lot of applications, that would go easy, if i could overcome the first problem. Cataloging would be another hard issue i fear, but i nevert tried it yet, because how to catalog if there is no metadata?

This made me so dejected, i even made fewer photos lately (and even those are undeveloped yet). I only have hope on the next release of f-Spot and Digikam. Maybe, who knows. I love linux, but from a photographers point of view, the applications available are very few. This can be well understood. Developers are making software they are interested in (in general). This is why there are image-editors and -viewers, but no asset-management, or workflow software. The latter few are mainly used by professional photographer, who are unlikely to be developers (actually, this may not be true, for i am not a professional, but i use them, and so may be a lot of other people). I think that this situation will change, and in two years (i hope) there will be both sophisticated metadata-editors as well as asset-management applications.

Currently i am learning python and pyGtk in my spare time. That is the other reason for not writing to this blog. I want to develop a GUI wrapper for exiftool. If there is no application that suits my needs, than i have to write it myself. I have some programming knowledge (not much, unfortunately), and I am curious what i will be capable of. I don’t think that it will ever be a full featured product, as my goal is to make it capable to fit in my workflow, but i will upload the source, once there will be something to upload.

If i find anything interesting meanwhile, i will post about it. Hope it will be soon.

Geotagging 2

I tried the software QLandkarte, what is a graphical application for communicating with Garmin GPS units. It’s main feature (for me at least) is that it can send and receive maps to/from devices. (Its features makes it similar to the Garmin Mapsource)

It was not easy to set it up, because 0.5.2 precompiled from getdeb was unable to send maps (feisty64 package, my system is qutsy64) although, it was working fine for a friend (feisty32 package on gutsy32). Fortunately, there is a source package (0.5.3). But be sure to install its dependencies before compiling it, because the package has no autoconf script. Works great. Its usb-protocol is based on GPSBabel, so the module problem mentioned above can be an issue here too. Can send and recieve routes, tracks, waypoints and maps.

Geotagging

I do geocaching. And naturally, i make photos during my trips. So why not connect the two? What if I could tag my photos with the coordinates they where shot on? My camera does not have a built in GPS receiver, but that is no problem.

My GPS is a Garmin hand held device, with USB port. I’ve chosen GPSBabel, as it is said to work well with Garmin devices. Unfortunately, there is a little problem with USB modules, but a solution can be found here. Just a note: I did the Ubuntu Dapper solution, and had to restart after the editing/creating of the files. No kernel recompiling was necessary.

For USB capable Garmin devices, type in the following command:

$ gpsbabel -t -i garmin -f usb: -o gpx -F tracklog.gpx

This will download the tracks from the GPS to a file called “tracklog.gpx”.

The EXIF metadata section of a photo holds information on the creation time of the photos (among other things), (just make shure that the clock in your camera is adjusted well), so the time stamp of every photo is to be checked against the tracklog, and if a track point with the same time stamp exists, then the coordinates of the trackpoint are to be written to the GPS section of the metadata of the photo.

This is what GPS Photo Correlate does. And it comes with a GUI too. It is capable of interpolation between trackpoints, so if the time stamps are not exactly the same, it will correlate from the coordinates of two adjacent points for the time stamp of the photos. Really easy to use. The only flaw - for me - is that it seems to be unable to write to DNG files.

On workflows and metadata

My last post was on the first steps of my photographic workflow, namely downloading, backing up, and cconverting to DNG.

The next step is bulk metadata editing. At this point i only enter data that is relevant to all images of the session. For instance, creator and contact info, copyright terms, some keywords on the location or occasion and on people. Theese fileds are members of the IPTC metadata. For this i would need an application that can edit IPTC, and can edit the metadata of DNG files, and can show thumbnails.

Much to my amazement, I was unable to find an application on linux capable of theese three simple things. I hope that I may be wrong, and soon you will comment me some applications i have not run across so far. Both digiKam of KDE nad f-Spot of Gnome are feature-rich applications, but somwhere fail for me (f-Spot has limited metadata capabilities, and digiKam wants to copy my files to its working directory). Fortunately the next few releases of both software will contain some very useful features for me (more on the upcoming features here (f-Spot) and here (digiKam) ).

I hoped to find some GUI for the famous exifTool, but was unable (only found a windows GUI). ExifTool is so very-very powerful, especially in batch metadata editing, i really can’t understand why it has no GUI. But if I think about it, it may be a daunting work to implement only part of its functionality in a graphical way.

Well, so much, i only have a question more. Do you know about a metadata editor out there, that can handle DNG-s, knows IPTC, shows thumbnails and is capable of both single picture, and batch metadata edit?

On workflows, openRaw and DNG

It’s been quite a long time since my last post. I was busy with work and other stuff, but what is more important, i was on to port my photographic post-processing workflow to linux.

Workflow seems to be a popular word among photographers nowadays, and there are as many workflows as there are photographers. In this post I will introduce the first part of my (former) workflow to you in order to show you an interesting discovery.

My (former) workflow began like this:

Mainly, i shoot raw. Not because my camera does not make decent jpegs, but i like to be in control. I have a directory structure for my photos (actually, there are two, one for the original files, and one for the derivative files. I store them separately), what is extendible, and makes backing up to dvd-s easy, and i want applications to adapt to my habits (workflow) rather then force me to adapt to theirs.

After downloading the photos from memory card (or, as it is often in my case, from a portable hard drive, with built in card reader to wich i have copied the contents of my card on site) and immediately backing them up to a separate hard drive, i convert the raws to DNG-s.

There are web-wide arguments on DNG, if it is the answer or not to the question of the (photographic) life, the (photographic) universe and everything, and a very long but very interesting conversation on it (from Stuart Nixon, Peter Krogh, Kevin Connor, and others) can be found on openraw.org.

Why I have chosen DNG? Portability. Oh yes, i forgot to tell you, my wokflow was developed with portability, and application independence in mind.

Raw converters never write to the raw files. The raw files are from-camera originals, and shall remain so. Usually they are closed, not documneted standards, an in order not to corrupt them, raw-editors do not write them. They usually create a separate file, wich contains the alterations the user have made. And every raw-converter does it on its own way (even the tools the raw converters offer differ slightly). They even place theese files differently (some of them place them to the folder of the image files, while others make a separate directory), and none of them can read the sidecar files of the others (naturally ). If you have processed a photo with one type of converter, you won’t be able to view the result later on a different converter.
The only exception is DNG. DNG stores the original raw file + metadata about this file in a container. The metadata is about the alterations the user made (in a standardized form) and data on the photo (exif, iptc, xmp, and whatewer). And it is an open standard. Not a perfect one, but usable. And the applications, that implement the standard can read, interpret and write the DNG files (writing means altering the metada about the original embedded raw file, and not directly altering the embedded original raw file).

There is no DNG converter for linux yet (afaik), mostly because linux users (and developers) see the DNG move as a blatant attempt to take over the RAW format market by a jealous software house not currently a player (writing the two words ‘DNG’ and ‘linux’ to google, the first result will be this article).

So far, the only solution - in my view - is DNG. OpenRAW is a very respectable movement, but please, the article that pops up if you go to the openRaw site is 15 months old! And - again afaik - open documentation of the raw formats will not solve the problem of the sidecar files (and thus application independence). Even if a raw file is documented, it does not contain a place for additional metadata (on image alterations). And a little addition: The original title of the above linked article, the Notes on the future of Open RAW formats, and a look at DNG was “DNG is not the answer”, but it was renamed a few days after its publishing. And as the comments after the article shows, Mr Nixon stated things that were wrong, and were rather his assumptions than facts. Now who is blatant here? (more on what was right and wrong in that article and in its comments is here and here by Barry Pearson, (the page was checked for its accuracy by Juergen Specht from openRAW))

I feel that for the members of the openRAW, DNG is the Antichrist, while Adobe is the Satan itself. In my view, the purpose of the two initiations have several common points. DNG has a versioning system, and maybe if members of openRAW would suggest alterations on DNG, then the next release of DNG (if Adobe would have implemented theese theoretical alterations) could be “the” openRAW. DNG is very well accepted, and together, Adobe and openRaw would be able to persuade more manufacturers to implement a common standard.

Panorama - Hugin

In the summer I shot some panorama pictures to be joined to form one big panorama. It was an experiment from my part if and how i could overcome the various perspective distortions and lens vignetting. As it turned out, i couldn’t. Individual pictures had to be distorted individually to match the adjacent photo. And the more far the point to be joined is from the center of the picture is, the more perspective distortion i had to compensate. These photos weren’t taken on tripod, and I wasn’t too cautious during the making. I just wanted to play with panorama creating, and i had to realize it is no fun! Or at least no fun if you don’t have the right tool.

Then i tried Hugin. The interface is quite complicated, it has seven tabs loaded with options. Anyway, i loaded 4 images, and much to my amazement, Hugin immediately began to stitch them. And much more to my amazement, about half a minute later, the panorama image was ready, and it was quite flawless!

As it turned out the first tab of the seven is a simplified interface, where the program does (almost) everything automatically.

But after experimenting with the manual modes, it seemed no more that complicated.

The second tab is for loading individual images. It makes sense arranging the photos to a left–>right or up–>down order, or else the program may not be able to create the panoramas automatically.

The third tab is for adjusting the settings related for the camera and lens, all done automatically if the image contains the related EXIF metadata.

The fourth tab is for cropping the individual images if you want to.

On the fifth tab you can select points on adjacent images to be aligned.

Well, the fifth tab is still an enigma for me (i haven’t read the manual), but it is about optimizing.

The last tab shows some options concerning the output panorama can be set, like final size and so.

But here is a really important feature of the program, namely the enblend module. Without it, on the stitched panorama, the individual picture edges could be seen due to lens vignetting. But enblend blends them to be invisible.

Before letting the program do its work its worth checking the preview and adjusting it a little, if needed. Usually the only problem is that the image is not properly centered, and/or the horizon is angular or curved.

Hugin is a really very powerful program. Although its UI is a bit complicated, it is very easy to use, because you only need to mess with the controls, if you want something extra, or in the rare occasion of the program being unable to do everything by itself.

For Ubuntu users, Hugin is in the Graphics section of the Universe repository.