Skip navigation.

F-Spot 0.0.3 Released

Gnome Multimedia
Gnome Multimedia

After quite some time from the previous release, the Mono-based, Novell-sponsored, F-Spot, an image catalog/viewer application, reached version 0.0.3. Changelog here, download here, latest screenshot here.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

PNGs

Has anyone else noticed that f-spot doesn't load PNGs?

Mono performance

Where is mono performance headed? In particular with respect to memory usage. Apps like muine and F-spot use insane amounts of memory. mono is really exciting because of the x-platform and because it is just a good framework to develop with but god does it use a lot of memory.

I haven't used it since the 1.0 release so maybe these things are getting better.

Hmmm... installing a few doze by Anonymous George

For a nice image thumbnailer

For a nice image thumbnailer it's probably not worth it. For an app that takes care of everything between plugging my camera into the computer and seeing my photos on the internet, and has a nice thumbnail organizer to boot, it might be worth the extra dependencies.

and..

and a wicked cool music player

and a fantastic rss aggregator

and one of the most innovative todo systems I've ever seen

and a metadata cataloguing engine (what ever happened to dashboard anyway?)

and to be prepared for beagle, the mono-based competition to WinFS

and to obtain a very nice rapid development platform

The list goes on. I'd say it's definitely worth it

Yeah, and a kitchen sink too,

Yeah, and a kitchen sink too, and every one of those processes starts a copy of mono VM with about 25MB memory footprint. No thank you.

wicked cool music player

it would be even cooler if a cd player was built in. i'm sick of using more than one app for managing and playing my music. especially when all the interfaces are completely different.

i think the itunes- and winamp-like interfaces are terrible

liblcms-1.0.0.dll?

Where can I find liblcms-1.0.0.dll?

Thanks,

Centralized information

I think that F-spot looks very cool, and I'm excited about it's progress, but there is one thing that bothers me (and is also in GThumb). Why does photo management software centralize comments and picture meta data? This seems to be a common thread. But, if I use an application like Gnumeric, all the data is stored in a single file out in my filesystem. If I use a program like GRAMPS all my geneology data for that family is stored in a single file that I can move around. But, if I manage my photos with F-Spot or GThumb I have some mystery meta data file that has all the work I put into my photos in it. I can't move the directories or files around without effectively loosing that work.

The only solution that I see is storing the metadata with the file directly. Kinda ugly because there is alot more files in the file system (the JPEG plus a metadata file). But, if this was hidden by Nautilus it doesn't seem like it would effect users that much. Any other ideas? It seems like we should be able to do this better.

The solution I'm currently using is BINS, but I'd love to have all of the GUI friendliness so when people ask me how I do my photos I can give them a solution that they can do also.

Reiser4

That problem will hopefully soon be solved with a reiser4 plugin. With reiser4, you'll be able to add metadata to a file without changing the file and have that metadata follow the file automatically. We just need someone to write the plugin and another to make use of the plugin. The only drawback is the reiser4 dependancy but I'm ready to live that.

A la Rhythmbox

The problem is that if you store the data as part of the photo file, and you have 50,000 files, it would take forever to sort or search. (Grepping one 50,000-line file is much faster than Grepping 50,000 files.)

I think the solution is a hybrid, like Rhythmbox uses: store the metadata in the file itself, and also build some application-specific indices so it's efficient to access. (I didn't realize that f-splat didn't do this already.)

Only if you aren't using a de

Only if you aren't using a desktop search engine like Beagle.

The killer for storing metadata externally is that if you use external programs to move, copy, etc the photos you lose the metadata.

--
Come To Daddy

Even so

Beagle *is* an index. It uses the Lucene indexing engine.

I hate this too. I would like

I hate this too. I would like to see the comments to be put into the EXIF data of the JPEG file. I think JAlbum currently does that...

digiKam

digiKam can optionally store it's comments in the EXIF data (at least version 0.7). It slows down comment reading and writing, but it's worth the hassle...

Info in EXIF

I went and looked up the EXIF standard and this definitely seems to be the case. Specifically if you look at page 28 (34 in the PDF) there is a UserComment field. There is also a title field. Seems like this might be a good way to do things, perhaps extending this to specify which kind of user comment (keywords, description, textual location description, etc.). Very cool.

No, you need IPTC/IIM tags

EXIF is designed for things that can be automatically calculated -- 90% of the time, timestamp and landscape/portrait orientation are all that is used. The IPTC (international press telecommunications council) has a much better "what's in the photo and what does it mean" set of standard metadata tags called IIM (see http://www.iptc.org/IIM/). Photoshop and related Adobe products have full support for them, as do the heavyweight commercial digital archive manager programs. ImgSeek supports reading them, though not writing new ones yet.

database

I used BINS for a while but I finally switched to Gallery which is has the advantage (or disadvantage) of being dynamic (in php).
See http://gallery.menalto.com/

Gallery is a nice to way to create HTML galleries but it does not solve the problem of attaching data to the images. I currently use Gthumb I am not really happy about it for the same reasons.

I though about it for a long time and my conclusion is my prefered system would be a database (mysql) in which the meta information would be associated not only to the image filename but also to a checksum of the file content (md5sum).

If you want to edit the file then it might be a good idea to also index some of the unique properties preserved by your graphical editor (I think that Gimp preserves some of the original JPG EXIF fields).

HIG

Just by looking at it, it clearly needs some HIG love. However, just looking at it I can see it definetly will rock, just needs to fit in a little bit more to gnome...

Yeah!

F-Spot rocks!