A quick grumpy review of Shotwell

By Jonathan Corbet
June 16, 2010

Your editor routinely does a fair amount of photo editing, typically preparing conference pictures for articles or pictures of children for grandparents. In recent years, xv has become less of a tool of choice; it did a number of things right that others still haven't figured out, but it's old, dead, not really free, and unmaintained. Much of this work is now done with gthumb instead. Unfortunately, gthumb has been broken (as in "crashes at start") in Rawhide for quite some time; leaving your editor to look for alternatives. In this context, the relatively new Shotwell application came to your editor's attention. Shotwell is said to be replacing F-Spot as the default photo manager in the Ubuntu 10.10 release, so it seems worth a look.

First, though, a grumpy note on the gthumb problem. The bugzilla entry indicates that this crash is the result of being unable to display 3D effects. Now, as far as your editor knows, gthumb has not yet acquired the ability to work with those 3D cameras which are all the rage. The 3D requirement, instead, comes from a desire to show fancy effects in the "slide show" mode. Bling is nice, but if it kills the ability to use the tool for its very two-dimensional intended task, one needs to question the priorities involved.

Unlike gthumb, Shotwell 0.5.2 is entirely happy to run without access to 3D effects. Also unlike gthumb, Shotwell will not just operate on a directory full of images; one must, instead, "import" images into the application. Importing can be done directly from a camera or from a directory. Obnoxiously, the file browser always starts in the user's home directory regardless of where the application was started - and regardless of where the user imported a directory from moments earlier. The importer is not currently able to deal with images in raw formats.

After being imported, photos are organized into "events," which are just the day in which they were taken. The default view is organized around these events, so the basic mode of interaction is one of a reverse-sorted timeline of photos. Each event has one "key photo" associated with it which is shown in the event-level views. Of course, real events often span more than one day; Shotwell provides the ability to merge the day-based events into larger groups. There does not appear to be any way to split an event apart, though. If one photographs a wedding in the morning, a business meeting after lunch, and a vuvuzela-inspired bar brawl in the evening, it's all forever a single event as far as Shotwell is concerned.

Naturally enough, there's support for attaching tags to photos. It's easy enough to quickly add tags to groups of photographs; they can only be removed from a single photo at a time, though. There is no hierarchy to tags, so the list will get long if a lot of tags are used. Tags, like events, are displayed in the left column and are easily selectable.

Shotwell has some simple image editing options, including rotation and cropping. There is a red-eye removal feature as well. The use of it is somewhat awkward; it puts a small circle on the image which the user must position over the eye and size accordingly. It does work, though, and is arguably preferable to the gthumb equivalent, which is sometimes better described as a "red face removal" feature. Shotwell has a small dialog for adjusting parameters like exposure and saturation; there is also an "enhance" button which performs some behind-the-scenes magic, not always to good effect.

The red-eye removal feature exposes one strange gap in Shotwell's feature set: there is no way to zoom in on an image. It's always "fit to window," regardless of what the user might want. This makes the placement of the red-eye tool's circle problematic on anything but a close-up photo.

Users of other image editing tools will likely be looking for a "save as" option after making some changes, but Shotwell has no such thing. Instead, all edits are squirreled away in some hidden database. Shotwell does not change the image itself; it maintains an edit list which is applied on the fly when the image is displayed. So, once some edits are made, the original photo is no longer visible in Shotwell unless the user has thought to create a duplicate prior to making changes. One can always undo changes to get back to the original once one remembers that changes have been made. There is no indication in the interface, though, that any edits have been made. One wonders if the Shotwell developers are aware of the fact that they are committing themselves to the exact behavior of all their editing primitives forever; it would be most disturbing to see pictures change in unpredictable ways after a software upgrade.

One can save out an edited version of an image using the "export" feature. Exporting is also the only time when it is possible to change the resolution of a photograph. It is not possible to change the format an image is stored in. There are also features to "publish" a photo to various proprietary web services; your editor did not test any of those.

For users who simply want a way to collect and organize their photographs, Shotwell may well be developing into a reasonable alternative. For grumpy editors, though, this application seems like the wrong approach. A directory full of photographs is exactly that; there should be no need to "import" it into some application's black box to work with the contents. Any non-trivial photographic workflow involves a number of tools, including raw editors, the Gimp, hugin, etc. Once an image disappears into Shotwell's alternative universe, it becomes unavailable for use with anything else. In other words: in your editor's view, this practice of turning a directory of image files into another, hidden directory of image files breaks the concept of having a box full of useful tools and makes Shotwell unsuitable for real use.

One also must wonder what happens, years from now, when users may want to switch to a newer, shinier application which can cope with the 3D photos they will be taking at that time. How does one transfer thousands of pictures - many with edits hidden in places known only to Shotwell - into that new application? Running "export" on them, one at a time, seems like an unappealing option. Shotwell is free software (it is LGPLv2.1-licensed), so somebody can certainly write a "set my photos free" tool for it. But, to your editor, the need for such a tool just seems wrong.

There is much to be said for innovation in this space; Linux has some nice photo management and editing software, but it can certainly get better. But one would hope that this innovation would happen in a way that does not break the toolbox concept in a domain where toolboxes are highly appropriate. Shotwell is a young utility; perhaps it will evolve and learn to play better with others and to avoid locking its users in. Until that time, it will doubtless be well received by certain classes of users, but it's certainly not for everybody.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 2:30 UTC (Thu) by pabs (subscriber, #43278) [Link]

