Samen met Mike Gemünde (tigger) ben ik begonnen aan het toevoegen van ondersteuning voor afbeeldingen in Taglib#, de metadata bibliotheek die gebruikt wordt door Banshee en momenteel enkel muziek en video ondersteunt. Waarom is dit belangrijk? Omdat we hierdoor het verwerken van metadata in F-Spot drastisch kunnen verbeteren. En als Banshee ooit beslist om foto-functionaliteit toe te voegen, dan is het meteen ook voor hun bruikbaar.

Het doel is om een bruikbare, complete en solide metadata bibliotheek te bouwen. Met uitgebreide (tot in thet extreme toe) unit tests. Wanneer het om jouw files gaat willen we kunnen garanderen dat het correct zal gebeuren.

Dit alles kan je vinden op Gitorious. De code zit in de photo-support branch van de mainline repository, master is een kopie van de SVN repository voor upstream Taglib#. Momenteel ondersteunen we JPEG en TIFF, met Exif en XMP (zie de wiki voor meer details). We zijn van plan om dit verder uit te breiden naar alle andere formaten. Meer instructies in verband met het verkrijgen en testen van de code kan je hier vinden.

Wat is het grote plan? Eerst gaan we de git versie op zich verbeteren. Wanneer die klaar is zullen we deze beginnen gebruiken (en shippen) in F-Spot om ze verder te laten rijpen (tegelijkertijd houden we de hoofdrepository in gitorious up-to-date). Op lange termijn zullen we met upstream werken om dit terug te mergen. Ik heb reeds gepraat met Gabriel Burt, deze "fork" zal dus niet eeuwig blijven bestaan.

We zijn nog op zoek naar mensen die mee willen helpen. Ofwel door het te testen (zodat je zeker bent dat het je files juist behandelt) en natuurlijk door er aan te hacken. Tot mijn grote verbazing moet helemaal geen superhero hacker zijn om nuttigs te kunnen doen, het schrijven van een metadata library is niet zo heel moeilijk.

Zin om mee te helpen? Zet je IRC client op, kom naar #f-spot (op irc.gnome.org) en praat met mij (rubenv) of 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 because <sarcasm>adding complete and correct support for Exif, IPTC, XMP and every camera makenotes is such an easy task</sarcasm>.

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").

Naam
Email (optioneel)
Website (optioneel)
Onthoud mijn gegevens
Email mij wanneer er nieuwe reacties zijn
Reactie