Linux.com

I always thought gthumb was the way to go for GNOME.

#

I think that best is <a href="http://kphotoalbum.org/" title="kphotoalbum.org">kphotoalbum</a kphotoalbum.org>.

Much better that digikam!

#

There's no end to the list of "image browsers" -- meaning apps that let you scroll through folders looking at thumbnails. But that's a different use case than full-fledged "photo managers."

Now, having said that, the big question is where you draw that line. Frankly there are just dozens and dozens of apps that kind of do photo management. It depends entirely on the user whether an app is a "too simple" thumbnail browser or a "good enough" photo manager. I chose to leave out gThumb (and GTKsee) because (a) feature-wise they are far on the low-end of the simple browser-to-photo manager spectrum, (b) they refer to themselves as "viewers" or "browsers" and (c) there's only so much space in an article before people stop reading, so I wanted to get around to the apps that are actually good photo managers.

KimDaBa / Kphotoalbum also didn't make the cut; in my own tests it is buggy and its interface is a disaster. Breaks all conventions of normal photo management in an effort to be "different," plus it doesn't offer basic features the other apps do. That gave it walking papers for this article.

Granted, I was very, very unimpressed with Digikam and F-Spot (very), but they were necessary evils, since they are touted as the "official" photo management apps for their respective DE's.

In any event, I could certainly have added more apps to the "don't" pile covered in this story, but none of them would have changed what I put in the "do" pile. For people who just want a recommendation, it doesn't matter what the discarded alternatives were.

#

Formerly KimBaDa, KPhotoAlbum is a powerful organizer. So powerful, in fact, that they recommend that you play with the included fake album before moving on to your own photos and organizational scheme. Once you start with your own photos, you can give each an unlimited number of tags, describing who is in them, where, when, and more. You can even draw a rough sketch and have KPhotoAlbum find the similar photo (it is fun but only works ok; it would be cool to incorporate into Flickr, though).

If one is only looking for an iPhoto clone, I have no idea if this even qualifies. But it does stand on its own as an organizational tool.

#

I'll second that thought. And I reviewed for my own personal needs a dozen of "organizers" and KPhotoAlbum is the best one out there. I also did quick demos for my friends and everybody was stunned by functionality. KPhotoAlbum is *THE* photo manager - the rest are more from category "image viewers".

#

I second (third) this! I, too, reviewed all the picture management programs I could find (including all of the ones mentioned) and KimDaBa (as it used to be called) turned out to be the best one for my needs (tagging and sorting a large collection). So make sure you include KPhotoAlbum in your evaluations of picture management suites.

In addition to that, I do use Picasa because of it's "I'm feeling lucky" image enhancement feature. I export the enhanced images and manage them with KimDaBa/KPhotoAlbum.

See ya
-- sds

#

I use Mirage for image editing.
<a href="http://mirageiv.berlios.de/index.html" title="berlios.de">http://mirageiv.berlios.de/index.html</a berlios.de>

mainly becuase it allow you to add custom commands, so with that i have imagemagick commands to perform tasks it can't yet do all from the gui.

Does what i need.

Alan

#

You can use your coustom commands also with gqview<nobr> <wbr></nobr>;-)

#

I'm loving Picasa so far. While it's not open, it's from a community friendly source (no pun intended). My OS changes with my mood so it's nice to have the same app across all platforms.

What I'm really after though is an Amorok for images (amorok keeps my music tidy by path/naming by metadata). I've a tone of photos, added to daily by my wife with the digital camera, and a naming convension that does not match what the camera uses. Is there a manager that can do batch renaming based on metadata? "[album name][date][time][count if same minute].jpg"?

I've a CLI Magic article from a few months ago with a three step process but doing so from within a manager would be ideal.

#

to rename based on exif data, you can use:
<a href="http://pintant.cat/qphotosort" title="pintant.cat">http://pintant.cat/qphotosort</a pintant.cat>

If you have any problem with it, don't hesitate to send a mail to the address at end of that webpage. Or if you use it and you like it<nobr> <wbr></nobr>:-)

Carles

#

Good question. I'm not aware of any app that can do automatic renaming of any kind. Digikam, imgSeek, and Picasa all have batch renaming tools, but they must be chosen manually -- which sounds like it is not what you are asking for (though correct me if I'm wrong). As is the case on most other features, imgSeek has the most flexible/powerful implementation of the three.