Ahh, events are actually a bit more complex than just the day they were taken on. In my collection there are multiple events per day. It seems to look for clusters of photos that were taken around a specific time.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 2:36 UTC (Thu) by pabs (subscriber, #43278) [Link]

BTW, another piece of photography software our grumpy editor might like to review is darktable:

http://darktable.sourceforge.net/

A quick grumpy review of Shotwell

Posted Jun 17, 2010 2:57 UTC (Thu) by PhracturedBlue (subscriber, #4193) [Link] (16 responses)

I've been using digiKam for a while. In fact the only reason I have KDE libs on my system is to run digiKam. I've tried lots of organizational programs, and they all have limitations, but digiKam is good at handling RAW images (including custom color profiles), has decent editing capabilities, and makes it easy to apply transformations to image sets. It also has no problem dealing with a directory full of images, and it will only modify them when you tell it too (a problem I had last time I tried F-Spot)

I know this is an article about Shotwell, and it is scheduled to have RAW support and a 16bit pipeline in the future, but I think it needs to mature more before I give it a try.

Anyhow, I think the grumpy editor reviewed digiKam a while ago (like in 2005), but I am quite happy with it now

Digikam

Posted Jun 17, 2010 5:19 UTC (Thu) by noxxi (subscriber, #4994) [Link] (3 responses)

I can also only recommend digikam.
I've switched to it years ago while migrating from Mac/iPhoto and I'm quit happy with it. It's easy to group, classify, comment and tag images, it supports easy geotagging and it's open in that it can store all these meta data in standard format in the image itself.
The last point is the most important for me, because this means I'm not locked in into using digikam.
And if I need to do something special with the meta-data outside of digikam I can also script my images outside of it and later make digikam read the changed meta data.

Digikam

Posted Jun 17, 2010 10:22 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

It's also open in that even its internal DB (maintained so it doesn't have to keep on rewriting images all the time) is a sqlite database, so easy to fiddle with outside of digikam.

Digikam

Posted Jun 17, 2010 10:32 UTC (Thu) by tzafrir (subscriber, #11501) [Link]

Right. But try copying it from one computer to the other. It will loudly complain about invalid an UUID. It stores the UUID of the disk in the DB.

Digikam

Posted Jun 18, 2010 8:15 UTC (Fri) by buchanmilne (guest, #42315) [Link]

In 1.3, the database can also be external (so, sharing photo meta-data between different machines is possible, if the photos are in a constant location, e.g. network share). At present only MySQL is supported, but more external databases will come.

Digikam is also available on Windows, and while there are a few small issues, works adequately, and is better than many of the free apps on Windows.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 10:45 UTC (Thu) by modernjazz (guest, #4185) [Link] (1 responses)

Agreed, Digikam is quite amazing, and I use it for my own collection---it implements everything I've ever wanted, and more, and is easy to use. I think it does most things our editor wants in the way our editor seems to want them to work, with one exception: it is very much album-based and therefore requires importing a new directory (though the imported set of files are not "black box", one simply gets a copy of the original directory and the files within it). And for importing, at least it defaults to the directory from which digikam was launched on the command line (that's frequently a big pet peeve of mine as well).

However, I wonder whether editor is looking for a more lightweight approach? If so, it's possible that gwenview may be a closer KDE equivalent: even though it's not really a "photo management application" it addresses, quite nicely, most of the things that made our editor grump about Shotwell. On the other hand, as far as I can tell it currently lacks features that he might find essential: viewing RAW images without needing to first convert to another format (at least you can do this conveniently within gwenview...), and photo-organizational features (I can't find a way to "display by tag," though as nepomuk matures I suspect that will soon come for free). So I doubt it would currently fit his needs. Still, it's surely an application worth keeping an eye on.

A quick grumpy review of Shotwell

Posted Jun 20, 2010 10:46 UTC (Sun) by jospoortvliet (guest, #33164) [Link]

Maybe he can just use showfoto from Digikam? It has afaik all he needs - it can open a folder and let you quickly modify all images in there. I use it often for retouching foto's...

digikam

Posted Jun 17, 2010 13:21 UTC (Thu) by Webexcess (guest, #197) [Link] (9 responses)

I recently switched to digikam when f-spot stopped working on my netbook (20K photos-of-the-kids might have had something to do with it)

fast and very configurable UI is great for the netbook. It also *understands* that the photos are on the LAN and might disappear if the connection goes away. Unfortunately I can't seem to bind a shortcut key to tagging images (3 mouse clicks instead), and navigation keyboard commands are a little cumbersome.

Overall it's still the best I've found.

digiKam

Posted Jun 19, 2010 2:06 UTC (Sat) by Velmont (guest, #46433) [Link] (8 responses)

Correct. digiKam is the only photo organizer in Linux that isn't dog slow and doesn't want to move your pictures.

I've tested them all, digiKam is the only software that works.

Too bad I have to pull inn half of KDE just to use it, Konqueror and Kmail (wtf?) and loads of other stuff I don't want. However, it's just miles ahead everything else...

digiKam

Posted Jun 20, 2010 10:48 UTC (Sun) by jospoortvliet (guest, #33164) [Link] (7 responses)

that's really really weird, as digikam should only depend on KDElibs (and possibly kdeworkspace-runtime). Konqi and kmail are entirely separate apps... Some distributions do not split up packages, eg if you want kmail you will get all KDE PIM apps but digikam isn't even part of the official KDE software compilation but has a separate release schedule. So it should certainly not require any other KDE application to be available.

digiKam

Posted Jun 23, 2010 5:20 UTC (Wed) by Velmont (guest, #46433) [Link] (6 responses)

This is Ubuntu, it was a few releases ago, but I just checked with Lucid Lynx now, and although it doesn't seem to pull in Kmail, it does pull in Konqueror and Dolphin.

digiKam

Posted Jun 23, 2010 6:27 UTC (Wed) by jospoortvliet (guest, #33164) [Link] (2 responses)

Tsss. Well I couldn't think of a reason why this would be needed - it's simply a dependency/packaging issue in debian/ubuntu. I'd file a bug...

digiKam

Posted Jun 23, 2010 13:19 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

Perhaps it's for the 'open in file viewer' menu option.

digiKam

Posted Jun 23, 2010 13:26 UTC (Wed) by jospoortvliet (guest, #33164) [Link]

Na, that should just use the XDG standard and open eg Nautilus in Gnome or Explorer in Windows...

digiKam in Ubuntu RECOMMENDS konqueror

Posted Jun 24, 2010 11:49 UTC (Thu) by emmi3 (subscriber, #62443) [Link] (2 responses)

The Ubuntu package for digikam does NOT depend on Konqueror or Dolphin, but it instead recommends kipi-plugins, which in turn recommends konqueror und suggests kmail and so on...

Since Ubuntu by default installs recommended packages (but afaik not suggested packages) konqueror is "pulled in".

So to install digikam with the kipi-plugins (and exiv2), but without Konqueror and Dolphin one could use the following command:

aptitude -R install digikam kipi-plugins+M exiv2+M

To find out about the dependencies I find the "-D"-switch for aptitude usually very helpful. Or use

aptitude -R digikam

and look out for RECOMMENDED but not installed packages

Yours,
Robert

digiKam in Ubuntu RECOMMENDS konqueror

Posted Jul 4, 2010 21:19 UTC (Sun) by bjartur (guest, #67801) [Link] (1 responses)

WTH is this a recommendation (rather than a suggestion)?!

Debian Packaging Policy [OT]

Posted Jul 5, 2010 8:30 UTC (Mon) by Felix.Braun (guest, #3032) [Link]

The difference as per Debian Packaging Policy is a matter of degree:

Depends: This declares an absolute dependency.
Recommends: This declares a strong, but not absolute, dependency.
Suggests: This is used to declare that one package may be more useful with one or more others.

I think that this fine-grained dependency tracking allows Debian (and derivatives) to strike a good compromise between simplicity and configurability in terms of dependency management.

Gthumb

Posted Jun 17, 2010 3:49 UTC (Thu) by ncm (guest, #165) [Link] (11 responses)

The latest Debian packaging of gthumb, 2.11.3, doesn't crash, but it lacks essential features found in 2.10.11, so I have held off. The most important missing feature in 2.11, from my standpoint, is a sidebar with thumbnails. Probably Debian should package both under different names, as 2.11 doesn't seem ready for mainstream use yet. The 2.10 version has been eminently usable, for my purposes.

It's nice to see the Grumpy Editor acknowledging gthumb as a photo collection manager, and not just (as had been asserted earlier) a viewer.

Gthumb

Posted Jun 17, 2010 4:35 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (9 responses)

I'm still on Fedora 12, and I like gthumb for photos. I've got several machines to deal with, and a mixture of Intel, ATI, and nVidia graphics. If future gthumb requires extensive 3D support to work, it might be necessary to fork the old one if I want to move to Fedora 13 until the graphics situation settles down.

Gthumb

Posted Jun 17, 2010 17:08 UTC (Thu) by yodermk (subscriber, #3803) [Link] (8 responses)

I've used GThumb on Fedora 13. No problem here.

I am also a fan of its simplistic approach, not wanting to "import" anything. And for viewing it's hands down the best I've seen -- keyboard shortcuts that make sense (all the others seem to botch that somehow).

Gthumb

Posted Jun 22, 2010 10:58 UTC (Tue) by Yenya (subscriber, #52846) [Link] (7 responses)

The F13 version of gthumb has severe problems:

- no view with "thumbnails on the right" anymore (on widescreen monitor with 3:2 aspect ratio of photos it really hurts)

- "ask before deleting" does not work for me (it still deletes unconditionally, and in Preferences it is unchecked even though I have enabled it before.

- photos are displayed 1:1, i.e. not fitted to the screen size. The "fit to screen size" is reset when I advance to the next image. And it still does not work when the thumbnails are displayed - the "screen size" is computed with the thumbnails area included, so I have to scroll even in the "fit to screen size" mode.

It is a huge step back for me and I am looking for a replacement for gthumb.

Gthumb

Posted Jun 22, 2010 11:59 UTC (Tue) by avtechmjc (guest, #50477) [Link] (5 responses)

Why would you take the time to complain about these bugs on LWN, but not file bug reports at: http://bugzilla.gnome.org/enter_bug.cgi?product=gthumb ?

The "ask before deleting" bug is real, but has not been reported, for example.

Gthumb

Posted Jun 22, 2010 12:14 UTC (Tue) by avtechmjc (guest, #50477) [Link]

And I have reported that issue as:
http://bugzilla.gnome.org/show_bug.cgi?id=622386

I don't see any problems with screen zooming, however. What do you have set at Edit > Preferences > Viewer > After loading an image?

Gthumb

Posted Jun 22, 2010 15:32 UTC (Tue) by Yenya (subscriber, #52846) [Link] (3 responses)

Well, I have been thinking about eventually reporting those as bugs, but I am less than enthusiastic when it comes to reporting usability bugs, especially after putting an effort to reporting or at least following several GDM > 2.20 usability bugs like the following ones:

https://bugzilla.redhat.com/show_bug.cgi?id=433649
https://bugzilla.redhat.com/show_bug.cgi?id=451562
https://bugzilla.redhat.com/show_bug.cgi?id=444213

which are either mostly ignored by GDM developers, or are closed as WONTFIX or DEFERRED. I think when it comes to usability reports, it is clearly a decision of the development team to make the application look like they want.

Gthumb

Posted Jun 22, 2010 15:57 UTC (Tue) by avtechmjc (guest, #50477) [Link] (2 responses)

I filed your deletion bug for you (http://bugzilla.gnome.org/show_bug.cgi?id=622386), and it was fixed within the hour:

http://git.gnome.org/browse/gthumb/commit/?id=8cbde58ed70...

Please do file gThumb bugs (in the upstream bugzilla, not the redhat one). The 2.11.x series is in active development, and feedback is both helpful and necessary.

- Mike

Gthumb

Posted Jun 22, 2010 16:03 UTC (Tue) by Yenya (subscriber, #52846) [Link] (1 responses)

Thanks!

I will look into gthumb usability issues after I manage to upgrade my primary workstation to F13 (some time next week). It seems that gthumb developers provide better reaction time and attitude than gdm ones :-)

-Yenya

Gthumb

Posted Jun 22, 2010 16:41 UTC (Tue) by avtechmjc (guest, #50477) [Link]

gThumb 2.11.x (which is a total rewrite compared to 2.10.x) is now pretty much feature-complete in git master, and a 2.11.4 release should happen "soon".

Fixing bugs and enhancing usability are the current priorities:

http://mail.gnome.org/archives/gthumb-list/2010-June/msg0...

- Mike

Gthumb

Posted Jun 22, 2010 12:54 UTC (Tue) by corbet (editor, #1) [Link]

Add to the list: the "resize" operation defaults to a percentage - every time. Which is silly: who doesn't want to resize to a specific size? Gthumb usability has definitely dropped, even before it stopped working altogether.

Gthumb

Posted Jun 17, 2010 19:05 UTC (Thu) by avtechmjc (guest, #50477) [Link]

You know about the thumbnail pane (View > Thumbnail Pane, F8) in viewer mode, right?

When an image is open, the other images in the folder are shown in a thumbnail pane below the open image.

- Mike

unfortunately this misdesign is common

Posted Jun 17, 2010 4:31 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (28 responses)

There seem to be any number of photo applications that want to suck your photos into some internal database somewhere, often by copying all of the images, which could eat up several gigabytes of disk without warning and commits you to using only that app.

I don't know why people think that this is a good idea.

unfortunately this misdesign is common

Posted Jun 17, 2010 5:28 UTC (Thu) by eru (subscriber, #2753) [Link] (26 responses)

I agree, but what are the alternatives if you want the tool to provide more organization than just whatever is in one directory? The tool might keep a database with metadata and references to the original pictures (by file name), but the links get broken if the pictures are moved (eg the user adds more disks and decides some photo directories need to relocate).

But whatever the solution, it should be straightforward and as much self-documenting as possible, since we are storing data for years or decades, and migrations to different hardware and software are a certainty.

I'm currenly not using a photo management software but my plain directories full of pictures I might want to find later are getting larger, so I have been thinking about what would be a good organizer. I thought of Shotwell, but our Grumpy Editor just lessened my enthusiasm for it.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 5:39 UTC (Thu) by NicDumZ (guest, #65935) [Link] (24 responses)

> The tool might keep a database with metadata and references to the original pictures (by file name), but the links get broken if the pictures are moved (eg the user adds more disks and decides some photo directories need to relocate).

Very good point. Maybe one could have a hash-based and/or distance-based wizard to rebuild a broken database when the tool launches and detects missing files and cant trivially find the pictures matching their name?

Is this the time when someones steps forward and says "we need a standard for managing media collections", and asks all existing tools to support such standard? It seems that some common base is the only way to have different tools collaborating correctly with each others...

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 6:10 UTC (Thu) by doogie (guest, #2445) [Link] (5 responses)

git-based, and git notes?

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 13:45 UTC (Thu) by dgm (subscriber, #49227) [Link] (1 responses)

Just my thoughts. Git is supposedly a dumb content tracker, so it looks like it's just asking for it.
And btw, I didn't knew of git-notes, thanks for the pointer!

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 17:42 UTC (Thu) by dlang (guest, #313) [Link]

to make this work well in git you would need to make a diff function that would handle the EXIF metadata appropriately (so that if you change a EXIF tag git doesn't think the entire file is different)

this isn't a huge undertaking, but I'm not aware that anyone has done it yet.

Even after you do this you may have grief with large repositories.

Very true but it begs the question of generic picture management policy.

Posted Jun 20, 2010 20:09 UTC (Sun) by nix (subscriber, #2304) [Link] (2 responses)

For images? Unless you can convince everyone to rescale their photos to small sizes (good luck with that), it's not going to work. git isn't good at giant binary lump tracking.

(e.g. I've been taking photos for less than three months in a serious way and I already have >10Gb of them. git repos that size are hard indeed to manage.)

Very true but it begs the question of generic picture management policy.

Posted Jun 21, 2010 1:07 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

this partly depends on if the changes to the files are in the images or if it's mostly changing metadata.

if it's a lot of editing (and saving the intermediate images) git is definitely bad for the job.

if it's mostly metadata changes and tagging, then git is merely poor (with a fairly clear roadmap of how to get better)

Very true but it begs the question of generic picture management policy.

Posted Jun 21, 2010 21:33 UTC (Mon) by nix (subscriber, #2304) [Link]

Unfortunately, even if there are very few changes to the images, git does badly with giant binary blobs. It's true that does *worse* if the images are edited heavily, but, really, for things like this you don't want *any* extra copies of the images lying around, and git's going to give you one every fifty-odd commits, as long as there's a modification in there somewhere.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 7:16 UTC (Thu) by ekj (guest, #1524) [Link] (2 responses)

That is, infact, PRECISELY what kphotoalbum does.

It stores meta-information about the files in a xml-file, including the sha1sum of the files. This means that if you move, reogranize or rename your files, the meta-information will still apply.

The meta-information -also- sticks if you edit the file, because it has filename AND sha1sum. But if you do both, you lose the meta-information, unless you run "update sha1sums" (a maintenance-tool available in the tool-menu)

So "edit + update sums + move" is fine. But "edit + move" results in lost metainformation. Reasonable, in my opinion, because if the FILE changed AND the filename changed, how is any tool supposed to know it's "the same" file?

Kphotoalbum also does NOT import your pictures, nor ever change them in any way (though it supports kipi-plugins, and some of those do modify files)

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 9:43 UTC (Thu) by eru (subscriber, #2753) [Link]

Thanks for bringing it up. I'll have look at kphotoalbum, it sounds like the kind of tool I am looking for.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 13:02 UTC (Thu) by dmag (guest, #17775) [Link]

+1
I've been using kphotoalbum for years. The interface could be more intuitive, but it's OK once you get used to it. It's got hierarchical tags, add/remove multiple tags, etc. It will bring your recently-used tags to the top (but there is still a way to use a tag w/o bringing it to the top). It's got multiple categories of tags (people, places, keywords). It automatically finds any new photos you throw in the photo directory. (Let's face it, all your photos should be in one directory. 1TB drives are like $60 now.)

But my biggest wish would be for a really good web app, so my family could view and help tag the photos.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 12:43 UTC (Thu) by jackb (guest, #41909) [Link] (14 responses)

Sounds like yet another problem that a filesystem which supported attaching arbitrary metadata to files accessible via standard file/directory semantics could have solved.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 16:47 UTC (Thu) by martinfick (subscriber, #4455) [Link] (13 responses)

Until you move your files to another filesystem! What you are proposing simply glosses over the problem by calling the internal DB the local metadata enhanced filesystem.

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 18:29 UTC (Thu) by jackb (guest, #41909) [Link] (12 responses)

I didn't propose it - Hans Reiser did.

Had reiser4 fs been completed as initially intended the required functionality would have been added to the VFS layer and more than likely ported to other file systems by now.

Then the "how to we store and access metadata" problem would be solved permanently and universally. (at least on Linux)

Very true but it begs the question of generic picture management policy.

Posted Jun 17, 2010 18:55 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (11 responses)

Until you need to back it up. Or copy it to Windows.

Very true but it begs the question of generic picture management policy.

Posted Jun 20, 2010 20:28 UTC (Sun) by nix (subscriber, #2304) [Link]

Or access it over the network ($HOME on NFS -> you can hardly use it at all).

Very true but it begs the question of generic picture management policy.

Posted Jun 21, 2010 11:59 UTC (Mon) by jond (subscriber, #37669) [Link]

indeed, as soon as I burn my photos to backup DVDs, bye-bye metadata.

Very true but it begs the question of generic picture management policy.

Posted Jun 28, 2010 20:53 UTC (Mon) by bjartur (guest, #67801) [Link] (8 responses)

It's a simple tradeoff:

use the "right" solution (xattrs): Metadata will persist through changes and reorganization; Other programs will be able to find and use metadata (file managers, (set|get)fattr).; Not all filesystems support xattrs. Some hacks exist to store xattrs in filesystems that don't support them but do support some similiar concepts (e.g. NTFS alt.str.).
use the "hacked" solution (seperate metadata files): Will work over e.g. NFS sans extra hacking; Metadate won't persist through edits and reorganization. Hacks exists to make metadata persist through either (e.g. by comparing images to all existing images).; Metadata won't be obviously "attached" to the related files.; Directories get cluttered with metadata files or risk corruption of metadata of all imported files.

Personally, I'm a fan of xattrs as I like being able to move the files around without having to fire up a specific image-moving application and glancing over the images themselves rather than just telling sh to move all images taken in a certain timespan to a seperate folder and consider storing images in big library that makes exporting images to native filesystems necessary plain aweful.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 11:22 UTC (Tue) by paulj (subscriber, #341) [Link] (7 responses)

Why not develop a file format that can handle multiple streams internally? Then you get the best of all worlds:

- works with tools which think files are just files
- allows other tools to treat files as collections of different data

There are a number of such formats already, what we're lacking is a format that is optimised for multiple-streams for data storage.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 16:41 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

Wouldn't we call these multiple-stream files 'directories'?

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 17:45 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Yep, but that's fragile in the face of applications that are not aware that the dirs+files are arranged in certain way - leading to the problems the parent poster perceives which caused them to argue for xattrs (which are much, much more fragile in the same sense - and hence much worse).

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 20:03 UTC (Tue) by nix (subscriber, #2304) [Link]

FUSE (automounted by a library) plus something like tarballs (only not actually .tar, I know .tar is vile, maybe .gz.cpio, i.e. gzipped first then cpioed?) might do the trick.

Very true but it begs the question of generic picture management policy.

Posted Jun 29, 2010 18:15 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

you mean like EXIF tags inside a image file?

Very true but it begs the question of generic picture management policy.

Posted Jun 30, 2010 6:59 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Yes. Is EXIF limited in some way though, that makes it less than useful for image apps to put all their metadata in there?

Very true but it begs the question of generic picture management policy.

Posted Jun 30, 2010 7:19 UTC (Wed) by dlang (guest, #313) [Link]

probably the fact that it's fairly expensive to search metadata that's part of many separate files compared to having the data condensed into one file/database

this applies to xattr use as well.

Very true but it begs the question of generic picture management policy.

Posted Jul 4, 2010 18:21 UTC (Sun) by bjartur (guest, #67801) [Link]

It's called "filesystem" :P

Ideally, I'd like simply having mountable files (on Linux you'll need a loop device; preferably in user space) that can be formatted as a directory (multiple named internal data streams), list (multiple indexable streams) or whatever may be invented in the future. Simple bencode some data and mount it to be able to work with it The Unix(R) Way. The tools that work with the data need not care how it's stored on disk, so you can just choose the most efficient format or whatever suits you.

Use directories

Posted Jul 4, 2010 21:14 UTC (Sun) by bjartur (guest, #67801) [Link]

Copying isn't necessary: if moving the physical location of files *requires* a namechange the naming system is broken. It's purpose is to abstract physical location away. If it can't do that, it isn't working properly.

Categorizing images into folders using hiearchial directories should work fine. If you use symlinks or bind mounts you'll get full device abstraction and even just union mounting gets you some abstraction (though it may pose some limits on the storage of labels (i.e. names of folders)). Union mounting may simplify management if the set of folders is quite static.

unfortunately this misdesign is common

Posted Jun 17, 2010 13:38 UTC (Thu) by marcH (subscriber, #57642) [Link]

> There seem to be any number of photo applications that want to suck your photos into some internal database somewhere, [...] and commits you to using only that app.

It's called a BKL: Big piKtures Lock.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 6:49 UTC (Thu) by spaetz (guest, #32870) [Link] (1 responses)

As a long-time gthumb users, I have defected to shotwell and I am mostly happy with it (if you compare the life-span of gthumb and shotwell (first shotwell commit in svn is 12 months ago), I find it very promising). Disclaimer: I am just a user of shotwell 0.5.2

-No multiple events on a day:
In an event, I select a couple images, I press Ctrl-n (or select menu->new event) and the photos are split off into a new event on the same day. Works fine here.

-Import:
The import dialog *can* copy photos to a folder (I think it proposes the XDG_PICTURES_DIR which is set to "$HOME/Photos" on my box) although I recall that is going to be configurable.
There *is* a checkbox in that import dialog that says "don't copy image" which lets the image rest in place as is (making it useful for other programs). I simply copy my new pictures to a new subdir of my media dir and reimport the whole media dir with the "leave in place" option checked, which will not copy the images to a magic library. It will ignore duplicates that are already imported.
As for the obvious solution: monitoring a dir for new files to appear there is a ticket for that: http://trac.yorba.org/ticket/374

-As for zooming, that is annoying, indeed. I never noticed before. Trac tickets seem to indicate it should be there.

Overall I like it because:
- It is fast
- It doesn't get in my old ways of organizing my photos (that is keeping subdirs in a media folder where *I* put them)
- tags and events are useful
- easy integrated flickr upload
- very dynamic development and responsive team of hackers

A quick grumpy review of Shotwell

Posted Jun 17, 2010 7:03 UTC (Thu) by spaetz (guest, #32870) [Link]

PS. Image zooming *is* implemented and is part of the soon-to-be-released 0.6 version.

I don't need a photo manager

Posted Jun 17, 2010 11:36 UTC (Thu) by sorpigal (guest, #36106) [Link] (1 responses)

I don't need a photo manager or photo editor or photo organizer, I need an *image organizer*.

I've got plenty of dumb image viewers and plenty of image/photo editors. I don't need simple editing because I can (and prefer to) use the GIMP. The tool I'm missing is something that gives me a good way to organize images.

Shotwell, and a lot of other photo organizers, seem to be oriented around the idea that you will take photographs and then do things to them, categorize them by who is in them, when they were taken, and so on. I don't need photo-like features; I don't care when, I don't care who, I don't care where. I simply need tagging at a massive scale. I have perhaps 20 images of photographs that I have taken. I have something like 30,000 images that are not photographs. When it comes to organization I simply don't need any for my photographs.

My images typically have multiple properties, such as what's depicted in them, or what I used to create them, or what project they're for. Some of these properties overlap. Today I use a directory tree and symlinks to attempt to cross-reference things correctly, but it's a nightmare to manage. Ideally I'd like to be able to add multiple tags to these images and then filter by tag, rather than attempt to put them in multiple directories and then list multiple directories and remove duplicates 'somehow'.

Adding tags needs to be easy. No more than one click (or keyboard shortcut) to invoke "add tag", auto-completion of existing tags, and automatic creation of "new" unknown tags when I hit Enter. The workflow should be: View image, CTRL+T (or whatever), type one or more tags, hit Enter. One or more tags have been added to the image and saved to disk.

Tags should be stored in the image. I don't care how, but I want those tags to stay with the image as I move it between computers. I ultimately want to be able to build my own command line filtering/sorting tools. My ideal image organizer would probably maintain a tag index for fast searching, but the tags themselves should be stored in the image. My images are in multiple formats (gif, jpeg, png and xcf) so this is quite a challenge.

I need speed and reliability. I've seen some image organizers crash when handed 10k images, or take days to process them. I've tried a lot of image managers and this is a point where most of them fail.

Am I the only one who isn't a photographer and still has a need to organize images?

I don't need a photo manager

Posted Jun 17, 2010 12:19 UTC (Thu) by skx (subscriber, #14652) [Link]

You're not alone in wanting something like that.

I've written a hokey set of shell-scripts for adding tags to images, storing them in the EXIF data. Right now I have EXIF comments which look like "Tag:colour Tag:outdoors Tag:people Tag:people-me" which isn't ideal, but is simple to parse, update, and remove.

I keep thinking I should write a tool to make this a GUI process, storing tag information both in an image and in an SQLite database for speed. But I never quite get round to it.

If somebody else would that would be ideal.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 12:14 UTC (Thu) by michel (subscriber, #10186) [Link]

> vuvuzela-inspired bar brawl in the evening
Very inspired!

A quick grumpy review of Shotwell

Posted Jun 17, 2010 13:00 UTC (Thu) by Hanno (guest, #41730) [Link] (1 responses)

Idle words from a user to follow.

Have been using f-spot for several Ubuntu releases now. It is kinda-nice and it works fine with external tools, it keeps versions of edited images and its photo repository is a simple directory layout plus a small sqlite database, both are easy to understand. Backing it up or "exporting" photos from it is very simple.

But f-spot crashes every now and then (with no data loss, however) and it appears to slow down with lots of photos. Also, it keeps importing the same image files again and again, even when it is asked to detect duplicates with checksums. That feature hasn't worked properly for a long time.

But here's a plea to anyone implementing image organizer software: Please make it multi-user-capable in some way or another. All current photo organizers seem to expect to store photos on a local disk in one-user mode. This isn't practical when you are, say, married, both love to snap photos and use two laptops and a NAS in the household.

Since a long time, my wife and I are looking for a photo organizer that we can use to work on our shared collection of photos. Right now, the photo collection is on my laptop and my wife needs to login to edit or choose photos.

It would be really nice to have something that we can either use from two computers to work concurrently on photos stored on a network NAS. And / or something that allows to share and edit photos on another computer in the network. I've been looking at web-based photo organizers to put on the NAS, but haven't found one that is as nice as f-spot so far.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 14:00 UTC (Thu) by pizza (subscriber, #46) [Link]

|It would be really nice to have something that we can either use from two computers to work concurrently on photos stored on a network NAS. And / or something that allows to share and edit photos on another computer in the network. I've been looking at web-based photo organizers to put on the NAS, but haven't found one that is as nice as f-spot so far.

At the risk of tooting my own horn, there's always the aptly-named 'Photo Organizer' (http://po.shaftnet.org) that tries to do just that. It's web-based, a hell of a lot faster than gallery (not saying much!), and scales decently well (I have >100K images taking up >700GB). Nobody's tried to shoehorn it into a NAS box that I'm aware of, but there's no inherent reason why it couldn't be.

Its development is mainly driven by my personal needs (and available time) and it certainly has its warts, but it does what I need, at least.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 13:27 UTC (Thu) by Tet (guest, #5433) [Link] (2 responses)

Shotwell will not just operate on a directory full of images; one must, instead, "import" images into the application

That instantly disqualifies it in my book. I'll stick with xv. It may be old and unmaintainted, but it works, and I've yet to find another image viewer that I prefer.

A quick grumpy review of Shotwell

Posted Jun 17, 2010 19:10 UTC (Thu) by alextingle (guest, #20593) [Link]

Did you try gqview / geeqie? It's really really fast, straightforward and to the point.

A quick grumpy review of Shotwell

Posted Jun 20, 2010 10:51 UTC (Sun) by jospoortvliet (guest, #33164) [Link]

Maybe you should try gwenview or showfoto?

A quick grumpy review of Shotwell

Posted Jun 17, 2010 16:21 UTC (Thu) by cry_regarder (subscriber, #50545) [Link] (1 responses)

My tool chain of choice is gthumb-importer, geeqie, hugin, gimp, and gallery2. The photo manager tools all seem to much in the "all your photo are belong to us" camp.

Cry

A quick grumpy review of Shotwell

Posted Jun 17, 2010 17:51 UTC (Thu) by coriordan (guest, #7544) [Link]

I also like geeqie (previously called GQview).

Alas poor xv....

Posted Jun 17, 2010 21:32 UTC (Thu) by tferro (subscriber, #3989) [Link] (2 responses)

Sigh! Why is it so hard for developers to replicate the wonderful simplicity and flexibility that John Bradley got so right with xv? All the newer systems I've seen and played with seem to concentrate on being flashy and sophisticated - I just want to work with my images.

- An old, grumpy user.

Alas poor xv....

Posted Jun 20, 2010 20:32 UTC (Sun) by nix (subscriber, #2304) [Link] (1 responses)

ImageMagick's display(1) has a basic user interface that's about as simple and uncluttered as you can find. (If anything, a bit *too* uncluttered.)

Alas poor xv....

Posted Jun 21, 2010 16:56 UTC (Mon) by bronson (subscriber, #4806) [Link]

The photo management tool I use the most is qiv. Specifically 'qiv -t *.jpg' and type 'd' to delete. :(

One day I will find another tool that is as fast and trouble free as qiv. I was hoping that Shotwell would not follow in F-Spot's footsteps quite so closely but ah well.

Response from Shotwell team founder

Posted Jun 17, 2010 22:49 UTC (Thu) by adamdingle (guest, #67751) [Link] (13 responses)

Grumpy Editor,

I'm the founder of Yorba (makers of Shotwell) and have been deeply involved in Shotwell's design from day one. Thanks a lot for trying out Shotwell and for the candid and thorough review. We always appreciate direct feedback and are happy to hear about what people do and do not like.

Grumpy Editor, your review touched on various points about Shotwell, but of course your biggest gripe was about the way Shotwell imports photos and about the relationship between the Shotwell photo library and the file system. I'll first provide brief feedback about some of the smaller points:

- You mentioned the lack of support for RAW photos and zooming into photos. Both of these features have been impemented in trunk and will be present in the Shotwell 0.6 release (coming in the next two weeks).

- As someone else pointed out in another comment, it actually is possible to split an event apart in Shotwell: simply select the photos you'd like to split into a separate event, then choose Events->New Event.

- It actually is possible to remove a tag from several photos at once. Simply select the tag in the sidebar, then select the photos you'd like to remove it from and choose Tags->Remove Tags From Photos.

- We do hope to implement hierarchical tags at some point (that's http://trac.yorba.org/ticket/1401, if you're curious).

OK, and now on to your Major Concern. As you pointed out in your review, Shotwell expects you to import all photos into its library. As you do so, Shotwell indexes their metadata so you can search them in various ways. You can edit photos in Shotwell, but normally your changes stay in the Shotwell universe. Changes get written to files only when you export (or, in Shotwell 0.6, when you use Shotwell's Open in External Editor command, which writes pending changes to a file and then opens an external program such as GIMP on it).

The Shotwell model is common among commercial photo programs; iPhoto, Aperture and (to some degree) Picasa all work this way, for instance. But clearly you want a photo program to use a different model. You'd like to be able to browse through photos easily according to their on-disk file hierarchy, and presumably you'd like photo edits and metadata to be stored in the photo files themselves, at all times. I imagine you'd also like to be able to search for all photos matching a given tag or in a given date range. For this to be possible, a photo program must of course index the on-disk photos, which is itself a form of importing, really. But it sounds like you're opposed to an explicit import step. (Perhaps you'd like to point a photo program at your top-level photo directory and let it index everything in the background. Or maybe you'd like a photo program to automatically index all the photos in directories which the user browses through.)

So, then, which model is superior? We built Shotwell to use explicit importing and to store edits in its own database both because other popular programs work that way and because certain users have told us they want us never to touch their originals (see, for example, the discussion at http://lists.yorba.org/pipermail/shotwell/2010-April/0002...). But recently we've been getting more and more feedback from people like you who want a storage model based directly on the filesystem (see, for example, http://ubuntuforums.org/showthread.php?p=9475456 or https://bugs.launchpad.net/ubuntu/+source/shotwell/+bug/5...). So I've actually become less and less sure that we've gotten this right, and I think it's likely that we'll switch to something like your preferred storage model in a not-too-distant release, at least as an option for the user. In fact, different users seem to have distinctly different storage preferences, and so perhaps we can even evolve Shotwell to the point where the user can choose where data is stored. For example, a user might want us to store metadata (e.g. photo titles/keywords) either in the original files, in sidecar XMP files, in the Shotwell database, or in Tracker. It might be cool if Shotwell could do any of these as you please.

As you mentioned, Shotwell is a young utility. We do in fact plan to evolve it to work more flexibly together with other Linux tools, so thanks again for the feedback and please keep your eyes open for future Shotwell developments!

Cheers,
adam

===
Adam Dingle
Yorba

Response from Shotwell team founder

Posted Jun 17, 2010 23:07 UTC (Thu) by dlang (guest, #313) [Link] (6 responses)

I think that the key thing is that the current model is based on the premise that the user will only use one application to touch their pictures.

the Grumpy Editor (and many of the rest of us) want to be able to use multiple different apps to deal with the pictures.

we may use Shotwell to view and organize the pictures, but gimp to edit them, (or imagemagic to resize them, or dcraw to convert from raw, etc)

we could let Shotwell import them (and copy them) into it's own structure, and then point these tools at the results, but this will fail as soon as any other tool also wants to take complete control of the pictures, so Shotwell is viewed as being anti-social by doing so.

We understand that this is common practice for the propriatary software world (windows and MAC especially), but the unix philosophy is to allow you to use multiple tools, allowing the user to pick best-of-breed solutions for each task. It's nice if there is one GUI that can leverage the specialized work and be a single panel for doing the common work, but if that prevents other tools from being used, that GUI can easily become more of a liability than an asset.

It's not strictly necessary for all the metadata to be stored in the initial files, but it should be stored in some way that makes it possible for other apps (and/or scripts) to find, access, and ideally modify this data. putting it in exif is one way (and probably the easiest cross-application method), but not the only way.

This also isn't saying that copies of the pictures shouldn't be made. In fact if you modify the image (especially if you modify the image in a way that cannot be perfectly undone) you _should_ make a copy of the image in some manner before you do so.

Response from Shotwell team founder

Posted Jun 18, 2010 0:32 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (5 responses)

If they implement an edit in another application feature does this solve the problem of multi-application editting?

I think the key question for me is..
what's is the best way to implement a revision control system for images that works well across multiple applications? I really don't want to have to keep oodles of copies of my photos around when I touch them up for different formats. I want revision control in a _smart_ way.

Shotwell's database is just a mechanism to do for images what git does for source code isn't it?

The problem is, we are building dedicated photo revisioning systems into applications silos. What we need is a common revisioning system that _ALL_ imaging processing applications can use. Even commandline usage..where you checkout specific imagine revision, edit the image,then import that back into the image revision database as a changeset (with tags or other metadata as deemed appropriate)

-jef

Response from Shotwell team founder

Posted Jun 18, 2010 0:42 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

no, shotwell is like if git was integrated into gedit and you could only access the files through gedit.

git doesn't force you to use a specific tool to manipulate the working copy of the files stored in it.

if shotwell organized the images and left them alone in the filesystem for you to use whatever tool to tweak them, you would not see people raising this objection.

Response from Shotwell team founder

Posted Jun 18, 2010 13:21 UTC (Fri) by paulj (subscriber, #341) [Link] (3 responses)

Insightful comment there.

It follows from what you say that an equivalent model with Shotwell would be if the photos on disk were with modifications applied, with Shotwell keeping data somewhere on how to undo changes (or conversely how to change the original to the current version on disk). ?

Response from Shotwell team founder

Posted Jun 18, 2010 14:51 UTC (Fri) by adamdingle (guest, #67751) [Link] (2 responses)

I agree: it would make sense for Shotwell to store photos on disk with modifications applied, but with the original photo backed up under a separate filename and also storing information about how to change the original to the current version on disk. As some people have observed, it would even be nice if the transformation information could be shared among programs, not specific to one program such as Shotwell. Perhaps we can get there one day. We're interested in modifying Shotwell to use a GEGL pipeline and that might be one step toward a transformation structure that can be shared.

Response from Shotwell team founder

Posted Jun 18, 2010 18:52 UTC (Fri) by dlang (guest, #313) [Link]

that would be good. I don't think it's that necessary for the exact details of how to convert one to another be available cross application (other than as comments/documentation trail/changelog)

but the unmodified original should always be available (or recoverable, with with lossy compression algorithms means a copy), and the currently 'final' result should be accessable without a need to run some export process.

Response from Shotwell team founder

Posted Jun 19, 2010 2:42 UTC (Sat) by spitzak (guest, #4593) [Link]

Editing should just move the original from X/foo.jpg to X/originals/foo.jpg, and it should throw it away if that file is already there (thus you only keep the most recent edit and the original). If other applications followed this rule as well then you could use any editor and still recover the original.

I would very much like to see a photo manager that just leaves the files where they were. You would give it a list of directories and it will act like the set of photos is every photo found in those directorys and any subdirectories. If a file is in a given directory it acts like it has a tag that is the directory name, as well as any tags that are in the EXIF data. Attempting to remove these "directory tags" would, I guess, move the files, perhaps with a warning. Or add a "not actually tagged with this" tag.

For Linux apps this almost is necessary, just so you can cooperate with some of those proprietary apps that insist on moving the files. For instance I would like to use it to at least look at an rsync copy of a iPhoto directory. If we are careful we should be able to at least change the tags and perhaps edit files and those apps will still handle it.

There may be an "import" but it would be for reading off of cameras and SD cards and other removable media, where you have a good reason to want a copy. The user should be able to choose what directory it goes into, and there should be programmable scripts (with some pre-supplied ones) to use dates and other EXIF data to place the files into subdirectories.

Response from Shotwell team founder

Posted Jun 19, 2010 2:22 UTC (Sat) by Velmont (guest, #46433) [Link] (4 responses)

Have you looked carefully at digiKam?

I've been following Shotwell, because I'd really like to get a less-fat image organizer that digiKam. What digiKam does well:

* You can tag pictures, and captions, and everything is stored INSIDE the picture (I've been burned by this before, using Gallery to write captions for thousands of images and then, all of them lost).
* It's FAST (that's important, I've got thousands of pictures, I want to zoom through them and delete, delete, delete (or watch, watch, watch))
* It doesn't copy or change the pictures
* It does FAST searching (how? well it has it's own indexed database ALONGSIDE the pictures, it's basically just copied the information that already exists inside the images, but done so because it needs to search it).

You can use Tracker to do the searching and indexing-part. I've heard it's much better these days.

The other thing digiKam doesn't do is having an easy way to tag pictures fast (you have to click much with the mouse!).

Anyway, thinking it's way cool you're considering changing the way the software works! :D

Response from Shotwell team founder

Posted Jun 21, 2010 20:49 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

The digikam tags are just stored in a database, so if you shut it down first (or are using a non-sqlite database in recent versions) you can add tags in bulk using raw SQL, restart digikam and write the lot out to the images with a couple of mouse clicks. :)

(but, to be honest, a lot of the time tagging depends on the contents of the images, and for that a bunch of select-mouse-clicks and tag clicks are actually a *good* user interface. Using WIMP GUIs for things that actually are graphical in nature seems like a good idea to me.)

Response from Shotwell team founder

Posted Jun 23, 2010 5:17 UTC (Wed) by Velmont (guest, #46433) [Link]

Well, ... I've got so many tags. I tag with e.g. names, and so I need to write, I'm writing Jack Smi[...word complete...]. Etc.

So what I want is to go to next picture, add tag «jack smi...», add tag «ha» [ppy], next picture. etc.

You can't do that quickly by the mouse. By all means, the mouse ui can stay, I would probably use that for some things, but not for my main tagging.

Response from Shotwell team founder

Posted Jan 6, 2011 22:06 UTC (Thu) by ceplm (subscriber, #41334) [Link] (1 responses)

It is probably too late for any participant of this thread to actually care, but if anybody finds this via Google, most of the "I just want to organize my photos and then process them with something else" camp can be very well pleased with jbrout (http://jbrout.manatlan.com/, packaged for most Linux distros, but check for the latest version). It stores all tags and info INSIDE of the image file (yes, it has cache for fast search, but it is not the authoritative storage of information). Also, it's trivial to have any external application on right-click-menu. Highly suggested.

Matěj

Response from Shotwell team founder

Posted Nov 28, 2011 11:59 UTC (Mon) by Velmont (guest, #46433) [Link]

I did search for my own name to find my user ID on lwn, and lo and behold, a new answer. I'll look at it, looks rather nice.

Would be interesting to see how fast it is. DigiKam is still, one of the fastest image browsers I've come across.

DigiKam loads incrementally better versions of the image, and I believe it decodes the next picture when you have extra time as well. Maybe even it uses a free core on your CPU to do that, I don't know, but I do know that it's miles faster than most other software when looking quickly through huge pictures.

Although I'm no fan of the copy on the website: It's noisy!! Very much so! ;-)

Response from Shotwell team founder

Posted Jun 20, 2010 15:29 UTC (Sun) by mebourne (guest, #50785) [Link]

Since you seem to be interested in different use-cases and workflows and since gthumb has just been ruined(*) in the latest version in Fedora 13 (luckily a downgrade to the Fedora 12 package still works fine at the moment) and since there seem to be a preponderance of photo programs like the current shotwell which go against the unix philosophy here's how I manage my 10k's of photos.

I use a script to pull the photos off whichever camera and into the fs, fixing timezone, rotation etc. Photos are placed in a careful directory hierachy organised by event and renamed to MMDD-HHMM to ensure time ordering across multiple cameras, essential at many events (such as weddings). Some photos (such as random shots of the kids around the house) are instead categorised by year and content rather than event.

All photos get checked into a VCS (I use SVN at the moment, though could be anything).

I need a "photo organiser" application that works with my directory hierachy, photos are going to just appear in there from scripts, I don't want any manual import step, I don't want any important metadata stored outside of the photo (and certainly not outside of the directory, gthumb adds a .comments dir which is ok). Storing a cache of metadata for searching would be fine as long as indexing was transparent. It's good to rewrite the image any time I touch it (metadata, or image editing, mostly using gimp anyway) and I don't want the photo organiser to try and do any backup copies or version control itself. After every bunch of edits I commit and if I don't like the changes I can revert.

I check out several copies of the images to different places for different use cases, some full copies and some selected by tags (gthumb's comments are easy to parse from script being in "text" ie. xml).

My main use case of the photo app is rapidly zapping through pictures using the keyboard. Tagging, commenting individually or in groups, deleting (though of course they stay in vcs history). I need a thumbnail organiser but most of the screen needs to be showing the photo and I need keys to zoom into pixel and out again quickly, and full screen/windowed. I might take 10-20 shots of a photo to get a good one and need to see pixel level focus etc, and I need to be able to navigate around them for comparison quickly using the keyboard.

A nice touch would be integration with vcs to be able to view historic commits of a photo for comparison, or to commit changes directly from the app, though the command line works just fine for now. Colour profile understanding would be great too, though colour correcting the whole X display works well enough for now.

(*) The UI has been messed up to make it unusable for my most basic use case and the thing crashes incessantly. Guess I'll just be keeping a fork of the old gthumb which was 9/10 for my workflow until something better comes along. If that is going to be shotwell then great. :)

3D

Posted Jun 18, 2010 8:49 UTC (Fri) by drago01 (subscriber, #50715) [Link] (8 responses)

"Bling is nice, but if it kills the ability to use the tool for its very two-dimensional intended task, one needs to question the priorities involved."

Well the problem is not that the apps uses 3D features; but that OpenGL does not work on your system for whatever reason.

You can't really blame apps for broken OS infrastructure.

3D

Posted Jun 18, 2010 8:54 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

so why does an app to display 2D pictures not work on a machine that doesn't support OpenGL?

per the article this is only used for a slideshow, but if the person just wants to manage the images and not do a slideshow, the app is still useless on anything that doesn't have OpenGL

this is a perfect example of bling making an app unuseable.

3D

Posted Jun 18, 2010 15:13 UTC (Fri) by foom (subscriber, #14868) [Link]

There's really no reason why apps shouldn't be able to rely on basic OpenGL features working. At *least* via software rendering, even if you have no 3D hardware. And software rendering should be just fine for doing transition effects for a slideshow. That apps currently cannot reliably depend on OpenGL to work is a big problem...

Luckily, there is a lot of working going on now to fix that problem, so for new apps, I too would be mighty tempted to just assume it works for everyone, or will work soon enough to not matter.

3D

Posted Jun 18, 2010 17:02 UTC (Fri) by drago01 (subscriber, #50715) [Link]

I wasn't being specific to the app itself but there is no reason why apps should pretend that opengl is an optional feature that is "rare".

If opengl does not work that something at the system level is _broken_ not the app that tries to use it.

In fact I consider not using opengl where it makes sense a bug; GPUs aren't just providing a framebuffer where you can directly draw to, they can actually do the rendering, so it is valid to use them for their intended task.

3D

Posted Jun 23, 2010 9:51 UTC (Wed) by ebassi (subscriber, #54855) [Link] (1 responses)

so why does an app to display 2D pictures not work on a machine that doesn't support OpenGL?

you seem to imply a dichotomy between a 2D pipeline and a 3D pipeline that has ceased to exist in modern hardware - and by "modern" I mean something released post-1999.

if you have a GPU - be it a discrete or an integrated unit - all your pixels get pushed through the same pipeline. the great goal of the Linux graphics infrastructure is to make everything as hardware accelerated as possible, which means going through OpenGL - the only open API and specification for hardware accelerate graphics.

not supporting OpenGL on capable hardware (i.e. everything that's at most 5 to 10 years old) it's a bug.

3D

Posted Jun 25, 2010 11:10 UTC (Fri) by robbe (guest, #16131) [Link]

> you seem to imply a dichotomy between a 2D pipeline and a 3D pipeline

I don't think that was implied. One can certainly defend the view that a program rendering 2D objects to a 2D output without (normally) doing 3D transformations on them could limit itself to using a 2D API. Especially if the 2D API is supported by everything your target audience is caring about, while the alternative OpenGL has pretty dodgy support on average.

Whether this 2D API is implemented in HW by a 2D pipeline, a 3D pipeline, or a horde of spice-swigging OpenBSD developers warping spacetime with their giant brains is besides the point.

There are of course arguments for using OpenGL without alternative: simplicity; that the 2D API is too crufty; that shoveling wastage at the proverbial fan will finally create enough of a stink that the OpenGL situation under Linux is fixed for good.

3D

Posted Jun 23, 2010 0:38 UTC (Wed) by dododge (guest, #2870) [Link] (2 responses)

I haven't tried this latest gthumb (my system is not handy), but I see in the Clutter README that it depends on the XComposite extension. That can be a problem on multi-head systems.

People with only two displays attached to the same card can get around the problems by using things like NVIDIA's Twinview, which tricks the X server into thinking you only have one display. When you add a second card to get three displays it all falls apart. Twinview doesn't work across cards, so you have to enable Xinerama (or live with not being able to move windows between screens). Enabling Xinerama causes XComposite to be disabled because they're not compatible. Xinerama is supposedly deprecated and replaced by XRandR -- which is compatible with XComposite -- but XRandR also doesn't work with multiple cards and and that capability has been repeatedly delayed for something like 3 years now.

3D

Posted Jun 23, 2010 9:44 UTC (Wed) by ebassi (subscriber, #54855) [Link] (1 responses)

Disclaimer: I am the Clutter maintainer

I haven't tried this latest gthumb (my system is not handy), but I see in the Clutter README that it depends on the XComposite extension. That can be a problem on multi-head systems.

the XComposite extension is optional.

also, I have a multi-head system (two panels, my LVDS and an external monitor) and it works perfectly fine. granted, I'm not using an extension and X server from 1997 but something designed released in this millenium. ;-)

and yes, I'm using Clutter on this system. actually, it's the system on which Clutter itself is mainly developed.

3D

Posted Jun 23, 2010 21:44 UTC (Wed) by dododge (guest, #2870) [Link]

> the XComposite extension is optional.

Sounds good, thanks.

> granted, I'm not using an extension and X server from 1997 but something designed released in this millenium. ;-)

My 3-head system is running the current Xorg in Ubuntu 10.04, which still can't do XComposite (or XRandR) properly across multiple cards. It does at least do OpenGL, and windowed applications such as Google Earth are okay. Anything that tries to go full-screen can get very confused or worse yet trigger bugs in the X server, though.

It seems like every new release gets a little bit worse. For example with this latest Xorg the server chokes if you try to configure a 3-1-2 screen layout (so that screen 1 is in the center), which had worked fine for the past 4-5 years. The only person I've heard of managing to get XComposite to work across multiple cards had to use a several-years-old modified Xgl server -- it's never worked in Xorg.