GNU Photo Archiving software? 56
jonr asks: "After I got my
Olympus
E-100RS camera, I have been enjoying photography again. I now
take on average dozens photos a day. Now the problem is ever growing
photo collection. I found an excellent archiving software,
IMatch but I'm
looking for something similar to run under Linux. Folders and
sub-folders are are just not cutting it. IMatch allows me to put my
photos in a category tree, e.g. a photo of my dog could be placed in
Family/Pets and Animals/Dogs. It also has off-line archiving, a must
have for growing collection. Now does anybody know of a tool or a
collection of tools for this?"
try this (Score:3, Informative)
Found with a quick google search.
Re:try this (Score:2, Funny)
Error: Insufficent Operator Head Space code number "duhdurdur"
Re:try this (Score:3, Informative)
Am I oversimplifying the problem here? (Score:1)
Of course, this makes me want to go look for Linux hierarchical storage programs.
Re:Am I oversimplifying the problem here? (Score:4, Insightful)
While it leverages filesystem tools, it isn't user friendly: one still needs some kind of app to tie it all together (and answer questions like, "Under what other keys is this image also indexed?"). I call this the "reverse-symlink" problem: what are the symlinks to a given cannonical file name?
Also, symlinks to symlinks (keys to on-line version to possibly off-line nfs-mountable media) tend to add inefficiency, although I don't reall see two levels as all that problematic.
Still, it does look like a quick and dirty poor-man's hack. Don't give up on the simple and obvious just yet.
Re:Am I oversimplifying the problem here? (Score:2)
Not to mention that Keywords and Category could have dozens of entries each. Consider a picture of the WTC cleanup. Category alone could give you WTC, NYC, Terrorism, Fire Dept, rescue, news, 2001, emergency, and Guiliani just at first glance. And that's an easy one. Stock photos are much worse. If you try organizing your images by hand-symlinking folders, you're rapidly going to end up with an exponentially-expanding mess that you then have to hand navigate every time you want to make a change. And that's assuming you do it all correct the first time through; forget about it when you throw in human error.
Besides, what you're really doing in that scenario is hand-creating a relational database. Why on earth would you want to go through that mess when there are industrial strength database packages out there that do it all for you?
Nate
Re:Am I oversimplifying the problem here? (Score:2)
Yes, a poor-man's solution: quick and dirty.
Why on earth would you want to go through that mess when there are industrial strength database packages out there that do it all for you?
Hmm, "industrial strenght" strikes me as expensive, in this context (someone wanting to manage their personal digital photos).
I'd probably start with a symlink method, and if the catagorization really started to get out of hand, consider automated tools to generate the links based on a KWIK indexing technique, or move to a proper meta-data database.
But, the symlink technique does not preclude eventual migration to a more powerful beast, like a bona-fide database. In fact, it should be a simple matter to populate the latter with the metadata represented by the former. Thus, it seams like a decent intermediate step before going all out.
Frankly, I just can't imagine the number of keys per item being all that large. It strikes me that you're arguing for a "mod-foo" solution when I'm suggesting trying "foo cgi-bin" first. They both have their place.
Re:Am I oversimplifying the problem here? (Score:2)
Besides, the guy said he takes a dozen pictures a day, which even for a few keys is well out of hand over the course of a year. Even one key each is 4380 pictures.
And it seemed to me like the whole essence of his question was how to move up from the quick-and-dirty to something nicer like the Mac (iPhoto) and Windows (iMatch or whatever he mentioned) users have available to them.
Nate
PS - Oh crud, I just realized I forgot to list one option in my other post about real programs: Photodex, Inc. makes a commercial image-management program called Compupic. You can check it out at www.photodex.com.
A couple of distributions do include the free version on their "supplemental" CD's, but I heard about it because we use it where I work (where last week I spent fifteen hours cataloging and searching photo databases that stretch back 25 years and have dozens of keys per image, which is why I'm so bitter about this issue today....).
I'd be a little wary of the free Linux version; it's clearly the red-headed-stepchild of their prodcut family, and the supported Windows version I have to use is a pain enough.
Re:Am I oversimplifying the problem here? (Score:1)
Depends entirely on how friendly you consider the command line
(and answer questions like, "Under what other keys is this image also indexed?"). I call this the "reverse-symlink" problem: what are the symlinks to a given cannonical file name?
In that case, you can always use hard links instead of symlinks.. then a (maybe not-so) simple :
$ find -inum `ls -i thisfile.jpg |awk '{print $1}'`
will tell you.. (of course with this scenario, all the files must be on the same partition..)
Incidentally, I do this (the symlink method) with my MP3 collection - the main folder contains artists/ albums/ years/
the songs are linked by the artist name, album (which don't necessarily correspond 1:1), and decade the song was recorded.. original songs are placed under the artist, with links in the other folders.. (there is the occasional link in the artist folder, pointing to a file under another artist - for collaborations, etc..)
It works pretty well for me..
Re:Am I oversimplifying the problem here? (Score:2)
I've found that the cannonical starting point usually reflects existing mechanical hierarchies -- in my case, how I've organized my CDs.
Re:Am I oversimplifying the problem here? (Score:2)
Sounds expensive in terms of disk I/O (reading all those directories). I suppose you could do a similar thing with symlinks (find all links that point to the same cannonical file, assuming a single level link to keep it simple), thus removing the single-partition limit, and cache the results for rapid access. A cron job could do this.
Re:Karma observation (off-topic) (Score:1)
I suppose that this is not necessarily unreasonable, but I wonder if it is a bug or a feature?
I take that back... it is definitely a bug, at least in the overrated case. Here's why:
A post can be overrated for one of two reasons: "shouting" by someone with a +2 default score, being moded down, or excessive upward moderation by others. I don't think that the poster should be penalized karma because of positive opinions that others have.
Thus, overrated mods should only lower karma when the score is at or below the original posting score.
The other case, that is losing karma on an otherwise upward modded comment, is not as clear. It stands to reason that the greater one's karma the more vulnerable it is due to what one says -- this keeps karma in check, even with a cap. But one's karma should never be affected downward because of positive upward modding by others.
Re:Karma observation (off-topic) (Score:1)
Think of it as a karma cap of 45 with some room to take care of duelling moderator issues and you'll be fine with it.
Re:Karma observation (off-topic) (Score:1)
I can post at +1 (because I select "No Score +1 Bonus"), get 4 positive mods to +5, and 6 overrated mods to -1 (say, can a post at 0 be overrated?). That results in a drop in karma to 44.
I can post at +2, get three positive mods to +5, and 6 overrated mods to -1. That again results in a drop in karma to 44.
Clearly, it doen't matter what I post at: I can lose as much karma as the max score minus the min score (from overrateds).
It isn't a big deal, of course, but I still think the principle is flawed: losing karma because some people think the opinions of other people are overrated?
Re:Karma observation (off-topic) (Score:1)
If you don't feel like trolling, tell someone who pisses you off "Fuck you" at +2. It sends a stronger message that way :).
Re:Am I oversimplifying the problem here? (Score:1)
He said he wants pictures of his dog in two different places...
bash$ln -s
Re: Am I oversimplifying the problem here? (Score:5, Interesting)
Why not just use the filesystem to categorize pictures, and some other solution for hierarchical storage or removable media cataloging? Then, when you want to look for a picture, you just search for the directory/category name, and it'll either tell you where it is
Yes, you are oversimplifying. Big time.
I work for a newspaper. Our single greatest technological hurdle is archiving in some sort or reasonable fashion.
You'd think the Associated Press would have this figured out. They create tens of thousands of pictures a day. They have the big stick to get the system built. They had their developers create a product called 'AP Preserver'. It was to be the end-all be-all photo archive solution. After many years of trying to get it right, they dropped the product. Even with all their knowledge of the subject and a rather large check book, they couldn't get it right.
In the past, archiving photos was easy. They were physical and humanity was well versed with physical items. No longer is that the case. Digital photos are a pain in the buttocks.
Part of the problem is expectations are higher now that photos are digital. When photos were on strips of film, often times they weren't kept for more than five or ten years. Even folks who kept them longer generally didn't keep out-takes (photos not used in the newspaper).
Now, we are expected to keep every picture taken by every photographer of every event forever. Worse than that, folks want to be able to search for photos using keywords and sometimes even by what the picture looks like. (For example, if you want all the profile pictures of Bush, all you'd need to do is find a picture of Bush in profile and then feed it to the search engine and it will find the rest. (Just for clarification, when I say 'profile pictures of Bush', I mean profile pictures of President Bush and not profile pictures of hairy bush [hairybush.com].)
The fairly large newspaper I work for creates a gig or so of photos and graphics each day (speaking only for Editorial and not Advertising). We use a product called Portfolio [extensis.com] by Extensis. It runs on an NT server which doesn't help the AskSlashdotter in the least. We will probably use Portfolio for another couple years until CCI's MediaStore [www.cci.dk] is ready for prime time.
Some will say I'm being silly by comparing a major newspaper to a guy with a digital camera. We both face the same issues of cataloging and retrieval. The only difference is that he is probably using a 60-gig harddrive and we're using a multi-terabyte array.
Anyone who thinks that archiving photos is easy has never tried.
I'm sorry to report that there are no great photo archiving solutions. Find the one that sucks the least and you have accomplished much.
Matt
Re: Am I oversimplifying the problem here? (Score:1)
Re: Am I oversimplifying the problem here? (Score:1)
Will CCI provide conversion tools to migrate from the Portfolio product, or will you have to do the process on your own?
Re: Am I oversimplifying the problem here? (Score:2)
Will CCI provide conversion tools to migrate from the Portfolio product, or will you have to do the process on your own?
I'm pretty sure that CCI will write an import process to pull photos out of AP Preserver. I doubt they will do the same for Portfolio. It's not as universal as Perserver.
Since Portfolio doesn't alter the orignal image, worst case is that we'll have to import millions of photos into the new solution from scratch, losing good metadata. Portfolio does have a way to export data (or so I'm told) so I suspect we'll have to pay someone (probably CCI) to write an import script which will keep our yummy metadata. But I'm not holding my breath.
Migration of data from one image archive platform is a real problem. We have had at least three solutions this far and getting data out of one into the next is always painful.
Unlike text archiving which we figured out long ago, photo and image archiving is still a mystery. Our text archive is virtually unchanged since we bought it online in 1983 except for the addition of some drive space (it now has 12 gig online!) and a web interface (it was telnet only). In fact, the hardware is some of the oldest in the building.
Matt
Re: Am I oversimplifying the problem here? (Score:1)
Where I work, various imaging solutions were (before the latest budget cuts) being considered--what several of them have in common, despite paying lip service to "open standards," is that once one is chosen, switching vendors becomes very painful.
Re: Am I oversimplifying the problem here? (Score:1)
Have a look at this - using semantic web stuff (RDF, etc) for photo indexing:
Ontology-Based Photo Annotation, A. Th. (Guus) Schreiber, Barbara Dubbeldam, Jan Wielemaker and Bob Wielinga, IEEE Intelligent Systems, no. 3, May/June 2001, 66-74
www.swi.psy.uva.nl/usr/Schreiber/papers/Schreibe r0 1a.pdf
Great article (Score:2)
Re: Am I oversimplifying the problem here? (Score:1)
Re:Come on, this question is soo lame (Score:2, Insightful)
Note that I said "shoot" date, not file creation date. Real software for this type of task is database-driven and is what pro photographers need to maintain thousands of files, and be able to search them and subsearch them.
ln -s that.
Re:Come on, this question is soo lame (Score:2)
try this:
http://www.linux.it/~carlos/nosql/
but an RDBMS for saving the metainfo of a few snaps you've got to be kidding right?
thousands, wooo steady on, the meta info might not fit on this floppy disk, I'll have to gzip it!
Re:Come on, this question is soo lame (Score:1)
Just print them out! (Score:1)
Sometimes computers are the problem, not the solution.
ln -s (Score:1)
create dir and 'place' files in them by using symbolic links. there, one copy of the file and it 'exists' in many places (catagories) as you want.
If You Have Access to a Mac... (Score:2, Informative)
Umm, a database? (Score:1, Interesting)
fields for image, title, caption, category, when, where, a longer description of what it is, and any keywords to find this.
Throw the whole thing behind a web page, and a navigable image library.
gqview and konqueror (Score:3, Insightful)
I can't think of anything better. I also have some directories that have over 1000 files in them, and using konqueror to view the thumbnails works like a charm.
I really can't think of why you'd need any other software to create a directory for you based on what you want to list the files under when it is so easy to do it in gqview. I.E. File -> new directory , then select files and then right click and move them to your directory. I guess by naming them as a category this save a step or two, but its really insignificant IMHO.
Here we go (Score:5, Insightful)
Well, here are some projects that do do what you want, in one way or another.
Photoseek, Lodju and GPC are the only ones that are not designed to be web-interface only. Several of the numerous "web gallery" packages have good indexing capabilities, but are primarily geared at presentation, not cataloging.
The non-Web-gallery programs are all relatively young-in-the-lifecycle projects. Although GPC seems to be the furthest along, my initial experience with Photoseek was better -- but it has been so long since a release that I'm not sure how healthy development is.
Don't listen to anybody who suggests that you do it all by hand with flat files. They've never tried.
Nate
Re:Here we go (Score:1)
That's for sure. This is a database problem and demands a proper database solution. I tried with flat files and it was just too cumbersome to keep up to date and work with. I would be happy to let anyone take a look at the rather miserable chunk of perl code that I wrote if they wanted, but the short story is to not reinvent the wheel, and use a database to do all the storage and searching.
BTW, thanks to Nate for all the good pointers, I might try again with my 2000+ photos :-)
- Mike
what he have here is a failure to communicate (Score:3, Insightful)
them1: software, shmoftware! Linux users are men! Write a script! Bootstrap the damn thing!
them2: I tore apart a sega dreamcast and converted my 27" jamma console into a multimedia photo archival unit. Check out the links here [arcadecontrols.com]
them3: Why in gods name would you want to archive something as stupid as photos anyway? I just take pictures of my computer, and put them in a directory called
The question is not why or when or how but Is there any software available! Jeesh guys, its a simple question.
Of course, I don't know the answer to that question either, so file this one under a troll I guess.
Perhaps this? (Score:1)
Actually; here's a strange trend (perhaps it's just me) but every time someone wants some kind of application like photo archiving or any kind of database or mail or whatever, I immediately think and/or search for a web-based solution. Even for home stuff I install things like "Squirrel mail" and "PHP-donkey" on my main Linux box, then I can access them from anywhere with just a web browser.
Perhaps it's because I have to keep reinstalling Windows when it fscks up (Not my fault, Sue keeps installing those crappy Kewlbox games and assorted other flakeware!!) and this approach saves me from having to reconfigure mail and stuff..?
The Gallery (Score:2)
Re:The Gallery (Score:1)
it currently lacks symlinks and I wouldn't recommend it for industrial use, but it works well and has quite an active mailing list, lots of users and people supporting them.
The Gallery (Score:1, Redundant)
"Gallery is a slick web based photo album written using PHP. Easy to install (it includes a config wizard), it provides users with the ability to create and maintain their own albums in the album collection via an intuitive web interface. Photo management includes automatic thumbnail creation, image resizing, rotation, ordering, captioning, searching and more. Albums can have read, write and caption permissions per individual authenticated user for an additional level of privacy."
But if you want more choice, have a look around [freshmeat.net] and you will really be spoilt for choice.
On a side note, Slashdot is not freshmeat! Get a clue and learn how to use a search engine !
Try IMatch (Score:1)
www.photools.com
Same problem (Score:1)
The photos store in a mySQL database that keeps everything from name, place, people, photographer, category, etc; and uses php/apache for a frontend.
If you want a preview check it out at http://24.221.255.108/photo/ login with slashdot/linus.
And that is not a superfly fast webserver, so picture loads may be painful.