On the other hand, if you tire of waiting for a solution, anything that you can compose into a script you can bind to a hotkey in GQview.... So if you had a good bash or perl script to perform the metadata-based rename, you could add it to GQview -- it wouldn't be automatic, but it would be a single keypress, which is still better than nothing.

#

Did ever try Kphotoalbum SVN version? You should...I have more tham 8.000 photos and works very fast also I can search by EXIF so I can find ease way my photos by differents types of camera.

#

No. SVN, CVS, and all other forms of unreleased code do not qualify for review in a head-to-head app comparison. Why? Because (a) they aren't generally available, (b) they are unstable (in the crash-prone, daily-usage sense), (c) they are unstable in the "any new features/improvements/bigfixes may be rolled back, disappear, or break at any particular time you grab a snapshot" sense, and (d) they are unstable in the "any new features/improvements/bigfixes may be rolled back, disappear, or changed between now and the actual release" sense.

If an app makes substantial improvements that survive until stable release, it will be the released version that deserves a review and/or a place in a head-to-head comparison.

And at that point in time, it will be fair to compare the new version of the app in question with the equivalent, contemporary versions of its competition. You can compare SVN-builds to SVN-builds, or released code to released code, but not SVN-builds to released code. Comparing an unstable build of one app to a stable build of another app is irrelevant.

#

I may have misunderstood what you were trying to say here, but F-Spot does, and has for a while, support adding comments to photos. I use the functionality quite often, and thanks to the more recent releases supporting saving this data in the images themselves it makes the data more easily accessible by outside applications.

#

I noticed you mentioned that F-Spot copied all files regardless of whether you had checked that box or not. I am using F-Spot and that is not correct. Please report on which version of the software you are using. The latest release is 0.3.0.

#

I believe that that is the embedded Exif description tag; in any event it isn't searchable, which is the point. And you can't see the comments in browse mode. It baffles me when photo/music/document-management app developers hard-code one and exactly one way to organize your material into their app.

Please don't misunderstand me -- if you like F-Spot, more power to you. I'm not out to criticize anyone's personal choice. But I feel strongly that the fact that your response ended with the observation that the embedding of the description tag makes the data easier to access by outside apps illustrates that F-Spot is not getting the job done right.

#

Wikipedia has a comparison of image viewers.
* <a href="http://en.wikipedia.org/wiki/Comparison_of_image_viewers" title="wikipedia.org">http://en.wikipedia.org/wiki/Comparison_of_image_<nobr>v<wbr></nobr> iewers</a wikipedia.org>

iPhoto looks pretty cool, too bad it's not for Linux and not FOSS.<nobr> <wbr></nobr>:(
<a href="http://en.wikipedia.org/wiki/IPhoto" title="wikipedia.org">http://en.wikipedia.org/wiki/IPhoto</a wikipedia.org>

Couple years ago, I liked this software called "ACDSee Classic", it was light-weight and quick. But it was shareware and for Windows.<nobr> <wbr></nobr>:(<nobr> <wbr></nobr>:(<nobr> <wbr></nobr>:(

#

I noticed your comments on needing to copy the images before you could work with them using digiKam.

Use showFoto instead. It's the same viewer/editor you'll find in digiKam, and you can open a specific image or a folder of images from any drive/partition that you have access to (no need to copy them).

I use showFoto instead of digiKam all the time so that I don't need to import the images first.

I like the showFoto/digiKam user interface (before/after view) for many basic tasks (USM, etc.).

#

I have my digital camera photos in one directory tree and screenshot in another and so on. Then I have one dir which is the root for digikam and there I have symlinks to these other dirs.

This way I can organize different types of files with digikam without really mixing them in the fs.

#

That does work well; probably most people eventually refine their file structure as much as they can. But even in this case, you are forced to arrange your files in a particular way to cope with digiKam's expectations. Since it stores the relevant info in an SQLite database, that's really an unnecessary burden.

#

Lack of search aside, what the previous poster was saying is that you wrongly asserted that F-Spot does not allow comments to be added to images. This is not the case, since comments have been supported since the earliest versions of the program.

As for his ending comments, I don't think that's an indication that F-Spot isn't doing a good job. It's simply an observation that by keeping user comments in the file itself instead of in a separate f-spot specific store, other apps can use it. Web-based photo galleries, for example, which aren't F-Spot's role.

#

It's not just that you can't search on them; you can't browse on them, you can't display them in the sidebar, and they don't even show up in the extended metadata panel. It's inherited from the Exif support library; F-Spot the application really makes no use out of it. Sorry if that wasn't clear in the original wording, I hope that's more straightforward.

But I'd disagree strongly with tossing lack-of-search aside. Search is the key. Without search, you don't have much more than what's built in to Nautilus -- thumbnail browsing, timestamp sorting, and tag/emblem assignment. And setting the desktop wallpaper.

#

I second KPhotoAlbum. It lets you tag photos with Persons, Places, Things and keywords, and it makes it easy to tag photos quickly. For instance, I can now search for photos of "Me and Bob, in New York, that I took last year" with just a few clicks. It has a built in viewer and slideshow feature; however it lacks editing features such as cropping or red-eye removal. Picasa still has the best red-eye removal of any program I've tried.

#

Wow... I've never seen anyone that actually liked the redeye removal in Picasa.

I've always considered it to have the absolute worse redeye reduction features of any program I've used.

Unless they've changed it (and perhaps they did, as I haven't checked this feature in a while), you can't even zoom in on an eye when using the feature, and it's not good enough to remove stubborn redeye anyway.

It would be the last program I'd ever use for that purpose. It's a pretty good browsing tool, though (at least in Windows).

#

I thought that I would have to copy my images, too, and passed over digikam for a while, but when I reconsidered, I realized that I could set the album directory to the one that I store the photos in. digikam puts a small db file into the root of that directory, otherwise your directories remain unchanged.
As for the sideways tabs, konqueror has tabs on the side, as does amarok. Is this so disconcerting? I use digikam almost exclusively for managing my collection (except for extensive editing, when I use gimp and krita), but I have never had to use those tabs at all (I don't tg my photos, but keep them in heirarchical directories with meaningful names and subcategories.
The kipi plugins are great and add a lot to the program. I also use gthumb a bit, but digikam is hands-down the best photo application, bar none. And the associated showphoto is a great slideshow and viewer application.

#

I'm not sure how you could have included gqview, but still refer to gthumb as "far on the low-end" feature-wise. gthumb has far more features than gqview, and does much more to fulfil the "photo manager" criteria than gqview. Incidentally, gqview also refers to itself as an image browser.

#

I'll tell you how. GQview has far superior searching capabilities, it is faster, it can read RAW file formats, and it can parse the entire Exif metadata tag set. gThumb can't.

#

The comments aren't inherited from the support library, since it was only in recent versions that it used EXIF to store them. Previously they were stored separately from the files (and an option still exists to allow this).

I wasn't dismissing search as useless, by the way - just noting that it wasn't relative to the point about comments not being supported. They're not searchable as they should be, but they *are* supported.

#

It irks me that you guys even mentioned Picasa in this comparison. If we are going to include apps that run in emulators then we should have reviewed most Windows photo apps. Thats like a Linux gaming site comparing Wolfenstein:Enemy Territory and Counter-Strike Source running in Cedega. Lame.

#

Wine is not an emulator.

#

so what does wine stand for if not: "Wine Is Not an Emulator" ?

#

GwenView is my choice.

I don't like F-Spot and Digi-this-and-Digi-that photo managers because you need to make a choice that limits you to that choice and when you want to unchoose you have time invested and that means that you might not move to a better solution.

That better solution out of the box is GwenView that allows for photos to be file managed at it's basic feature set... and that is enough and plenty all at the same time.

Note: The KIPI plugins work just fine too.

#

One suggestion:

Would have been helpful, to list the versions
of the apps you tested. I hope you can still
add them.

and an addition:

digikam's editor (and showfoto) support a
second set of plugins: DigikamImagePlugins.

DIP are used only by the editor part, not
the album manager. They workon a memory copy
on _one_ image, several operations can be done
and undone, without modifying the original
image.

kipi-plugins work one or many image files.
After a kipi plugins has done it's job the
image on disk is modified.

Achim

#

"DIP are used only by the editor part, not
the album manager. They work on a memory copy
on _one_ image, several operations can be done
and undone, without modifying the original
image."

That's a little misleading, given that Picasa is also mentioned. Making changes in the digiKam editor and saving DOES alter the original image. Picasa works differently, remembering the changes you made to each image, and re-applying them every time you display it. To permanently apply the changes you made in Picasa (to make them visible in another program), you have to export the image.

#

I answered to original post: you can try to use <a href="http://pintant.cat/qphotosort" title="pintant.cat">http://pintant.cat/qphotosort</a pintant.cat> . I answer to you too just in case you have notification mails for comments<nobr> <wbr></nobr>:-)

#

Picasa has some really nice gadgets, looks good, and if you have little children that like to play with the computer, it's really great.

But as there is no directory tree and files show simply the file name without the path, it is absolutely unusable.

Imagine: You have thousands of photos in different sizes and versions: lets say: thumbnail, small, large, black-and-white, 16-bit, raw, original, retouched, with watermark, etc. Of course all similar files have the same name. Picasa shows all these pictures just with their names - you never know, which version you are dealing with. You have to click a lot to find out.

Plus: Picasa always runs in background eating up some of your ressources, and as it is closed source, you don't even know for sure, what it is doing whyle sitting in the memory. You can, of course, turn it off, but then you'll loose the advantage of having a quickly searchable database. Researching the computer again takes hours.

No, Picasa is a nice piece of a toy if you like some desktop effects, but as a photo management tool it is completely unusable.

Don't tell me, how many people use it. This is no argument. If you count the flies, sh*t must be best food.

#

I completely agree with you about Picasa. It has the easiest re-touching I have seen (color/contrast/shadows corrections), but is completely useless in practice because it ignores the (carefully organized) paths where my pictures are stored and even goes to great lengths to hide it from me.

#

Refocus is not the same as sharpen filter. See <a href="http://refocus.sourceforge.net/" title="sourceforge.net">http://refocus.sourceforge.net/</a sourceforge.net>

#

There is also a perl app called MaPiVi (<a href="http://mapivi.de.vu/" title="mapivi.de.vu">http://mapivi.de.vu/</a mapivi.de.vu>), it uses all available MetaData fields (EXIF, IPTC) to tag the pictures, creates a temporary database for searching (can be redone from images any time), supports basic adjustments to JPEGs like batch renaming, cropping, rotation, levels (some of them are lossless operations).

But still, I have not found a photo management app for linux that would handle reasonably well big collections of photos (in terms of quantity, file size, number of locations - e.g. CD, DVD, external HDD), keeping a temporary set of thumbnails and screen-previews (so that I do not need to use the DVD for searching), but still keeping all tagging as MetaData in the picture files (I had to change my catalloguing app in the past, as a result, I have lost my previous tagging as it was stored only in a proprietary database).

#

Hi, just for clarification:

> big collections of photos (in terms of quantity, file size

I have 25.000 pictures in my Mapivi database and it runs quite well and fast<nobr> <wbr></nobr>...

> number of locations - e.g. CD, DVD, external HDD)

Mapivi supports pictures on external media<nobr> <wbr></nobr>..

> keeping a temporary set of thumbnails and<nobr> <wbr></nobr>.. and stores thumbnails in a central place for them.

> screen-previews (so that I do not need to use the DVD for searching)

OK, this is not supported by Mapivi.

> but still keeping all tagging as MetaData in the picture files

This is the way Mapivi stores all metadata.

So except of the scree-preview everything is supported by Mapivi.

Regards

            Martin

#

An important item that I always consider is that all your hard work should be done only once. If your current choice of program ever gets discontinued, you should be able to keep on using your photo collection in other programs. This is what is so great about F-Spot. The other programs (and certainly Picasa) are not open about the way they store your added keywords etc. No program offers an export or import function for compatibility with other programs. F-Spot however uses a simple SQL database, a technology that will be forever accessable.

pjv

#

You mentioned imgSeek very shortly, but you missed to mention the most important feature of it for photo organizing: the similarity search. It is great thing: you do not necessarily need the keywords and categories (which of course are supported, but you was too lazy to set for all 25000 photos in your collection), it is sufficient to remember how the image looked like. You can either draw approximate sketch of what you want to find, or you can use any image which is similar to the one you are searching.
You also stated it is more focused around searching images than organizing. But why one organizes the photo collection? To be able to find that one photograph. So the strong searching capabilities are equally important for the target functionality, plus it has most of the image cataloging functions you would need.
Not that it is the best img cataloging tool under the Sun, but it is still interesting one.

#

They have released the source for 0.90 and binaries will be available soon too.

In regards to your problems with exif data, I think it is a problem with your system as I've never had any problems reading exif data.

#

I completely agree with your evaluation of Gqview. I use it in an Xfce environment, where it integrates very well.

#

Yes true; the current version will not manage pictures in-place. The Settings allow you to configure one Album Library Path (<a href="http://docs.kde.org/stable/en/extragear-graphics/digikam/using-kapp-setup.html" title="kde.org">http://docs.kde.org/stable/en/extragear-graphics<nobr>/<wbr></nobr> digikam/using-kapp-setup.html</a kde.org>) into which it copies all the pictures. And the import/add feature does not offer you a choice about copying/leaving images in place. You could change the Album Library Path to point to a directory where your photos already reside -- though you cannot do this through the import/add tools -- but that is only tricking DigiKam into not copying the files. You should have the choice to work with all of your images in-place. DigiKam gives you no choice in the matter -- that is the problem. Changing the Album Library Path value is a workaround to that problem. But the problem shouldn't be there to begin with.

#

Ok, I see where you are coming from... you'd like to have photos scattered around the filesystem managed by Digikam in a virtual structure. That's fair enough, but that's not quite the same as

DigiKam forces you to copy all of your digital photos into a separate directory in order to work with them

If you keep all your photos under one directory, as I suspect many people do, you are not required to copy or move or even import any photos, which is what your statement implies. Simply setting the album path to the root of your photo collection works fine in that case. I do agree that it might be nice to have a handier way to switch between album sets though.

As someone else pointed out, the particular niche in the KDE world that I think you're looking for is being filled better by KPhotoAlbum. It much more of a virtual album aimed at being able to search and organise photo collections. Digikam is somewhat of a different animal, I think primarily aimed at someone who wants to get pictures off their digital camera, organise them, and perform post processing. While it supports meta tagging and searching, its strength is more in the image manipulation arena.

#

you'd like to have photos scattered around the filesystem managed by Digikam in a virtual structure.

No, I'd like to have all my photos where I currently have them, and have my photo management app(s) (a) make no assumptions about where they should be, (b) not decide that it knows better than I do where my photos belong, and (c) do what I tell it to, and no more.

If you keep all your photos under one directory, as I suspect many people do, you are not required to copy or move or even import any photos, which is what your statement implies.

You are, because when you first import a folder, you are not given any choice about whether to copy them into a special directory -- a setting than you can only change from a different portion of the application. "Import" != "copy." The other apps covered in this comparison do allow you this choice, as do the proprietary alternatives (including the expensive ones like Aperture); it is a shortcoming in digiKam.

As to subtle implication that the only alternative to keeping all your images in one hierarchy is to "have them scattered around the filesystem" -- no dice. Even when you have all of your digital photos organized in one hierarchy, the photo management app must be able to cope with your need to manage other sources. In the real world, you will have other images that you occasionally or even frequently need to index, search, and find. I deal with screenshots on a regular basis. I often have photos mailed to me from other people. I create non-photo artwork. None of these types of images belong in the same organized hierarchy as my photo catalog; in some cases I am not the owner; in some cases they are even impermanent.

As for the suggestion (and I'm not attributing this to you, personally) "well the first time you ever run DigiKam, you should just already know to go to the general preferences tab under Settings -> Configure digiKam and change the Album Library Path variable before you ever import any photos" -- well that's clearly retroactive logic attempting to rationalize the lack of flexibility in the app. In actual usage, the choice belongs in either (a) the first-run-wizard, or (b) the import stage dialog, or (c) preferrably both.

But the thing that makes it even worse is that most of us will use multiple applications to sort or manage our images over the lifespan of these files, and all of the apps that presume to "choose for you" pick a different directory name. DigiKam chooses<nobr> <wbr></nobr>/home/you/Pictures, F-Spot chooses<nobr> <wbr></nobr>/home/you/Photos, and so on.

Sometimes you just want to shout "Hey! Software! It's my data, I know where I want it, back off!"

Like I said in response to the F-Spot comment above, be assured I'm not criticizing your (or anyone else's) choice of preference in apps. If you like DigiKam, great.

#

Even when you have all of your digital photos organized in one hierarchy, the photo management app must be able to cope with your need to manage other sources.

Disagree. I'd say that a photo management app first and foremost must be able to manage your photographs.

It is telling that after dismissing F-Spot and Digikam, you state a preference for GQview. GQview is a simple image browser, with no ability to download from a camera, handle RAW files, perform even the most basic editing features, all of what I would consider essential in a photo management. GQview is, of course, a decent image browser and does not pretend to be a photo management app. The fact that it fits your needs better than photo management apps tells me that you aren't after a photo management app.

In the real world, you will have other images that you occasionally or even frequently need to index, search, and find.

I use the a more appropriate tool for that job - KPhotoAlbum. I use Digikam to download, organise, and postprocess photos from my cameras. Don't complain that a hammer sucks because it can't drive screws.

I deal with screenshots on a regular basis. I often have photos mailed to me from other people. I create non-photo artwork. None of these types of images belong in the same organized hierarchy as my photo catalog; in some cases I am not the owner; in some cases they are even impermanent.

As I suggested above, Digikam is not really the tool you are looking for, for your particular set of use cases. KPhotoAlbum is much closer to that.

Digikam is for managing the photos from your digital camera, as the name might suggest. It's not perfect, but it hardly is crippled as you seem to make it out to be, especially for its intended purpose.

I do like Digikam, for a lot of things, and I feel that you are misrepresenting it to a certain extent, such that potential new users might be turned off by your assertion that you need to import (copy) photos in order to use it. You clearly do, since that's the way you want to use it, and the way you expect it to work.

Every version that I have every used, including the current one in Ubuntu's repository that I just installed to check, prompts you for the location of your photos on first use. For many users using Digikam painlessly is just a matter of selecting your equivalent of "My Photos" on your hard drive the first time you start it up.

A lot of this depends on your definition of "Photo Management". If you want to organise and work with the photos that come off your camera(s), then Digikam is pretty good. If OTOH you want to index, sort, and catalogue images including photos, digital art, screenshots, clipart, etc, then digikam is not the right tool.

It seems to me that you have a very focused set of requirements in what you consider a photo management app, which is probably not typical. This review might have been better if you'd laid those out in more detail at the beginning.

#

"Your need to manage other sources" means your need to manage photos no matter how they get onto your system. A single, digiKam-only folder is great, as long you never stray from it. But that isn't really possible. More importantly, the reason that DigiKam's behavior is wrong is that is forces the user to adapt to the app's expectations. It's supposed to be the other way around. But I don't consider DigiKam's copying files without asking to be its major feature, nor even its major problem. It's simply the one that your initial comment claimed was not there.

I did not "dismiss" DigiKam and F-Spot, I pointed out their pros and cons. I did the same thing with GQview. And what I recommended was not GQview, but Picasa.

Speaking of definitions, this:

handle RAW files, perform even the most basic editing features, all of what I would consider essential in a photo management.

describes an image-editor, not a photo manager. Pulling the files off the camera is also not photo management. If you want to look around for a definition of photo management, go right ahead. It's well understood. The principle task of a photo management app is to enable the user to find particular photos -- whether they are looking for a single photo, any photos of a certain type, or all photos that match a given criteria. The criteria on which people look for a match varies widely: content, date/time, keywords, subject, shooter, camera type, location, whether it was day or night, indoors or outdoors -- whatever. That is what photo management is.

About Kphotoalbum, I already addressed that in <a href="http://applications.linux.com/comments.pl?sid=37738&cid=93990" title="linux.com">another comment</a linux.com> above (namely: it's not stable). As to the other question, whether the KDE project is appropriately promoting Digikam over and above Kphotoalbum, that is for them to answer. My take on the situation is that KimDaBa/KPhotoAlbum has been undergoing enough upheaval that it does not make for a good "bullet point" app; that plus the fact that it shares a lot of the same plugins with DigiKam means they can advertize with DigiKam.

And if DigiKam is not a photo management app at all, <a href="http://www.digikam.org/?q=about" title="digikam.org">I hope somebody tells the digiKam team</a digikam.org>.

Regarding the notion that an article or review somehow "damages" an open source app by shedding light on its shortcomings, nonsense. Bug reports aren't hurtful -- they're helpful, and it is in everyone's interest (meaning the developers and the users) to talk openly about the pros and cons of apps. That's how we find solutions. Like I said in the closing paragraph: the great thing about open source is that it is continually improving.

#

DigiKam forces you to copy all of your digital photos into a separate directory in order to work with them.

Not true. You can easily set the working directory in the preferences, and I believe on first use as well. I use Digikam regularly, with several different trees of photos, including some on removable media.

#

For browsing pictures and simple touch-up on Linux, especially involving RAW formats, I feel LightZone should be mentioned.

LightZone is proprietary, but it's free. You manage your own images, it just browses files. It doesn't have a database for searching, and it doesn't help get images out of your camera. But it does know about RAW and it's great for browsing, printing, retouching, and converting formats.

It's at <a href="http://sonic.net/~rat/lightcrafts" title="sonic.net">http://sonic.net/~rat/lightcrafts</a sonic.net>

#

If you got at least 1G of RAM

#

because picasa is a wine-based port, it runs extremely slowly and crashes on many systems.

#