Together with Mike Gemünde (tigger), I am happy to announce that we are working on adding image support to Taglib#, which is the metadata library used by Banshee and currently only supports audio and video files. So why is this important? Because we will be able to vastly improve the metadata handling inside F-Spot. Furthermore, should Banshee ever decide to add photo support. it’ll be ready for them to use.
The aim is to have a usable, complete and solid metadata library. This includes extensive unit testing (to the extreme). If we will handle your files, we want to guarantee that it will be done correctly.
All of this can be found on Gitorious. The code is in the photo-support branch of the mainline repository, master is a copy of the SVN repository for upstream Taglib#. Currently we support JPEG and TIFF, with Exif and XMP (see the wiki for more details). We plan to expand this to every other format out there. More instructions on how to get the code and test it can be found here.
So what’s the plan here? First, we will improve the git version as is. When it is ready, we will then start embedding it into the F-Spot tree (while keeping the main repository synced in gitorious), to let it mature. Over time, we’ll be working with upstream to have it merged back. I have already talked with Gabriel Burt about this, so this “fork” won’t stay around forever.
We are looking for people that want to help us out. By testing it (to make sure we handle your files correctly) and off-course by hacking on it. Much to my surprise, I noticed that writing a metadata library isn’t all that hard, so you don’t have to be a superhero hacker to be able to do something useful.
Want to help out? Hop onto IRC and join #f-spot (on irc.gnome.org), come and talk to me (rubenv) or Mike (tigger).
I approve! ;)
Too bad you aren’t doing this in C such that other people can use your work. Ah well, that’s your decision to make.
i wonder: if you were doing this in c++ (or even python for that matter) do you think you would hear half as many comments about your choice of language?
Great news!
“Furthermore, should Banshee ever decide to add photo support. it’ll be ready for them to use.”
To create the Netscape Navigator of media applications? Please no. :-) I love Banshee and F-Spot, but their uses are so vastly different I can’t imagine why you’d integrate them. Maybe you guys can pull it off, but I’m wary of monolithic apps like OpenOffice, Eclipse, SeaMonkey, etc.
@Søren Hauberg
Other C# apps can re-use the code. Do you troll every Python library asking them to rewrite in plain C as well? People should use whatever language they please! :-)
@anonymous coward:
I’m guessing yes. C++ isn’t very popular in the Gnome world, and Python’s performance in non-trivial desktop applications is…less than desirable. :-) The anti-Mono crowd just seems to be a lot more vocal than say: the anti-C++ crowd. Probably due to having a high profile figurehead like RMS involved.
Full disclosure: I’m a Python web developer as well as a happy Banshee, F-Spot, and Tomboy user.
This is really exciting. I was considering adding image support years ago after I added video but I lacked the subject matter expertise and was already losing interest in continuing development. I’m glad to see it’s finally getting added as it will really round out the platform.
Søren, It may surprise you but being written for .NET, TagLib# was able to gain a much larger user base than C, C++, and Python libraries written to accomplish similar goals. The big problem with C libaries is that they aren’t as portable as you would think and they rarely bridge the Linux and Windows worlds. Because .NET has a significant number of users and compiled Mono libraries run on Windows, I am still contacted to this day by people who want to integrate it with their commercial/shareware/freeware applications.
I love C as much as the next guy but you have got to take it off of its pedestal.
@anonymous coward:
don’t get me wrong: I have nothing against mono and I actually think that C# is a reasonable choice for applications like Banshee and F-Spot. But I still do think it is a shame when the libraries doing the very basic functionalities aren’t shared as much as possible between applications. Sadly, C seems to be the lowest common denominator, which makes it the best choice _if_ you want to share your work.
Given the current direction in the gnome desktop to use tracker as a repository for metadata about files my impression is that we should move away from the current application centric methods of handling collections. Right now we keep collections of music (and possibly video) files in banshee and photos in f-spot. Each of these is isolated from the rest of the desktop. Short of reading through the sqlite database in f-spot there is no way to access its rich metadata from other applications. This effort seems like a great way to get convergence between those two uses and it may allow other applications to use the same API to access music/video/photos but it is still not a general solution.
Has the option of putting all this into tracker been considered before and discarded? The f-spot work rubenv did for SoC enables reproducible image transformation workflows. Imagine this use case if that workflow is inside tracker and managed across applications:
- I take a photograph in RAW, convert it to a JPG, resize and crop it, alter its colors to be a funky red and white monochromatic, include it in a LaTeX file together with some formatted text, generate a PDF file from it and finally use a desktop publishing app to turn it into a fold-out brochure with three more pieces of text.
- I later decide to change the funky red and white monochromatic to blue and white. Since the transformation steps are included inside tracker and there is an orchestration piece of software that knows that files have changed and it should regenerate the chain I get a nice dialog that says “You’ve performed a change in an image that is used in this other file, do you want to update the file? (Continue, Break Link, Cancel)”
This is basically bringing the power of Make/Unix pipes to the GUI. You could even have an “export to Make” function where you package a set of files as a makefile and can import the set in another machine with the connections intact.
Even without this orchestration functionality having all the metadata inside tracker would free the data that is currently application specific. If enough standardization is done things like banshee and f-spot could be split up into modules. I can see f-spot not being a monolithic application and instead be:
- A plugin for nautilus to view the photos on the disk indexed by its metadata (tags, rolls, dates, etc)
- A set of exporters to send photos to flickr/facebook/etc
- An importer to get photos from media, catalog them as the user wants it (give it tags, assign rolls/events, etc)
- A set of converters that take an image in the broad sense (its RAW+JPEG+conversions+metadata+orchestration between versions) and operate on it generating more images, metadata and orchestration information
You could still package all of these together at the UI level as a single application if you want to give users an Aperture-style interaction. But what you could also do is stuff like:
- Import all the audio recordings, videos and photos from a specific event at the same time since they are on the same SD card. Catalog them together.
- Export video/audio/photos to facebook together with descriptions
- Search and catalog all of these plus text files and others all through the same interface in nautilus with a consistent set of tags
Getting all of these use cases working would take a bunch of coding but the point is that the data is the important bit. If we have a centralized and formalized way to describe what all the files are, anyone can write an application to enable one specific use case without having to hack into f-spot/banshee at all and in whatever language he wants to do it in.
Just my overly verbose 2 cents. I’m not assuming I am right at all and would love to hear others’ opinions.
@soren
Just pulling your leg :) I agree that a C library would be great, but the amount of legwork you need to do to keep bugs to a minimum and maintain a sane API in C is huge. Add to that the time it would take to maintain that separate library, and its C# bindings, and you’re looking at a considerable amount of effort. IMO, doing it in C# is just more feasible in these conditions.
This coming from someone who works with C all day, and loves the low-level feeling of the language.
Yes, because:
Adobe XMP Toolkit
Exempi
Exiv2
Exiftool
are not enough, and becauseadding complete and correct support for Exif, IPTC, XMP and every camera makenotes is such an easy task .
Reinventing the wheel, NIH and such come to mind…
Or you could help the developer of Exiv2. See:
http://dev.exiv2.org/boards/3/topics/show/162
We investigate quite a lot of alternatives, including exiv2. Mike even developed a gobject wrapper around exiv2 (gexiv2), with bindings (gexiv2-sharp).
Here: http://gitorious.org/gexiv2
Having investigated this (and getting very far at it), we made the call not to continue in that direction, in particular because we weren’t very happy with the API.
As a side-benefit, doing this in fully managed C# code means we get free portability, something that is quite often an issue too with C/C++ (despite the fact that they are generally claimed to be “portable”).