Slashdot Mirror


Flexible Photo Organization Software?

Matthew Wecksell asks: "Several years after getting a digital camera, I find myself with far too many pictures to keep track of, with multiple folders titled 'At the Beach' and so on. Picassa will not let me assign multiple labels to a picture and then search against those labels the way iTunes will with my music (eg: Show me all pictures with '"Grandma Foo" and not "Grandma Bar"' to find pics that have just one of my two grandmothers). Also, I'd like to find a solution that lets me export the meta data or keep it in the picture files, not a proprietary database, so that in ten or twenty years, I can use another program on another platform and still have useful tags assigned to my pictures that I'm taking today — I have no interest in re-tagging my pics. Has anyone found a good solution to the picture organization problem? Is there any standard 'ID3' style for putting metadata into an EXIF header?"

27 of 131 comments (clear)

  1. Good luck by finkployd · · Score: 2, Informative

    I'll be watching this thread closely, I made the mistake of putting of my my pictures in iPhoto (which is a fine program otherwise) and I find I am unable to get out of it. The pictures are categorized nicely in directories but the tags and such are not transferable to any other program as far as I can tell. I would really like to move to F-Spot but I don't feel like duplicating hours of work on some 3000 pictures.

    Finkployd

    1. Re:Good luck by MojoStan · · Score: 2
      You people _do_ know that iTunes can rip to MP3 just as well as AAC right? Sure MP3 isn't the default, but it takes all of 5 seconds to change. I use iTunes this way... and when I'm in Linux Amarok automatically pics up my iTunes MP3's... CD art, artist name, genre and all.
      I don't think Peregr1n was implying that iTunes cannot rip to MP3. Peregr1n was replying to someone who made the mistake of imporitng/tagging 3000 photos in iPhoto and cannot easily transfer the tags (re-tagging would take hours). I'm pretty sure Peregr1n was comparing the very common "mistake" of ripping/tagging thousands of AAC files in iTunes and pointing out the difficulty of transfering the AAC tags.

      I don't think this is Apple's fault, though. AFAIK, there is no established tagging standard for AAC files (like ID3 for MP3s).

      --
      TO START
      PRESS ANY KEY

      Where's the 'ANY' key? I see Esk, Kitarl, and Pig-Up...

  2. "me too" by tom17 · · Score: 2, Insightful

    I love the UI on Picassa, but I am finding that it has some shortcomings.

    For example, I have all my pictures on one network share. On desktop PC "A" I arrange my pictures into albums using labels. on Desktop PC "B", you have to repeat this work. A central (or even just exportable) database of this would be hands.

    Along with multiple labels

    and possibility of heirarchical albums structure.

    1. Re:"me too" by Viraptor · · Score: 5, Informative
      No idea what system are you using, but if it's Linux, then try F-Spot (http://f-spot.org/Main_Page). It's basically Picasa, but:
      • uses labels (normal text ones) AND tags with tag hierarchy, so you can tag it with "My room" and it will also get parent tags "Home", "My city", "My country" and "Place". Any number of tags allowed, along with complex searches (("Grandma foo" OR "Grandma bar") AND EXCLUDE "My room" is possible)
      • has less "effects", but
      • has more sliders in color / contrast correction + histogram
      • supports camera and folder import

      And yes - it has Picasaweb export!
      Additionally it's a new project and is actively developed. Tags are kept in database, so network sharing will probably work with good configuration. Changes are kept like in Picasa - it always keeps the original file without modifications.
    2. Re:"me too" by Clueless+Nick · · Score: 2, Informative
      and possibility of heirarchical albums structure.

      It's already there. Update Picasa through the Help menu entry or download it directly from http://picasa.google.com/

      -clueless
      --
      Chat with other atheists http://secularchat.org
  3. Photoshop Elements by BenjyD · · Score: 2, Informative

    I believe that Photoshop Elements 4 stores the tag data in the photo headers. In general, PSE4 on Windows is a really good photo organiser, I prefer it to iPhoto in fact.

    1. Re:Photoshop Elements by gutnor · · Score: 2, Interesting

      Photoshop Element (at least version 5.0) will store all tags as IPTC Keywords - i.e. available in Picassa and every program able to read EXIF and IPTC entry ( such as caption, ... )

      However it does not do that in realtime with tags as it does with caption. You need to periodically launch the command "write tags and info to photo" that will process all your photo in batch. This can be surprising when you work with more than one program simultanously. Also this is important because when you are renaming some tags, Elements will *ADD* (i.e. not overwrite) them into the keywords of the photo.
      On import however, Photoelement will propose you to import the various IPTC keywords it found as Tag.

      Good stuff with Photoshop Element is that it integrates well with the editor and everytime you update a photo it keep the original and create a versionset stack and version history inside the organiser. ( By default it keeps the original and name the subsequent version "_Edited-X" so this information could be exported using a script )

      Also if you take care about color calibration, PhotoElement is color managed.

      Finally Photoshop Element is a good organiser. Its interface is not as efficient (especially zoming, slidshows, ...) as Adobe Lightroom but it provides more "home user" friendly features ( VersionSet, Tag hierarchy, ... )
      Lightroom is free while in beta but sadly it is not going to be a cheap product since it is aimed at professional.

  4. I'm doing something like this by miyako · · Score: 4, Interesting

    Interestingly enough, I just stopped hacking on an application that will hopefully solve a lot of these problems just this minute to start reading slashdot. I actually just started coding on this project a couple of days ago, so it doesn't do a lot right now, but in a couple of days it should have at least the rudimentary features you are looking for (storage of tags, searching) and will hopefully be a bit usable.
    You can check out the code here if you want:
    http://code.google.com/p/mediabrowser/
    The project is written in C++ with Gtkmm, you'll have to compile it yourself since I haven't built any packages or anything.
    Hope that helps.

    --
    Famous Last Words: "hmm...wikipedia says it's edible"
    1. Re:I'm doing something like this by miyako · · Score: 3, Interesting

      Right now, I'm not really doing anything that much different or better than Digikam or F-Spot (haven't used KPhotoAlbum, so I can't speak to that) partially because those are really good programs, and partially because my app is still in the "just started it a few days ago" phase.
      The motivation at first started out being that I just wanted to learn Gtk and play with ImageMagick a bit. Since I've been hacking on it for a few days, I have some ideas that I think will make my application a different alternative. For one, I want to support video and audio as well as images. Pretty much every phone and digital camera now days takes short video clips at least, and I think they should be integrated in with photos nicely in an album. Some of my other ideas are a bit more experimental.
      As I was saying to a couple of people on IRC last night, in the end maybe some people will find the software useful, but it's probably going to become a sort of dumping grounds for me to play around with a lot of ideas I have for various image algorithms, and will eventually become completely incomprehencible to anyone below the rank of Advanced God.
      If anyone is interested, a couple of the ideas I've had are:
      Doing some facial recognition and learning algorithms so that the program will start to associate name tags with people in the photos, and automatically tag new photos with the people it sees in the photo.
      Draw a picture that resembles the photo you are looking for, and search the database for it.
      Using texture synthesis to clean up images.
      Working on creating a UI with OpenGL.
      those are just some of the potential ideas I have floating about in my head, if anyone is interested in lending a hand on coding on it send me an email.

      --
      Famous Last Words: "hmm...wikipedia says it's edible"
    2. Re:I'm doing something like this by swillden · · Score: 2, Informative

      For one, I want to support video and audio as well as images. Pretty much every phone and digital camera now days takes short video clips at least, and I think they should be integrated in with photos nicely in an album.

      KPhotoAlbum does that already, BTW.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    3. Re:I'm doing something like this by thinsoldier · · Score: 2, Insightful

      here' the thing with descript.ion files
      If I were to move a dozen photos from one dir to another using explorer the descript.ion file in the other directory has none of the info about the files I just put there.
      All that info is in the .ion file of the previous directory. If I copy that .ion file over to the new destination folder it overwrites the old one and now only those 12 recently moved photos will have metadata and the hundreds of other photos in that dir lose everything.

      descript.ion files suck unless every app in the os capable of moving files keeps constant track of them.

      I've been an acdsee user since version 4 and it just doesn't cut it for me. To manually 'tag' stuff (stored in its database or .ion) takes too many clicks and keys and to edit exif data takes even more.

      Crazy Idea:
      An new xml image filefomat .imx

      [imx]
              [meta] ...meta data here ...
              [/meta]
              [binaryimagedata] ...jpg or whatever binary image data here...
              [/binaryimagedata]
      [/imx]

      there, it can wrap any common existing file format.

  5. foobar by Anonymous Coward · · Score: 2, Funny

    Let me guess, your grandfathers names are 'widget' and 'gizmo' right ?

  6. Hmm. by BJH · · Score: 4, Informative
    Is there any standard 'ID3' style for putting metadata into an EXIF header?


    Why, yes, and they're described in section 4.6 of the EXIF specification.
    1. Re:Hmm. by jmkaza · · Score: 4, Informative

      Of course, actually reading section 4.6 shows that the only tags available are TIFF Attributes indicating such exciting information as the 'Subsampling ratio of Y to C', and the ever useful 'White point chromaticity'.
      As far as convenient ID3 type info that you can do something with; no.

  7. And thus, he said "iPhoto?" by MBCook · · Score: 2, Insightful

    I use iPhoto and besides albums I can assign keywords to the pictures making it easy to search by keyword. If iPhoto is not enough then Aperature is supposed to provide even more so I assume it would have better organizational stuff too.

    Of course, both require a Mac.

    But I love iPhoto. All my photos have names, ratings, and a set a keywords with everything from file type to portrait/landscape, to camera model and lens (I, of course, had to set all these).

    --
    Comment forecast: Bits of genius surrounded by a sea of mediocrity.
  8. Aperture or Lightroom by SuperKendall · · Score: 2, Informative

    If you were using a Mac, I'd suggest Aperture...

    But since you mentioned Picassa, I'll assume you are using Windows. You may want to look at Lightroom, you can organize photos and attach keywords which you can then search on. Lightroom will generate XMP files alongside images, which hold all your metadata (Aperture can do the same). Lightroom also stores these keywords inside a local database, making search very fast.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  9. Make mine multi-user. And hierarchical. by dschuetz · · Score: 2, Interesting

    I've been looking for the same thing, and, at least in the Mac world, it ain't out there. The closest I've found is Shoebox, which has a great hierarchical tagging system, but it's still single-user. And it's been a little buggy for me.

    Big bonus for Shoebox, though, is the hierarchical tags -- I can't believe how far we've gone with all sorts of folksonomy tagging systems, but virtually nobody's using a hierarchy of tags. Keeping these flat, especially if you want to start organizing and grouping by family, is just unusable after a 25-50 tags or so. With Shoebox's system, you can set things up like "John's Family" with John, his wife, and all kids as sub tags. Then, if, say, "Tim" (John's oldest son) marries "Jane", create "Tim's Family" as a sub to John's family, or even as a sub to Tim, and you can use aliases to have Tim show up in both places. It's hard to explain without pictures, but trust me, it's really very flexible.

    Anyway, the downsides:
    * Again, a little buggy / flaky
    * Proprietary: Can't export the data, though you can export the tag hierarchy (just not the associations between tags and the photos, at least not that I've found)
    * Single-user: It's licensed for a single userid on a single CPU, so my wife can't even access it on the same box, let alone me or her on any other box in the house.

    If we could get the organizational abilities of Shoebox (or a similar hierarchical tag system) in a client-server model, running on a linux server with clients on windows, mac, or whatever, then I think I'd have a personal winner. Bonus points if it speaks DPAP so iPhoto can read the libraries (to make printing, editing, etc., easier). Oh, and it'd have to have an easy way to store/track multiple versions of a photo, for when you crop, clean out redeye, etc.

    I'm "this close" to starting to hack something together myself, but simply have no time with all the other unfinished projects in my life (not to mention my son). At least I should write up a more careful specifications document and post it on a blog somewhere, for someone who actually has time to start hacking at. Really, the back-end DB stuff is trivial, you just need a decent front end. And a web interface just wouldn't be all that usable for huge collections, either. (otherwise, I'd recommend giving Zoph a look, as it's got a lot of the DB stuff but it's 100% web based).

  10. DigiKam by ajs318 · · Score: 4, Informative

    I used to use a simple script to I wrote to create an index.html page from a directory of photos. This worked surprisingly well; but then I discovered digikam, and now I wouldn't look back.

    --
    Je fume. Tu fumes. Nous fûmes!
  11. IPTC metadata is what you want by pauljlucas · · Score: 4, Informative
    Is there any standard 'ID3' style for putting metadata into an EXIF header?
    IPTC allows lots of metadata, e.g., caption, category, city, headline, keywords, etc. Google for it. Note that IPTC has nothing to do with EXIF. For JPEG files, IPTC metadata is stored in the segment having the APPD marker.
    --
    If you reply, do so only to what I explicitly wrote. If I didn't write it, don't assume or infer it.
  12. IPTC metadata by uglyhead69 · · Score: 4, Interesting

    Your Grandmother's names are Foo and Bar?!

    That is so incredibly cool!

    It sounds like what you really need is a basic IPTC editor. That way all the metadata you associate with the file stays with the file wherever it goes. If you're using a mac and have $300 you aren't terribly good friends with, you could buy Aperture. It has a really nice system for assigning IPTC fields in batches, and you can also set up hierarchies of IPTC keywords. (Think tags, but IPTC keywords have been in use a long time with the photo industry, and they call them IPTC keywords) Oh and Aperture does loads of other stuff. Its overkill if you don't shoot in RAW mode and do some post-processing. If you're talking about snapshots here, I would just find a simple tool for whatever you platform of choice is to let you edit IPTC headers. Get them all labeled first, then worry about management software in another year or so once you have finished all the labeling.

    Oh and try not to take any pictures in the meantime. You'll only make more work for yourself. Say hi to the Granmas for me!

    1. Re:IPTC metadata by Demosthenex · · Score: 2, Interesting

      I use Mapivi for photo management, IPTC metadata tagging, searches, etc.

      It is quite powerful, and the author is very responsive.

      http://mapivi.sourceforge.net/mapivi.shtml

      The argument for IPTC is simple: The data is stored in the image.

      I'm working on some perl scripts to search IPTC data in images, and create directories of symlinks to the results. That way I could use a tag like Xmas, and then run a query based on the year in the datestamp and the tag Xmas, and end up with subdirs for each year and all the photos symlinked from their original location.

      Then I can group upload to Gallery, or just run album on the symlinks.

      Demo

  13. Re:at least flickr gets them off of your drive by Cecil · · Score: 2, Insightful

    Maybe I'm a control freak, but I don't feel comfortable trusting someone else to a) store my photos, b) keep my photos secure, c) store a tag index for all of those photos. I don't even trust them to do it safely *right now*, much less to have done it and still be doing it 10 or 20 years down the road.

  14. My open, simple approach to the problem by xleeko · · Score: 4, Interesting

    I dealt with this a couple of years ago by adopting an external form for descriptions and a picture naming convention. See the screed/tirade below :-)

    I wrote a couple of scripts for bulk-importing lots of files and started a windows GUI editor to encourage family to adopt it, but got distracted. I have just been doing everything with emacs in the meantime.

    ==
    == Photo Description Tools
    ==

    Digital photos are wonderful, but for all of their megapixels they lack the simple feature of prints -- you can't write on the back of them.

    On the surface, it seems simple enough. When I take a picture of Uncle Harvey, the JPEG file is one million bytes in size. You would think that it wouldn't be difficult to add in the twelve extra bytes for the string "Uncle Harvey".

    The problem is that everyone wants to do it differently. In what has become computing industry standard practice, each vendor wants to lock you into their private database for notes, and when the technology or business environment changes, you lose everything.

    In the past year, I have shot many photos, and since I can't jot notes on the back, have forgotten many details about the subjects. I can't wait another few years for a winner to emerge before recording this information. I need to capture it now!

    I keep my physical photos for 30-40 years, and want to keep my digital photos for just as long. If you believe that your current solution is going to survive that long, good for you. I don't, and this is my open way of saving the information in a way that will survive for many years and hopefully outlast the stupid vendor contests.

    That data belongs to you! Don't let someone else lock it up!

    These protocols were written to scratch this particular itch. The following are
    my design goals:

    - Let me capture BASIC information about the photos

    - Store the master copy of the information in a separate file,
    so that we never lose it if some vendor decides to strip
    things from the picture file.

    - Store the master copy in an open format so that I can write
    tools against it or even just edit it with a text editor
    and never be held hostage to a particular tool.

    - Copy the info into the file multiple times in all the competing
    protocols, so that it will be visible in whatever system
    you happen to be using.

    In order to make this happen, I have defined two specs that will
    govern the tools I write. If it other people and projects want to
    adopt them too, so much the better.

    The first is the pixtag file format for picture descriptions. This is
    simple enough to write by hand with notepad.exe or emacs (I am doing a
    lot of this while building my tools), but structured enough for tools
    to easily read and manage.

    The second is a naming convention for files. You can use pixtag
    regardless of what you name your image files, but if you plan on
    keeping your pictures for decades, you better use something better
    than the IMG_1234 that comes out of your camera. Plus, you better
    plan on mixing those files with ones from other people, scans of
    traditional prints, and so on.

    PIXTAG DESCRIPTION FILE

    There is some flexibility in how the master file is handled. In most
    cases, I expect that there will be one file with all of the pictures a
    person has, or one file per directory (what I do) However, some people
    may want to partitioning files by year, or overachievers may even load
    everything into a mysql database.

    I suggest the pixtag file extension for the master files. So for a
    single file it might look like:

    loffredo.pixtag

    For multiple years or directories it might look like

    196x_loffredo.pixtag

  15. KPhotoAlbum by swillden · · Score: 3, Informative

    I don't know what platform you're on, but if you're on a Unix system, I *highly* recommend KPhotoAlbum (previously called KimDaBa).

    Some of its features:

    • All metadata is stored in an XML file, though optional SQL database support is nearly complete. Even after the SQL backend is done, you'll have a choice of using either SQL or XML. Either one gives you great data portability. The SQL backend ultimately promises multi-user access, and I'm working on a database synchronization tool, so that I can have an SQLite DB on my laptop and a MySQL DB on my home file server and automatically keep them in sync, allowing changes to be made in either place (my wife will probably always use the MySQL DB).
    • Tagging is very flexible. Define any number of categories, any number of tags within categories, arbitrary hierarchical and cross-hierarchical organization of tags within categories, etc. Basically, there's no tagging structure you can't build with it.
    • Tagging is very easy to do. The UI requires a little time to learn (though there are some videos to speed you through it), but that's because it's design is focused on making it possible to very efficiently categorize large numbers of photos, so there are a lot of hotkeys and tricks to learn. You can categorize photos just by pointing and clicking, but if you take a lot of pictures it's well worth it.
    • "Token"-based tagging is a big help, too. While viewing images you can quickly associate single-letter "tokens" with each one, then mass apply real tags to the images. I use this for tagging images with people.
    • It has a cool "date bar" that shows you a histogram of images over time, and allows you to quickly narrow your image searching and viewing by clicking and dragging over the date ranges.
    • You can search for images either with sophisticated query strings, or by "drilling down" through the categories. For example, if I want to see a picture of my daughter on our 2005 trip to Florida, I just click "Location", click "Florida" (perhaps typing "f" in the search field to narrow the list so I don't have to scroll to find it), click "Persons", click my daughter's name (again perhaps first narrowing the list), then drag across the 2005-ish region of the date bar. At each stage KPA shows me the number of photos that match my restrictions so far. When it's small enough, I click "View Images" and I see thumbnails of the selected set. Very fast and intuitive. There's also a query language if you prefer.
    • KPA supports the KDE Image Plugins, so you get all of those features, and new ones are added from time to time. There are export plugins that integrate with various web galleries, image manipulation plugins, a slide show creator and lots more.
    • Large databases work well. There are KPA users with well over 100,000 images, though you may need a little more RAM if you have that many photos. The SQL backend should make databases of arbitrary size perform well.
    • KPA also supports tagging, viewing and management of video clips.

    If you're going to try KPA, I highly recommend getting an SVN version, or waiting a few weeks for the next release. It's a very significant upgrade over the last release and it's been in feature freeze for a while so it's very solid.

    One of the things the question asked about was embedding the tags in the images, and if there was a standard way to do that. There is, it's called IPTC, and KPA supports loading tags from IPTC data. It doesn't support writing tags to IPTC, for two reasons:

    • First, KPA's tag metadata is much richer than what could be accomodated in IPTC, so anything put in IPTC fields would necessarily be a subset.
    • Second, a core part of KPA's philosophy is that the indexed images should not be modified in any way, to avoid any chance of data corruption (note that there are KIPI plugins that violate that philosophy).

    Note also that there are some tools out there that only store the metadata in IPTC

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  16. photolibrary by ed_g2s · · Score: 5, Informative

    I ran into this problem a few years ago, and so started work on my own project which I now use to keep my collection of 8500+ photos organised. Categories (tags/labels/...) are arranged in a tree, and are assigned to photos.
    So have a look at http://photolibrary.sourceforge.net/ (or http://sourceforge.net/projects/photolibrary)

  17. link by maxume · · Score: 2, Informative

    The rdf stuff feels like overkill, but overall, lots of places and things to look at:

    http://impressive.net/people/gerald/2000/09/photo. html#software

    --
    Nerd rage is the funniest rage.
  18. F-Spot uses Mono by solferino · · Score: 3, Informative

    I've read good things about F-Spot too.

    But for user awareness I'd like to point out that F-Spot is developed using Mono. You of course, can make your own decision about whether you are comfortable with this dependency.