The Grumpy Editor's Guide to Image Management Applications
This article is part of the LWN Grumpy Editor series. |
The technology of photography has moved forward in recent years, but certain issues remain. Your editor's closets contain numerous binders full of carefully organized negatives, contact sheets, and slides. Said closets also contain several boxes full of rather less carefully organized photographic output. There's a lot of great pictures there, but chances are good that nobody will ever see them. Organizing photographs is hard.
Now your editor's hard drive looks rather like those boxes in the closet; several years worth of digital photos have accumulated in a messy directory hierarchy with no easy way to find anything of interest. The move to the digital format has, if anything, made the mess worse. How can one cope with all those images? Your editor decided that there must be a free application out there which might help; here is what he found.
Features to look for
Any graphical file manager can enable mouse-based navigation through a directory tree full of images. An application tuned to image management, however, should offer more than that. Anything that can be done to help find a specific image - searching by date, where the picture was taken, who is in it, etc. - is more than welcome. One should not have to dig through a huge box of photos to find that darling shot of one's toddler performing gravity research with the new laptop. This sort of searching requires the creation and maintenance of metadata for images; a good application will make that task easy.
Images from digital cameras include a significant amount of embedded data in the exchangeable image file format (EXIF). The EXIF data can contain the date and time of the picture and a great deal of information on the state of the camera. An image manager should provide easy access to that data, and make use of it when appropriate.
Image management also involves various types of image manipulation. At the simple end of the scale, this means quickly getting rid of the unsuccessful (or incriminating) shots, and, perhaps, changing the orientation of portrait-mode shots. Your editor has found that the family does not always appreciate receiving full-resolution images from his 7 megapixel camera, so the ability to rescale images is needed. Cropping is another common task, both to remove uninteresting imagery or to fit a specific aspect ratio. From there, one can get into color balance tweaking, red-eye removal, noise removal, in-law removal, and advanced psychedelic effects. A good image manager should make the simpler tasks quick and easy, and the harder tasks possible - even if that just involves dumping the user into the Gimp.
An image manager should work well with the rest of the system; it doesn't necessarily help to fix up an image if you can't find the result afterward. An image manager which claims ownership over images and makes them hard to find outside of the application is making life harder. Similarly, some graphical users may appreciate a "move to trash" capability, but the more grumpy among us still like files to simply go away when asked, and have no use for a trash can; an image manager should be able to make files just go away. A good image manager will make printing easy, including selecting high-quality modes, printing multiple images per page, etc. An added bonus for some users might be the ability to quickly create a web page with a set of images. The ability to write a set of images to a CD might also be useful for some.
Your editor reviewed five image management applications, and spent a long day valiantly trying to build a working version of a sixth. Each tool was used to work with its own copy of a directory hierarchy containing about 3000 photos taken over many years. This has been a fun project; there is some good work being done in this area. Free image management tools are still in a relatively primitive form, however; some of them are maturing quickly, but there is some ground yet to cover.
digiKam
Your editor reviewed DigiKam once before,
as part of a previous article on
camera interface tools. We'll return to digiKam (and
gthumb, below) to examine its image management capabilities. DigiKam is a
KDE-based application under active development; version 0.7.2 was released
on March 4.
DigiKam wants to organize images into "albums." An album is a simple directory full of image files, though digiKam goes out of its way to hide that fact. Files can be "imported" into an album from anywhere; if the file comes from outside the album's directory, however, a copy will be made. The importing process for a large tree of images can be slow, but it only has to be done once. A binary file (digikam.db) appears to track all of the albums known to the application.
The digiKam window shows a pane with the album hierarchy, and a large area with thumbnails from the currently-selected album. By default, the thumbnails are annotated with the size of the image (only); the presentation used consumes a relatively large amount of screen space. Double-clicking on a thumbnail will produce a new window displaying the image itself.
The left-hand pane also includes an area called "My Tags." A few predefined tags ("Events," "People") exist; adding others is easily done with the menus. Clicking on a tag will bring up all images which currently have that tag assigned to them. There appears to be no way to get a view of more than one tag at once. Tags are hierarchical, but there is no inheritance by default. So, for example, if you create tags for each family member under "People," and assign those tags to images, clicking on "People" will not display any of those images. There is a configuration option to change this behavior, however.
Assignment of tags to images is done by way of a right-button menu attached to the thumbnail images. There is also a separate "comments and tags" dialog which, in addition to tag management, allows comments to be associated with images. Both comments and tags are displayed underneath each thumbnail image.
Other dialogs available from the thumbnail view include a "file properties" window and an EXIF information browser. The properties dialog allows the name and permissions of the file to be changed; it will happily make an image file setuid if you ask. There is also a histogram display which gives information on color distribution in the image. The EXIF browser provides full (read-only) access to the metadata stored within the image file; it has a help window describing (briefly) what each EXIF field means.
The image window displays the picture itself, and provides a set of editing options. Rotation, resizing, and cropping are done here; there appears to be no way to constrain the aspect ratio of a cropped image. Rotation of images in digiKam is not optimal: each image must be brought up separately in the image window, rotated, then saved. When you've just pulled dozens of images from your camera, you would like a quicker way to get that job done. Your editor's research indicates that the image window rotation is not lossless. There is said to be a plugin available which can do lossless rotation, but your editor was not able to get it installed.
Printing is a big hole in digiKam's capabilities. There appears to be no option to print multiple images at once (much less N-per-page capabilities). The image view window can print a single image, but it requires the user to type in a print command. At this point in the development of the Linux desktop, we can do better than that.
Like most KDE applications, digiKam is highly configurable; most users will want to tweak at least a few options. By default, digiKam wants to use a "trash can" when asked to remove images, but it can be convinced to simply delete them instead. There is also a plugin mechanism which can be used to add image editing tools.
In summary, digiKam is a capable and useful tool with a few remaining shortcomings. Given its pace of development, chances are that those issues will be ironed out in short order.
f-spot
Perhaps the newest entry into the image management space is f-spot, currently at version 0.0.12. It is a Mono application, written in C#. Despite its youth, f-spot already shows considerable promise, and is a useful application.
f-spot does not bother with albums, directories, or any such nonsense.
Instead, it implements a single, time-sorted stream of images with the
ability to sort on various types of metadata. Images must be imported into
f-spot before use, and the import process can be quite slow. After the
import process, the user gets a window with a list of tags on the left, an
information area on the bottom left, and a large pane with (possibly
thousands of) thumbnails. The thumbnails are not rendered until needed,
thankfully.
A feature unique to f-spot is a timeline at the top; clicking on a given month will scroll the thumbnail window to pictures taken on that date. The timeline is not updated when the thumbnail window is scrolled, however, so the two can get out of sync. The sorting of images depends on the date stored in each image's EXIF data; if that data does not exist, the images are given the current date. There appears to be no way to fix an image with a missing date, so it will be forever displayed in the wrong place.
Clicking on a thumbnail causes the lower-left window to be updated with information on that image - date, resolution, and exposure information. Once an image has been selected, a number of editing options are available, including color manipulation, focus adjustment, and rotation. It is possible to select multiple images (by holding down the control key) and rotate them in a single operation.
There is a separate window which can be requested (from the "View" menu) to look at the EXIF information stored in an image.
f-spot allows the user to assign tags to images in a manner very similar to digiKam's. The application also implements the concept of "categories." Your editor was not able to figure out what categories are supposed to do, and how they relate to tags. It was impossible to create new top-level tags (or categories). In general, the tag mechanism appears to need a little work. At the basic level, however, it functions just fine: clicking on a tag will narrow the thumbnail to images with that tag assigned; it is also possible to narrow further to a specific date range.
It would be nice to be able to automatically attach one or more tags to images when they are imported.
Double-clicking on a thumbnail replaces the thumbnail pane with the
selected image. It is, thus, not possible to view the thumbnail directory
and a specific image at the same time. At the bottom of the image window
is a line clearly intended for the entry of comments (though the comments
are used nowhere else). There is also a pulldown for the desired aspect
ratio; using the mouse, a box (constrained to the chosen ratio) can be
drawn over the image, and a click on the scissors icon will crop
accordingly. There is a red-eye removal option; the user must first select
an area to be affected. In your editor's experience, the selection must be
done very carefully, or the red-eye removal will leave obvious artifacts.
Given the nature of the task, it would be nice to be able to select
elliptical areas, rather than squares, for red-eye removal. There is also
a color editing dialog available. Nicely, the mouse wheel will quickly
zoom the image in and out.
f-spot handles image editing in an interesting way. The original image is never overwritten; instead, f-spot creates a new version (called "modified" by default). Different versions are selectable via a pulldown in the image information area. Since f-spot seems to assume you'll never do anything with the files directly, it feels free to give modified versions names like "dsc00450 (Modified (2)).jpg".
There is a full set of "export" options for getting images out of f-spot. Images can be exported, for example, to Flickr, to a web gallery, or burned to a CD. The CD writing process seems to work, though some things are unclear - does the program write the original form of an image, or the modified form? The printing support in f-spot is minimal, relative to some of the other tools reviewed here; there is little control over layout and it is easy to get it to attempt to print pages which do not fit on the paper.
f-spot shows some clear potential, especially for those who like the "tagged flat" method of organizing things. Its youth is apparent, but it would seem to be growing up fast; f-spot is worth watching.
flphoto
flphoto is a simple image manager based on the FLTK toolkit. It may be suitable for those looking for a lightweight application, but it has been left behind by the competition in a number of ways. Your editor also found this application relatively easy to crash. Version v1.2 was released in January, 2004; there does not appear to have been a great deal of development activity since then.
Like digiKam, flphoto works with the concept of "albums," into which photos
must be imported. Unlike digikam, however, flphoto cannot import a whole
directory hierarchy at once; instead, each directory must be fed to the
application separately. An album itself is really just a ".album"
file which contains a list of image file names.
The flphoto window consists primarily of an image viewing area. Thumbnails are presented in a long, horizontally scrolling window at the bottom; they show up in the order in which they were imported. Clicking on a thumbnail brings the image itself into the main part of the window. To your editor's eye, the quality of the image rendering is poorer than with other applications.
Some image editing options are available, including rotation, scaling, cropping (with aspect ratio constraints), sharpening, and red-eye reduction. There is an "edit" option which fires up the GIMP on the selected image. There is no way to rotate multiple images at once. There is a "properties" window which shows basic EXIF information and allows the entry of comments; those comments are not used for anything, however. flphoto has no concept of tags, or of searching for images in any way.
Printing works well, with a fair amount of flexibility in how images are printed, and even a simple calendar generator. There is a function for exporting images to a web page; flphoto is not able to burn images to a CD.
Overall, flphoto is a tool with some capability, but your editor would recommend that people looking for a new image management utility look elsewhere.
gthumb
gthumb is a GNOME-based application; in many ways it is the most fully-featured of the set. Unlike many other image management applications, gthumb is very much directory-oriented. It is happy working with any directory tree it is pointed to; no need to create albums, import pictures, etc. It thus works well for people who use other applications in their directory hierarchy, or for those who simply want to get started quickly.
The main gthumb window should look familiar by now; it has the usual
directory pane and area full of thumbnails. The gthumb "folder" pane only
shows one level of the hierarchy, however, which increases the amount of
clicking required to wander around in a directory tree. A number of
operations can be applied to images in the thumbnail view; these include
lossless rotation, series renaming, and series format conversion. There is
also a tool for locating duplicate images.
Double-clicking on a thumbnail brings up the image view; it is not possible
to have thumbnails and a full image on the screen simultaneously. EXIF
information is available in the image view - if you happen to tell gthumb
to show "comments." There are reasonable tools for scaling and cropping
(with aspect ratio constraints), and a number of more advanced (but not
always useful) image manipulation capabilities. There is no red-eye
removal, however.
Tags in gthumb are called "categories"; they are not hierarchical. gthumb supports comments on images; it also maintains the location of the image separately. Dates for images are supported; they can be taken from the EXIF information, the file date, or entered manually. The default, however, is "no date," even if the image has EXIF metadata; getting gthumb to actually use that metadata requires bringing up a dialog for each image. There does not appear to be a way to change that unfortunate default.
gthumb has the most complete image searching capabilities of any of the tools tested; if you take the time to enter metadata for your images, quite a few search options are available. Searches can be done on any subset of the file name, the image comment (it greps for substrings), the location, the date (on, before, or after - there is no way to specify a date range bounded on both ends), and the categories assigned to the image. If you want to look for all pictures of Aunt Tillie taken at home since the beginning of the year, gthumb can do it.
While gthumb normally works with the directory hierarchy, it also implements "catalogs," which are its version of albums. Images can be added to multiple catalogs at will. A special catalog contains the results of the most recent search; those images can be added, in bulk, to another catalog if desired. Thus, the search mechanism can be used to create catalogs relatively quickly - if you have your metadata in place. "Libraries" can be used to create hierarchies of catalogs.
Printing support in gthumb is flexible, with the ability to print up to 16 pictures per page. What gthumb lacks (as do all the others) is the ability to specify advanced printing options, such as print quality and paper type. Since that is just the sort of thing one might want to adjust when printing photographs, this omission is a true shortcoming.
KimDaBa
KimDaBa (the KDE Image Database) is the final tool which your editor was able to make work. It has some powerful capabilities, but could benefit from some usability work. KimDaBa 2.0 was released in October, 2004.
The first time a user runs KimDaBa, it asks for an image directory; all images managed by KimDaBa must be kept underneath that directory. If the number of images is large, the import process can take a very long time. When, eventually, the user quits the application, it will ask "do you want to save the changes?" without specifying what the changes are. If the user elects not to "save the changes," KimDaBa will not write its special XML file, and the whole import process must be done again the next time.
As it turns out, if you modify an image, KimDaBa will happily exit without asking about saving changes, and those changes will be lost.
The initial window is dismayingly textual for an image manager. It gives a
few entries with names like "Folder" and "Locations"; the bulk of the
window, however, consists of lines like "View images (1-100) 100
images." Clicking on one of those lines will bring up a thumbnail view
with exactly 100 images in it. Images are sorted in no clear order; it has
little to do with the date or the underlying directory structure. The
default background is black (that can be changed), which is a little
jarring.
KimDaBa does provide other ways of sorting images. The "Folder" line will yield a flattened, directory-oriented view. Users can assign three types of tags to images: "persons," "locations," and "keywords." 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. The "search" line pops up a dialog which enables a search for a combination of tags. 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.
Clicking on an image pops up a window with the full image view. The image
window has options for assigning tags to images and for performing
rotation; there is no way to do rotation from the thumbnail view. There is
also a button on the properties window which will delete the image.
Amusingly, KimDaBa
offers a "draw on image" option; it allows the user to add arrows, circles,
and squares (in black only) to the picture. It is not clear how this
capability would be useful.
KimDaBa does not provide a way to get at an image's EXIF information, though it is able to use the date found there. In fact, the application will not even display an image's resolution; there seems to be no way to get that information. There is also no option to resize an image.
There is a bizarre "lock images" function which causes the application to refuse to display them until the password is entered. Said password, as it turns out, is stored, in plain text, in the "index.xml" file. It would be better to leave out this sort of option; all it provides is a false feeling of security.
KimDaBa offers no printing options at all, no web page export, and no CD burning. There is an export operation; it creates a special file which can be imported into KimDaBa running on another system.
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.
Conclusion
One application which your editor was unable to make work is imgSeek. It is a Python program; its unique feature is the ability to look for images which are similar to a drawing made by the user. Version 0.8.4 of imgSeek was released in September, 2004; development seems to be quite slow since then. The version of imgSeek in Debian sid does not run as of this writing. Your editor hopes that imgSeek is able to move forward; this application's developers are trying to do some interesting things.
In general, there is a lot going on in this area. Clearly the time has come for the free software world to produce some high-quality image management applications.
That said, none of the tools reviewed here can truly be said to be
complete, and your editor will resist the temptation to pick a "winner"
from the set. Printing support is, perhaps, the weakest area at the
moment; Linux now has the capability to provide a great deal of control
over printing, but the image managers are not yet using it. Still, the
applications reviewed here have reached the point where they are useful
tools. It will be fun to see where they go from here.
Posted Apr 18, 2005 17:33 UTC (Mon)
by cantsin (guest, #4420)
[Link] (3 responses)
Posted Apr 18, 2005 17:36 UTC (Mon)
by cantsin (guest, #4420)
[Link]
Posted Apr 19, 2005 15:27 UTC (Tue)
by coolian (guest, #14818)
[Link] (1 responses)
Posted Apr 28, 2005 23:19 UTC (Thu)
by yem (guest, #1138)
[Link]
One thing I wish it had was support for loading raw digital camera files via dcraw. If that were possible, it would enable users to select a set of files, and send them off to, say, ufraw for colour processing and conversion to jpeg. UFRaw is great, but it's missing a nice interface for selecting images and initiating the batch processing.
Is anyone seriously working on dcraw support for either gqview or gdk-pixbuf?
Posted Apr 18, 2005 18:22 UTC (Mon)
by havoc (guest, #2261)
[Link] (17 responses)
A bit of internal fussing and mussing brought me to the analogy of a similar comparison between vim and emacs from the point of view of someone who has never used anything similar. I can imaging text something like this: "These are not editors! These are software torture devices. This garbage is not possibly usable by any human!"
I'm betting that users of the other software feel similarly short changed. It must have been a long, painful day for Mr. Grumpy. These five packages take mostly different approaches to the issue of image management. I can't imagine trying to grasp those concepts in just a few hours. Makes my head hurt.
That said, KimDaBa is an image management tool only. Rather than trying to do a half-baked job of editing, cropping, printing, etc., Jesper (the author of KimDaBa) has chosen to focus on image management, and leave the other tasks, done so well by other apps, to other applications and their teams. If I had the skill, I would write an article about KimDaBa and submit it for inclusion in a Defensive User's Guide for LWN.
Posted Apr 18, 2005 22:15 UTC (Mon)
by hp (guest, #5220)
[Link] (9 responses)
Havoc
Posted Apr 19, 2005 2:17 UTC (Tue)
by wjhenney (guest, #11768)
[Link] (7 responses)
Posted Apr 19, 2005 13:14 UTC (Tue)
by hp (guest, #5220)
[Link] (6 responses)
Posted Apr 19, 2005 14:02 UTC (Tue)
by havoc (guest, #2261)
[Link] (5 responses)
Posted Apr 19, 2005 14:32 UTC (Tue)
by wjhenney (guest, #11768)
[Link]
Posted Apr 19, 2005 15:29 UTC (Tue)
by coolian (guest, #14818)
[Link] (2 responses)
Posted Apr 19, 2005 17:52 UTC (Tue)
by havoc (guest, #2261)
[Link] (1 responses)
Posted Apr 19, 2005 19:55 UTC (Tue)
by berntsen (guest, #4650)
[Link]
Just happened to have gotten that link from a friend the other day (and I read on to see the havoc problem), thought it was funny to stumble over this confusion thingy afterwards. They world is "small", probably comes from results of random graph theory (7, I think to recall, handshakes on average between any two people on the earth).
Well, its probably just me being weird and shying away from work at this late hour.
Cheers,
Posted Apr 21, 2005 13:34 UTC (Thu)
by nhasan (guest, #1699)
[Link]
Posted Apr 19, 2005 0:30 UTC (Tue)
by corbet (editor, #1)
[Link] (6 responses)
Posted Apr 19, 2005 13:25 UTC (Tue)
by sitaram (guest, #5959)
[Link] (4 responses)
Great article as usual, but maybe I can add something here.
(1) where's the "in-law removal plugin" ? :-)
(2) gqview + kimdaba (hot keys to GIMP from gqview when needed) is what I use. The duplicate search in gqview is really something!
(3) kimdaba: read on...
KimDaBa's best feature is the drill down/incremental search. Lets just use the 3 default categories (keywords, location, person), although you can add your own categories and all the stuff below still applies.
Say I click on the keyword link, which shows me a choice of all the possible "keywords" there are in the system. I click on one of those keywords (say, "parties"), then the whole view changes to show only the subset of the photos that have that keyword. Now click on locations, say, and then on one particular location (say "Wynkoop") and you've subsetted it further. You get the idea...
If that's not good enough, there's a fairly neat search dialog with AND and OR searches (within each category).
Makes searching REALLY fast and easy, but there's no way you could have annotated 3000 photographs in one afternoon to actually get the benefit of this, so I can't honestly blame you or feel upset that you didn't like it.
Posted Apr 19, 2005 15:46 UTC (Tue)
by halla (subscriber, #14185)
[Link]
Posted Apr 20, 2005 18:07 UTC (Wed)
by abredon (guest, #2038)
[Link] (2 responses)
That's the problem I personally have with kimdaba - it's too slow at organizing.
None of the current Free Software Image Database programs (that is what I call this type of program) meets my needs at the current time, and most seem to be headed in the wrong direction by adding unneeded features like rotation and editing (that many other programs do well) at the expense of the single most important feature - quick categorization (which no Free Software does well yet).
Posted Apr 21, 2005 14:26 UTC (Thu)
by wjhenney (guest, #11768)
[Link] (1 responses)
Posted Apr 21, 2005 21:06 UTC (Thu)
by abredon (guest, #2038)
[Link]
I hadn't seen that dialog, and it is significantly better than what most of the other Free Software programs provide, but it takes 1 second to change from image to image in that dialog. Imatch takes under 1/10 second to change images, and I can select multiple images and skip from image to image out of order if I want. Also, the only thing I can do in the (modal) Edit Comments & Tags dialog is edit comments and tags. In IMatch's (non-modal) Category Assignments window, I can be assigning tags, notice that one image needs rotating, rotate it and continue assigning tags. I can then see that another image is completely ruined, delete it and continue assigning tags, all without losing my chain of thought.
Digikam is much better than the other Free options (and is on a par with many commercial programs - I consider it equivalent to Picasa, for example), but is still nowhere near good enough for what I need - the user interface gets in my way. With IMatch, I can sit down for 15 minutes before going to bed, and quickly categorize 300-400 images. When the Free programs get close to that point (i.e. when I can sit down and classify 50-100 programs without losing my train of thought), I will switch.
Posted Apr 19, 2005 14:12 UTC (Tue)
by havoc (guest, #2261)
[Link]
I am not much of a writer, but I try. I have started a "Defensive Users' Guide" to KimDaBa, which I hope to be able to submit to you. My hope is that "DU's" of the other programs mentioned here will also submit DUGs to you. I think it would be enlightening to see how users familiar with the software differ from your overview of a class of software. We, as users, have the advantage of familiarity, time and focus. My goal is to be non evangelistic about the software, but informative. I think a DUG would be an interesting counterpoint to your wonderful "Grumpy Editor's" pieces.
Posted Apr 18, 2005 19:45 UTC (Mon)
by Richard_J_Neill (subscriber, #23093)
[Link] (1 responses)
Personally, I use gthumb to quickly rotate/rename images off the camera, then use AlbumShaper to generate an album. Incidentally, you also mised out Gwenview.
Posted May 10, 2005 16:31 UTC (Tue)
by wstokes (guest, #29845)
[Link]
Posted Apr 18, 2005 21:19 UTC (Mon)
by gilb (subscriber, #11728)
[Link]
Posted Apr 18, 2005 21:41 UTC (Mon)
by pizza (subscriber, #46)
[Link] (8 responses)
My collection has grown to well over 10,000 photos (21 gigs!), and is currently growing at about a gig a month. That's what I mean by scaling.
I also need the ability to publish stuff online, and keep the two in sync.
And let's not forget about web-based apps. While there are a lot of "online gallery" tools, only a handful are really designed to manage images as opposed to "share photos" or whatnot.
I ended up settling on Photo Organizer, (http://www.k-i-s.net) which is web-based and uses PostgreSQL as its backend. Its feature set is modeled after commercial image management tools that professional photographers use.
The feature which sold me on it was the distinction it makes between folders of images, and albums, which are arbitrary views into these folders. An image resides in one folder, but can be displayed in any number of albums. This makes it easy to create categorical views.
Another added benefit is that since it's a [real] SQL database on the backend, you can do some truly insane things with bulk updates and other advanced queries. Nevermind the benefit that an app crash won't hose your metadata backend.
Unfortunately, I've had to make so much use of the SQL backend because PO's current interface for bulk updates is crummy to non-existant -- but that's the main feature slated for the next release. (...along with a pile of other stuff I've added or fixed to satisfy my own itches)
It's worth a look.
Posted Apr 19, 2005 5:24 UTC (Tue)
by astrophoenix (guest, #13528)
[Link] (4 responses)
that being said, I have a long set of work ahead to get all those images tagged with keywords,
Posted Apr 20, 2005 2:19 UTC (Wed)
by allenp (guest, #5654)
[Link] (3 responses)
I've got about 13,000 images and about 3000 lines of perl/Tk to manage
The big problem is to keep up with the tagging. I've had some sort of
I'd like to thank the grumpy editor for a great conversation-starter. The
I've always intended to release my ImageTool at some point if it ever
Paul Allen
Posted Apr 20, 2005 14:16 UTC (Wed)
by pizza (subscriber, #46)
[Link] (2 responses)
Looking at Freshmeat, I'd wager quite a few. :)
>I'd like to thank the grumpy editor for a great conversation-starter. The
Have a look at _exifiron_, part of the _photomolo_ suite. Its purpose is to, well, iron out the images, performing (completely lossless) rotation including updating the EXIF data to reflect the new orientation, strips out EXIF thumbnails, and adjusts the file timestamps to reflect the EXIF timestamp. Oh, and losslessly recompresses the images to use less space -- On average, it's shaved about 10% of the file off. When you're talking about 10K images or so, that space savings really adds up (two gigs in my case!).
> I've always intended to release my ImageTool at some point if it ever
Oh, you know it'll never be "stable". :) And you never know who else will pick up the ball.
Posted Apr 22, 2005 2:03 UTC (Fri)
by allenp (guest, #5654)
[Link] (1 responses)
Yep. I use exifiron for lossless cropping, rotation, or both.
>> I've always intended to release my ImageTool at some point if it ever
>Oh, you know it'll never be "stable". :) And you never know who else will >pick up the ball.
When it's stable enough that someone who's unfamiliar with the
Paul Allen
Posted Apr 22, 2005 13:54 UTC (Fri)
by pizza (subscriber, #46)
[Link]
jpegtran has issues with every digicam I've owned.. it always left a strip on the side of the image unless I used the --trim option. So I ended up getting a lossy rotation. I was rather happy to discover exifiron got it right.
Posted Apr 19, 2005 11:22 UTC (Tue)
by Luud (guest, #21831)
[Link] (1 responses)
Yes, I like PO too. Currently I'm working with Balint (the PO developer) to create a bulk upload feature that works from the command line. I've also got about 10000 fotos to enter into the database, and my webserver will not be able to cope with that through http.
Also, Balint is now working hard on the bulk update feature. So you can expect that in the next version.
I'm quite interrested in your user tools. Maybe it is a good idea to let Balint know what you are doing with them. I've found him to be very open to other peoples ideas.
As far as scalability goes for gthumb. It works very good for me on handling collections of up to 3000 fotos at a time in a directory tree. Renaming goes fine, although there is one feature they should better turn off: when typing in the new name in the rename series dialog, it kan take quite a while before your screen gets updated when there are lots of images to rename.
Cheers,
Posted Apr 19, 2005 15:26 UTC (Tue)
by pizza (subscriber, #46)
[Link]
As far as bulk uploads.. I feel your pain. It took me nearly three weeks to get all of mine uploaded in roughly 100 meg batches. Of course if I hadn't cared about things like setting the location and whatnot, it would have gone faster. That lack of a bulk update feature, ya see...
But I couldn't wait for the next release. I was already four months behind getting stuff posted (I was using BINS, and it just couldn't scale.. so I'd need an image management app to manage BINS..) so I fired up emacs and started hacking on the PO codebase.
Balint's accepted the majority of my patches, though he hasn't got back to me yet on the last one. (http://www.shaftnet.org/po/ if you want to see what I've done so far)
Posted Apr 19, 2005 11:29 UTC (Tue)
by halla (subscriber, #14185)
[Link]
Posted Apr 18, 2005 22:33 UTC (Mon)
by jec (subscriber, #5803)
[Link] (1 responses)
Posted Apr 18, 2005 22:40 UTC (Mon)
by corbet (editor, #1)
[Link]
But, yes, maybe a followup is in order.
Posted Apr 19, 2005 2:50 UTC (Tue)
by wjhenney (guest, #11768)
[Link] (1 responses)
The operative word here is appears:
unless features have been removed between 0.7.1 and 0.7.2, then
one can simply select multiple images in a given Album or Tag
view and click on
Similarly, batch rotating a bunch of images is just a matter of
selecting them and using the context menu. This works losslessly
for me - on FC3, I just had to
Also, the binary file (digiKam.db) is
actually a SQLite database. Hence, it is dead easy to write
scripts to manipulate the metadata (e.g., making a new tag that
is an intersection or union of existing ones). If only digiKam
would behave like f-spot in renaming modified photos then it
would be perfect (well, maybe a way of exporting to BINS too -
but I think I can script that myself if I find the time).
Posted Apr 19, 2005 16:12 UTC (Tue)
by vmole (guest, #111)
[Link]
...and click on Album->Export->Print Wizard...what a shame that you never found them.
What a shame that the digikam developers chose to ignore two decades of normal practice and bury the printing function anywhere except File->Print. Yes, I understand that printing is implemented as just another export plugin. But guess what? Your users don't care how it's implemented. Something as basic as printing shouldn't be something that the user has to hunt for.
For the record, I use digikam. But it's got some real usability issues.
Posted Apr 19, 2005 4:41 UTC (Tue)
by ncm (guest, #165)
[Link] (2 responses)
What do I want? Buttons next to each thumbnail, one to rotate left, another right. When I click one, I want it to start working immediately (after all, it's lossless, right?) while I go through the rest. It should show the rotated thumbnail immediately, and let me click again at the same image, and have the right thing end up on disk even if it was half-written out already. Of course I need a way to click the same button on a whole course of images; maybe *that* is something the native UI selection trick is good for. Oh, and I want keyboard shortcuts for all this, so I can step from one thumbnail to the next, and hit "L", "R", or (say) "U", and walk through the whole list without fooling with the mouse but once.
I want a red-eye removal feature that, all by itself, identifies pairs of luminous red circles or ellipses, and blackens just them without messing up red shirts or roses (or nipples, or car taillights, either, but I'll take my chances). It might allow its action to be restricted to a subset of the image, similar to a cropping tool, and let you poke at individual eyes you want blackened and non-eyes you want un-blackened.
I want to set up empty columns, each bound to a digit key, and then walk down all the thumbnails and bounce each into its right column with one keystroke. Then let me add a tag to all the images in a column, at once. I should be able to copy thumbnails into more than one column, so a picture may have more than one tag added.
Did even Apple get much of this right? I doubt it.
Posted Apr 21, 2005 10:11 UTC (Thu)
by gc (guest, #24112)
[Link]
I have started a web-album oriented software which takes the same irritation as a starter (among others). As a result, I have come-up with three different easy ways to rotate images: mouse gesture (click, drag a little right or left, release), one-click tools (you select the "rotate clockwise" toggle-button in the toolbar, then one click on each image is just what you need to do the rotation), and right-click popup context menu (this is the most "intuitive" for people not reading the doc and/or not used with the first two ways which are more specific). Of course, I also have keyboard shortcuts to do that.
(shameless self-advert) http://zarb.org/~gc/html/booh.html - not in freshmeat or other places yet because I want to finish all the most interesting features first - which is nearly the case btw.
It's not image-management oriented so doesn't aim at implementing too serious features such as cropping. It's more geared towards people who want to create web-albums _fast_.
About your suggestion or rotation, I think that putting buttons next to thumbnails would take up space better used to display images. Mouse gestures are a more elegant solution IMHO. But that can just be a matter of taste.
Posted May 10, 2005 16:28 UTC (Tue)
by wstokes (guest, #29845)
[Link]
I don't support EXIF data and tagging withing Album Shaper *yet*. It's being developed right now.
-Will
Posted Apr 19, 2005 5:04 UTC (Tue)
by hodoscek (subscriber, #5290)
[Link]
Posted Apr 19, 2005 10:35 UTC (Tue)
by kleptog (subscriber, #1183)
[Link] (4 responses)
The reason I'm suggesting this is that it comes with a program bins-edit-gui where you give the files you want to edit (use find to decide which ones) and it lets you view the image, edit the tags and indicate orientation (which it can do change losslessly).
All the configuration is XML and so is the metadata storage. I have written a few simple Perl scripts to allow me to update various parts. When you later generate your website you can select on these tags.
I wonder if it integrates with any of the other ones, because all up it could be anice combination.
Posted Apr 19, 2005 14:06 UTC (Tue)
by wjhenney (guest, #11768)
[Link]
Posted Apr 19, 2005 15:02 UTC (Tue)
by pizza (subscriber, #46)
[Link] (2 responses)
I did submit a few patches to it over the last couple of years, but making it significantly faster would mean fundamental changes to how it works.. and the code makes my forebrain mutiny.
Posted Apr 20, 2005 3:22 UTC (Wed)
by kleptog (subscriber, #1183)
[Link] (1 responses)
I do think it could be made smarter, like skipping whole directories if they havn't changed but as it is it doesn't maintain enough metadata. I might patch it if it gets on my nerves... If I'm moving directories around I tend to move them in the output directory too to avoid the rescaling.
Posted Apr 20, 2005 14:25 UTC (Wed)
by pizza (subscriber, #46)
[Link]
Posted Apr 19, 2005 11:24 UTC (Tue)
by ekj (guest, #1524)
[Link] (3 responses)
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.
Posted Apr 19, 2005 14:16 UTC (Tue)
by havoc (guest, #2261)
[Link] (1 responses)
Posted Apr 22, 2005 8:57 UTC (Fri)
by ekj (guest, #1524)
[Link]
Posted Apr 19, 2005 14:17 UTC (Tue)
by wjhenney (guest, #11768)
[Link]
Posted Apr 19, 2005 13:29 UTC (Tue)
by a9db0 (subscriber, #2181)
[Link] (3 responses)
This is not accuate. In the main window simply select the images you need to rotate, then right click and select rotate from the popup menu.
Posted Apr 19, 2005 15:50 UTC (Tue)
by a9db0 (subscriber, #2181)
[Link] (2 responses)
Posted Apr 21, 2005 10:18 UTC (Thu)
by gc (guest, #24112)
[Link] (1 responses)
Posted Apr 21, 2005 16:48 UTC (Thu)
by a9db0 (subscriber, #2181)
[Link]
Posted Apr 19, 2005 15:23 UTC (Tue)
by pcharlan (guest, #29128)
[Link] (1 responses)
So a feature I'd look for in a photo management suite is that when I say something's gone, please don't leave any of it behind, and if it's not the only manager of the pic, don't leave anything behind between editing sessions.
Posted Apr 20, 2005 12:13 UTC (Wed)
by cloose (guest, #5066)
[Link]
Alt+F2
Posted Apr 21, 2005 9:47 UTC (Thu)
by ke3z (guest, #4303)
[Link]
I shoot NEF files. There's a patch for gqview that lets you view NEF. And Photo Organizer, which is what I currently use for management, can handle them via dcraw. But which other image management programs handle raw? Any that can't would be useless to me.
Another important feature, one that PO provides, is the ability to keep multiple versions of a photo -- different crops, for example.
Maybe at some point it would be good to review what's available for more substantive work. Actually, a review of digital photography workflow options under Linux would be good, albeit perhaps too large in scope for LWN.
Posted Apr 21, 2005 14:48 UTC (Thu)
by alspnost (guest, #2763)
[Link] (1 responses)
Posted Apr 22, 2005 10:42 UTC (Fri)
by rjw (guest, #10415)
[Link]
Posted Apr 22, 2005 3:50 UTC (Fri)
by gjmarter (guest, #5777)
[Link]
Modern digital cameras have the nice feature that you have a fairly accurate date on every photo. I however, have a big pile of old photographs that I am slowly scanning in to my computer. I would like to have a tool that helps me organize these pictures chronologically.
The general idea would be to have an interface that presents me with two photos whose date order is not known, and the user would identify which photo comes first chronologically possibly recording a rationale. Over time, the database of time relationships would grow and a more complete time line would emerge.
Also, it should be possible to add non-photo events to the time line such as "House painted grey", so that I can have an anchor against where I put pictures with the grey house and pictures with the house still white.
Posted Apr 22, 2005 17:57 UTC (Fri)
by mdhirsch (guest, #5924)
[Link]
Posted Apr 22, 2005 21:00 UTC (Fri)
by evgeny (subscriber, #774)
[Link]
Well, that's a reasonable default ;-). Then, just drag the thumbnails as you like.
> There is no way to rotate multiple images at once.
Select multiple thumbnails (mouse click with Ctrl pressed) and then go to Selected Images->Transform selected->... Shortcuts for the operations are defined, too.
> There is a "properties" window which shows basic EXIF information and allows the entry of comments; those comments are not used for anything, however.
They're used for the web album export and slide shows.
Posted Apr 29, 2005 16:39 UTC (Fri)
by guest01 (guest, #25274)
[Link]
There's a program called exif which is a command-line tool that will allow you to modify exif tags; you could use that tool to set the date in the exif information. The scripts I use to process my images use this command-line tool to set the author/copyright information in all my images.
Posted Apr 29, 2005 16:56 UTC (Fri)
by guest01 (guest, #25274)
[Link]
But they just laughed anyway. And you'd try, valiantly, to explain the "many small programs with pipes" idea and show them the power of a good "grep | cut | tr | sort" command-line but they'd just look at you like you were nuts.
Remember that time? So why is everyone rushing to these all-in-one solve-all-your-problems-in-one-application utilities? Thank goodness for the "old-timers" like ImageMagik which are command-line driven. Anything I can do on a command-line can be placed in a script and performed on hundreds of files while I sleep.
From the moment I started taking digital pictures I've used nothing more than a set of about a dozen or so bash and python scripts to manage my pictures and generate thumbs, reduced images, and create web-pages ready for my server.
No wonder "linux on the desktop" is becoming an embarrassing, bloated eye-sore!
Posted May 1, 2005 11:34 UTC (Sun)
by lbt (subscriber, #29672)
[Link]
It's an _excellent_ tool for managing large collections of images and to be honest it's functionality will best be appreciated by those who've been taking digital photos for a while!
It handles exif very well indeed, has mass processing (eg select 20 photos, type 'a' and enter a comment common to all: eg Holiday June 2004) or select those that need rotating 90deg right and do a lossless jpeg rotate.
It allows good image searches via any exif information - eg enter 'Holiday 2004' and you'll get all your snaps from any 2004 holidays.
I also add a rating to good photos so I can search for all my 'best' photos
It's written in perl (for those who care) and allows powerful extensions/plugins.
Drawbacks:
Just a happy user.
Posted May 25, 2005 11:52 UTC (Wed)
by kayosiii (guest, #30145)
[Link]
gqview is clearly missing in the above list. While it is restricted to
browsing only the contents of one directory, it provides since version 2.0
excellent search and printing functions (including flexbile arrangement of
many pictures on one sheet), display of EXIF data, organisation of images
into collections (independent from their storage location) and a powerful
search function for similar or duplicate images. And above all, it's a very
mature and fast program, also one that can be efficiently controlled by
keyboard and combined with external programs (Gimp, image rotations, custom
ImageMagick scripts) as keyboard shortcuts operating on images.
gqview
I see that "flat" views of images according to their creation date and
views of all images underneath a directory tree are available in the
developer version gqview 2.1.
gqview
I couldn't have said it better. gqview is a program that got it right, gqview
exactly like early 2.xx versions of ACDSee on Windows. Blazingly-fast,
simple UI and Blazingly-fast. It was also pretty speedy.
Easy to use over slower ssh links too.
I love the speed of gqview.gqview
I was shocked at the total non-comprehension of the genius of KimDaBa. After having used KimDaBa for well over a year, I was insulted that Mr. Grumpy didn't even begin to understand what he was looking at when he was looking at KimDaBa.pity
But vi and emacs _are_ software torture devices not usable by any normal person ;-)pity
Hang on, if you are the "real" Havoc then who is the other one? Or are Dr Havoc and Mr Pennington
you so committed to LWN that you bought two subscriptions? I feel like I
have entered the Twilight Zone....
I don't know who "havoc" is, hp = Havoc PenningtonDr Havoc and Mr Pennington
I apologize for the confusion. In one sense, I am an impostor -- in that I am NOT Havoc Pennington. I have used "havoc" as my online presence since ~1989. In that sense, I am "havoc."Dr Havoc and Mr Pennington
OK, thanks for clearing things up. I guess that with 6 billion potential Dr Havoc and Mr Pennington
linux users in the world, then nobody's name is going to stay unique for
ever anyhow :)
And you are creating "havoc" in hp's world. Dr Havoc and Mr Pennington
"Oh, great! Now I have guilt!"Dr Havoc and Mr Pennington
Hm. can't resist making a reference to hp's blog which contains a reference to the "problem" http://log.ometer.com/2005-04.html#9 (not direct link, but search for havoc below).Dr Havoc and Mr Pennington
/\/ (formerly (un)known as nike, berntsen, knb, nberntsen, ...)
Ok...all is good now. I was rather shocked to hear "hp" defending a KDE application so ferociously. Sanity is restored.Dr Havoc and Mr Pennington
So...could you post a paragraph explaining what it is about kimdaba that I missed? I can believe it's there, but I'm too slow to see it. Maybe it's the fault of all that Australian beer.
pity
Jon,pity
Isn't the duplicate images thing a kipi plugin? I used it from Digikam to weed out the duplicates pity
of my images. Is it really only three years ago we got that digital camera? Seven or eight
thousand pictures later...
>but there's no way you could have annotated 3000 photographs in one afternoon to actually get the benefit of thisToo slow
With the program I currently use (IMatch - a Windows program), I can sift through and tag over 1,000 images in under 1 hour - this includes putting each image into all applicable subcategories of 5 main categories (location, subject, image quality, process, and things in the picture).
The reason I can categorize this fast is that the tag selection is a tree with checkboxes. I select an image or images, then click on the appropriate checkboxes, then press a key to move to the next image. Each image takes only a few seconds to tag, and there is no wasted time and energy right-clicking to bring up an unnecessary dialog, and navigating down into the hierarchy of tags to find the right tags to assign (by which time I may well have forgotten the context of what I was doing)
Too slow - are you sure?
The reason I can categorize this fast is that the tag selection is a tree with checkboxes. I select an image or images, then click on the appropriate checkboxes, then press a key to move to the next image.
How is this different from how digikam works? This sounds like a perfect description of what you get when you choose "Edit Comments & Tags" from the context menu. You get a persistent window with a big thumbnail of the current image, a text box to write comments in, and a tree view of all your tags with check boxes. Alt-B and Alt-F move you to previous and next image, respectively.
You may be right that kimdaba can't do this (I haven't checked) but I think you should do more research before making sweeping comments like "None of the current Free Software Image Database programs ... meets my needs at the current time". Yeah, I know: there's so many of the damn things and life is short :)
>How is this different from how digikam works? This sounds like a perfect description of what you get when you choose "Edit Comments & Tags" from the context menu.re: Digikam Edit Comments
Mr. Grumpy,pity
One application you missed was AlbumShaper. It's actually rather good, and does the single job of creating a photo album (complete with slideshow/comments) very well. The result is viewable in any web browser.AlbumShaper
It's nice to see AS getting some attention. ;-) In case you're reading this discussion, can you let me know why you prefer using gthumb to rotate/rename your images? These are things Album Shaper tries to do as best as it possibly can. You do know AS supports batch rotation and keyboard shortcuts (Ctrl+R/L).AlbumShaper
-Will Stokes, Album Shaper developer
Jon, thanks for another great article. These really make the subscription worth every penny.Yet another great Grumpy Editor's Guide
So, how well do they *really* scale?Yes, Image *Management* apps.
scale: I have 18,154 images in kimdaba right now. takes less than 1 minute to start up. most Yes, Image *Management* apps.
operations I've tried so far take at most a couple seconds. this is on a 700MHz machine.
etc....
I wonder how many hackers got cameras a few years ago and started work Yes, Image *Management* apps.
immediately on a tool to sort the images?
them. The image database is an XML file that's now up to about 1.5M.
My ImageTool script takes about a second to start, and most of that
is spent creating the GUI. A query that will return the entire database
has the thumbnail view filled in less than five seconds. Smaller queries
are much faster because they only hit the disk for thumbnail display.
tagging capability for about two years, but I've still got piles of
images that have yet to be tagged.
two features I see here that I haven't thought to implement are batch
rotation and searching by EXIF date. Another feature I've got on my list
is the ability to email reduced versions of a selection of images to
friends. The free Google tool does that, I think.
stabilized. With so many strong competitors already out there, I may
just keep it to myself. :-)
> I wonder how many hackers got cameras a few years ago and started workYes, Image *Management* apps.
> immediately on a tool to sort the images?
>two features I see here that I haven't thought to implement are batch
>rotation and searching by EXIF date.
> stabilized. With so many strong competitors already out there, I may
> just keep it to myself. :-)
> Have a look at _exifiron_ ...Yes, Image *Management* apps.
I've fiddled with jpegtran as well, and can't remember what
I've ended up using for what. :-)
>> stabilized. With so many strong competitors already out there, I may
>> just keep it to myself. :-)
code (and may not be a coder) can install it and get it to do
something useful, I'll release it. I get lots of interest
whenever I describe what I'm doing, so I know I'll have no
shortage of beta testers.
>Yep. I use exifiron for lossless cropping, rotation, or both.Yes, Image *Management* apps.
>I've fiddled with jpegtran as well, and can't remember what
>I've ended up using for what. :-)
Hi pizza,Yes, Image *Management* apps.
Luud
I've been trading e-mails with Balint, and I am looking forward to the bulk update interface. I ended up coding up a few hack-ish things to get me by in the mean time though... but I'm also comfortable with SQL, so I do even more directly to the database...Yes, Image *Management* apps.
I've got about 8000 images and Digikam never becomes noticably slow. Yes, Image *Management* apps.
Digikam may present the world an album-like interface, but if you just
add pictures any old how in subdirectories under the digikam image root,
and they get picked up just fine.
And finally... The recent additions to Digikam, such as the CImg based
image restoration (noise reduction, inpainting) plugin or the perspective
correction plugin are just so cool...
IMO, gwenview is the most usable photo management application. It's KDE based and really well done. I think it's a miss to not have reviewed it here.And what about Gwenview?
Perhaps in the Second round? :-)
-jec
I always miss at least one. This time I even announced my intentions (on the digital camera interface article) and looked at what people recommended. In any case, it took a long time to write this article, I'm not sure how many more applications I could have tried.
And what about Gwenview?
digikam's printing is better than that
Printing is a big hole in digiKam's capabilities. There appears
to be no option to print multiple images at once (much less
N-per-page capabilities). The image view window can print a
single image, but it requires the user to type in a print
command. At this point in the development of the Linux desktop,
we can do better than that.
Album->Export->Print
Wizard
. After selecting the paper size and image size
(e.g., 4x6") then it automatically does the N-per-page layout
for you. Also, since it uses KDE's standard kprinter component,
you automatically get access to all the printer options for
paper quality, resolution, and what have you. I find it hard to
imagine how you could improve on digiKam's printing facilities -
what a shame that you never found them!
apt-get install
kipi-plugins
.
digikam's printing is better than that
I find the most irritating thing about all these programs is that they use the native "select and edit" notion built into whatever UI toolkit they were coded under. As a result, when I have 300 pictures taken at random orientations, I have to go through painfully "selecting" the 67 I want rotated left, and then tell it to go ahead, and then wait while it moves all those bits back and forth to disk. Then I have to "select" the 81 to rotate the other way, and then tell it to go ahead, and then wait again. Woe betide me if I ever emit a stray click after selecting 59 of them; I have to start over.Common irritations
> I find the most irritating thing about all these programs is that they use the native "select and edit" notion built into whatever UI toolkit they were coded under.Common irritations
You might enjoy using Album Shaper.Common irritations
-Select one or more photos and click the rotate buttons at the bottom of the screen to batch rotate one ormore.
-Be a power user. Use the arrow keys to navigate and Ctrl+R/L to rotate the selected photo semi-instantly using fast lossless transformations that work.
-Album Shaper provides an intelligent red-eye removal tool. In many cases you can select the entire image and the program finds the eyes and changes just them. Other red objects (like red lips) are almost always ignored.
You can always emerge imgseek to compile on Gentoo, and then worry about other distribution. It worked for megrumpy command: emerge imgseek
I use BINS actually. I know, it's not really an image organiser, it's for generating websites of images. In any case it stores metadata with each image.The Grumpy Editor's Guide to Image Management Applications
Yeah, I love BINS too, or at least the web-page generation part of it. I
think integration with BINS
bins-edit-gui
leaves much to be desired though - I
usually end up editing the XML files directly in emacs. I just made a
start on a python program to export digikam's metadata to BINS' XML
format. Hopefully I'll finish it at the weekend.
I used to use BINS, but unfortunately it doesn't scale too well. I gave up on it when it would take the better part of three hours to generate updated albums when all I did was move a few files around... But I did love the fact that it generated static HTML that needed nothing else to work.The Grumpy Editor's Guide to Image Management Applications
I must agree BINS doesn't scale brilliantly, I only have a bit over 1000 images in it and it does take a little while to regenerate the images. Fortunatly it doesn't rescale/reorientate the images more than once so if you run it often enough it's not too bad.The Grumpy Editor's Guide to Image Management Applications
Even barring keeping additional metadata, there are many, many enhancements that can be done to speed it up. Least of which is "if the jpeg file is older than the XML file, the odds are you don't need to re-parse the EXIF data." This change alone would speed things up considerably. I started to add it in, but as I mentioned before... I think I'd rather give myself a frontal lobotomy with a rusty spoon then wade that deep into the code again.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 Grumpy Editor's Guide to Image Management Applications
ekj, may I have permission to borrow liberally from this? Please?The Grumpy Editor's Guide to Image Management Applications
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.
The Grumpy Editor's Guide to Image Management Applications
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.
kimdaba's strengths
<i>Rotation of images in digiKam is not optimal: each image must be brought up separately in the image window, rotated, then saved.</i>The Grumpy Editor's Guide to Image Management Applications
Sorry. Blasted "Plain Text or HTML" button got me.The Grumpy Editor's Guide to Image Management Applications
or rather, you misunderstand the signification of "preview comment"?The Grumpy Editor's Guide to Image Management Applications
No, I read it, and the content and syntax was fine. I just didn't flip the bit for HTML display. Might have had something to do with the three year old climbing into my lap about then, though.The Grumpy Editor's Guide to Image Management Applications
I discovered a ".thumbnails" directory in my home directory the other day, containing thumbnails of everything I'd opened in the gimp for the last five months, including pics that my girlfriend would rather hadn't stayed on the hard drive unencrypted. I didn't know the gimp did that.Privacy
When you use KDE: Privacy
kcmshell privacy
clear all cached thumbnails
No mention of support for "raw" formats? Which applications can display images from raw (NEF, CRW, etc) files? Not the cheesy low-res embedded thumbnails, but the high-resolution images themselves.Raw support?
So what we really need is for Google to port Picasa (www.picasa.com) to Linux and open source it. Check it out it you haven't seen it, it's very slick. It's a shame that the free software world hasn't produced anything on a par with this yet.Picasa
I don't really get this. Picasa isn't very different than eg f-spot. What killer features do you think Picasa has? It has some I've never heard of anyone use. Picasa
I have a somewhat different form of image management that I would like to see. I have never been able to put any time into developing it though, so I'll post it here in the selfish hope that somebody else wants it too.Looking For A Project?
I use showimg, a KDE app that can use digikam plugins. It would have been Showimg
nice to see it in the review. I find it quite handy and featureful.
> Thumbnails are presented in a long, horizontally scrolling window at the bottom; they show up in the order in which they were imported.The Grumpy Editor's Guide to Image Management Applications
Regarding f-spot:exif
The sorting of images depends on the date stored in each image's EXIF data; if that data does not exist, the images are given the current date. There appears to be no way to fix an image with a missing date, so it will be forever displayed in the wrong place.
Remember way back when, when you first started using Linux/BSD/UNIX, and your Windows friends would laugh at you because emacs/vi didn't have a built-in spell-checker? And then you'd say: "but I've got 'ispell', it works with all my files, why would I want a spell checker integrated into each and every one of the tools I use when I could have one really good independent tool that I can use for all my files?"The "UNIX" way
Can I suggest looking at mapivi : http://mapivi.sourceforge.net/mapivi.shtmlThe Grumpy Editor's Guide to Image Management Applications
It's very fully featured but does have some minor ui fragility issues.
Much better than trying to use folders to arrange them.
* some ui bugs - eg changing directory whilst it's still scanning the 1st
* slow image preview
Assigning "Tags" -- You can also assign tags by selecting a group of Digikam
images and dragging them onto a Tag. You can do a large number of images
more easily using this method.
Rotation of images is best done outside of the image editor (this way it
is non lossy)... Select the group of images you want to rotate. Right
Click -> Rotate -> select rotation.
Printing: Album -> export -> print Wizard...
There are two sets of Plugins for Digikam - Kipi and Digikam plugins...
Much of the functionality that Grumpy editor was looking for is included
in these. Installing them was dead easy on my Mepis Box