User: Password:
Subscribe / Log in / New account

The Grumpy Editor's Guide to Image Management Applications

The Grumpy Editor's Guide to Image Management Applications

Posted Apr 19, 2005 11:24 UTC (Tue) by ekj (guest, #1524)
Parent article: The Grumpy Editor's Guide to Image Management Applications

You missed rather a lot under Kimdaba. I don't know the other apps well, but sadly, if you missed equally much about them, then this review is less than informative. For example:

The first time a user runs KimDaBa, it asks for an image directory; all images managed by KimDaBa must be kept underneath that directory. Nitpick: Or atleast there must be a symlink to the directory holding the images from somewhere under the image-root. But okay.

If the number of images is large, the import process can take a very long time. True. But there's a reason, and it's a good one that deserves to be mentioned: Kimdaba creates and stores an md5-hash of your images, so it will refind and recognize the images even if you move them around or rename them. Thus "playing nice with other applications".

Users can assign three types of tags to images: "persons," "locations," and "keywords." No. Users can assign any number of tags to images, the three you mention are merely the three standards that come preconfigured. Furthermore tags can be made members of other tags ("member groups") so if you like you can for example indicate that "Sally", "Bob" and "Johnnie" are members of "Family". Searching for "Family" would then find pictures containing any of them. Important function, ignored in the review.

There is a separate view for each type of tag, allowing quick access to all photos of a specific person, taken in a specific place, or with a given keyword attached to it. More than that: You can arbitrarily combine. If you want to see say all pictures of Sally in Italy you'd click: "Persons", "Sally", "Locations", "Italy".

There is also the ability to look at all images within a given date range - but the date filtering does not work in conjunction with the tags. Sure it does. Atleast it has in my Kimdaba since a lot longer than 2.0. "Date", enter from and to dates, "Person", "Sally". Will show all pictures with Sally in them from that date-range. Newer snapshot-versions has a zoomable datebar in addition with visual indication of how many pictures are taken in each year/month/week/day/hour (according to how you zoom)

Clicking on an image pops up a window with the full image view. Inaccurate. It opens a window with the size picture configured in the settings, if the image is smaller than this it opens the full image. With a 8MP image you often want something *between* a 64x64 thumbnail and the full 3300*2300 glory.

The image window has options for assigning tags to images yes. But you've overlooked one of the really nice things about Kimdaba, namely the possibility to tag many images at once. This makes tagging a large image-collection orders of magnitude quicker. For example: drag-select all the new images you took in vacation, rigth-click and select "tag all", put in for example "Location" "Italy" for all of them. I've tried other programs where you *have* to do this one-image-at-a-time which is a bloody big waste of time.

and for performing rotation; there is no way to do rotation from the thumbnail view. other than trough plugins, no -- more about this later.

KimDaBa offers no printing options at all, no web page export, and no CD burning. Untrue. These are all offered trough kipi-plugins.

Work continues on KimDaBa; it appears that version 2.1 will include a plugin mechanism (presumably for image editing functions) and a date bar similar to the one provided by f-spot.

The datebar is indeed new. But the plugins are not. Are you sure you're really running 2.0 ?

In general, a few of the complaints are "features, not bugs". For example the lack of scaling or editing-fuctions are fully intentional. Kimdaba follows an explicit goal of *not* in any way touching your images. If you store the xml-file somewhere else it can even work with the images of a read-only medium. This is by design. Many photographers do *not* want a tool that is there for organizing images to start *changing* their images.

Kimdaba can however, trough calling external programs with the kipi-plugins-mechanism (which is shared with digikam and probably will become the standard for image-program-plugins in KDE) do any of the things mentioned in this review, and a lot more. (scaling, rotation, web-export, cd-archiving are all among the existing kipi-plugins, meaning kimdaba and digikam can do them equally)

I'm sorry, but I'm left with the general impression that perhaps this time the review was a *little* bit too quick. Unless you only wanted to present a "first impressions" sort of article rather than an actual guide.

(Log in to post comments)

The Grumpy Editor's Guide to Image Management Applications

Posted Apr 19, 2005 14:16 UTC (Tue) by havoc (guest, #2261) [Link]

ekj, may I have permission to borrow liberally from this? Please?

The Grumpy Editor's Guide to Image Management Applications

Posted Apr 22, 2005 8:57 UTC (Fri) by ekj (guest, #1524) [Link]

Certainly. If there's something in there you find informative or otherwise useful, use it however you like. If you make something about Kimdaba, send me a link or something. I'm curious.

kimdaba's strengths

Posted Apr 19, 2005 14:17 UTC (Tue) by wjhenney (guest, #11768) [Link]

Kimdaba seems to be great at what it does best (efficient tag- and time-based filtering of your image collection) but doesn't compare to digiKam as a general purpose image management app. What would be fantastic would be if kimdaba's features could be provided as a plug-in to be used by digikam. That way, we would have the best of both worlds.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds