next »

[monoceros84]

Hi

After lots of problems with digiKam (bug, dependencies, etc.) I was thinking about a decent photo management program for Linux. At the moment digiKam is not working anymore and I can't find the reason...

So what are you using? Are you using anything at all?

Very important for me is the possibility to save the tags, ratings etc. into IPTC so that they are program independent...

[Rolf]

Have you used Pascal's repo? Then that has broken digikam. Pascal has a newer library (name forgotten, just start from the command line)  that is not recognized by digikam. I recall to have known a way to have different versions of one library.....

Have a look at F-Spot. I think it will be my software of choice.

[monoceros84]

Yes I have. Ok, that has to be the mistake. I was wondering - digiKam was running and suddenly (two days later) it isn't anymore. Ok, then I have to de-install UFRaw, remove the repository and install UFRaw and libexiv again. I guess it shout run afterwards... Better not having LensFun in UFRaw than not having digiKam.
But also apart from this there are problems with digiKam. Recently a bug is in there that makes the geolocalize function not working. It's fixed in the code but not in the binaries. And compiling digiKam (especially in Gnome) is almost impossible for guys like me 

The problem with alternatives to digiKam:

F-Spot: A read very often about problems involving changing the originals (especially the exiv data) or moving the pictures into an own file structure. I don't want a program that even considers doing such stuff. Might be that this can be disabled in the properties but you will always live with that fear. But no, never looked into it.

Picasa: Haven't used it for quite a while but the last time I tried it I didn't find all the stuff I want to have. Trees of tags for the pictures, IPTC support etc. It simply was a tool to manage the pictures in albums, make slideshows or rate them.

KPhotoAlbum: I simple was not able to control it. It felt antiquated. Can't remember about objective criticism but it didn't like it.

LightZone: More editor than management tool. The latter is really basic.

BlueMarine: It's still beta, not that much activity going on there. IPTC still not implemented, no guarantee about save file handling.

Image-Viewers with management functionality: Those tools are too powerless. I always missed one or another functionality.

I would even consider spending some money for a neat program or using Wine to run Windows software. The OS community has developed an incredible amount of tools for the photo workflow. You can do everything that is possible in other platforms - except for the management. That's unbelievable!

[amheuwr]

Hi
I use F-Spot with Unbuntu Linux Intrepid. Seems to work fine for me. Have tried all sorts of different photo management tools including Digikam, Blue Marine and Picassa. Digikam misbehaved for me on several occasions often crashing.
Although not immediately struck with F-Spot I decided to persevere and experiment. Making a back up of all my photos first. I then cracked on with learning about the strange way F-Spot arranges it's directories. Think this is what monoceros84 was referring to as well as the ability to modify photos. Once I got used to the  way the programme worked it has been fine for me, with no files being overwritten or accidentally deleted, although i can see how this would be possible. If you modify a photo then it shows whether you are looking at the original photo or one modified in the Gimp or in F-Spot itself. I have not noticed any exif data being overwritten or lost.
The export tools are excellent and it is possible to create neat web albums as well as just plain old file exports. I also use it to export to my web album of choice which is 23hq.com.
I believe that F-Spot developers are in the process of adding tools such as duplicate file finders which will be really useful.
Anyway, that was my twopenneth worth and at the end of the day it is down to personal preference. Quite a few people i know just use nautilus.

[monoceros84]

I then cracked on with learning about the strange way F-Spot arranges it's directories. Think this is what monoceros84 was referring to as well as the ability to modify photos.

So it's true - F-Spot moves your pictures into it's own folder structure? Or you have to create a structure F-Spot likes?
What if I would like to keep the structure I actually have?

[jgsack]

Yes the questions of monoceros84 are of interest to mee, as well.
I get upset when a program starts to "do stuff" (searching, moving???) with my hard disk contents without making it clear what is happening or (especially) whether anything irrevsible is being done!

So any extra words --either of reassurance or of ways to avoid unwanted results-- would be welcome.

Color me paranoid, I guess, .. jim

[eBrnd]

Yep, F-Spot puts the photos in it's own directory tree, it looks like year/month/day/import roll.
I also disliked this at first, but in the end you have all your photos tagged and don't have to worry about where they are in the file structure.

It won't move the photos without asking though - you'll have to "import" them which means it copies them, and it won't delete the originals. In fact it annoys me that I have to delete them manually because I use it to import the photos directly from the memory card of my camera.

If F-Spot ever breaks or I start hating it for some reason, it won't be much of an effort to move the photos into a directory structure like the one I used before, which was year - wherever the phots were taken/import roll if there was more than one.
The only thing I'll be loosing will be the tags (and the comments if I ever make any). And maybe I can figure out some way to pull those tags out of the F-Spot DB and append them to the file name or something...

[monoceros84]

Thanks for this detailed description, eBrnd!

Yep, F-Spot puts the photos in it's own directory tree, it looks like year/month/day/import roll.
I also disliked this at first, but in the end you have all your photos tagged and don't have to worry about where they are in the file structure.

Ok, that's reason enough for me not using F-Spot. I have a great (for me at least) folder structure and won't even consider braking it. And having all those gigabytes twice on my disk is not really a solution.
Why do they force an own structure and can't simply use the given one? 

The only thing I'll be loosing will be the tags (and the comments if I ever make any). And maybe I can figure out some way to pull those tags out of the F-Spot DB and append them to the file name or something...

And that's the next reason. I would never choose a program that can only use it's own data format. If it breaks you will loose all the hours of work you've put in the tags. Software like this has to use a common database format that can be read from several other programs as well - or even better writing the information directly into the IPTC tags of the images. Then you will never loose them and they are software independent.

Those two points WERE (and it seems they still ARE) the reasons why I have chosen digiKam over F-Spot.
Do I really have to install a virtual machine with Windows running just for being able to get a decent photo management tool? Unfortunately, neither Lightroom nor Aperture are running in Wine.

[amheuwr]

And that's the next reason. I would never choose a program that can only use it's own data format. If it breaks you will loose all the hours of work you've put in the tags. Software like this has to use a common database format that can be read from several other programs as well - or even better writing the information directly into the IPTC tags of the images. Then you will never loose them and they are software independent.

Those two points WERE (and it seems they still ARE) the reasons why I have chosen digiKam over F-Spot.
Do I really have to install a virtual machine with Windows running just for being able to get a decent photo management tool? Unfortunately, neither Lightroom nor Aperture are running in Wine.

Although I use F-Spot pretty much as it was designed i.e. all the new directories by year, month etc,  I have read the help files and it would appear to be fairly flexible and they suggest you do not have to import all the photos to the 'photos' directory.
Keeping the tags and comments as  you require would not be possible unless you use the method I use below.
I think what is important is the method in which you decide to back up your albums. I  find the F-Spot export to web gallery very good and I do this to DVD's. All the tags and comments made are saved to  that Gallery. Everything is in HTML so is universally recognised.
I suppose my biggest gripe would be that RAW images have  to be backed  up separately when i use the web gallery method.
One thing is for sure if you if you make the wrong decision as to how to store and view your collections then you could end up wasting a lot of time.

[eBrnd]

Well, copying photos to the program's own directory structure makes sense if you want to directly pull them off your camera and don't care where they'll end up as long as you find them.

I think F-Spot goes the way many programs go these days: The user does not need (or want) to know what's happening behind his windows and desktop. The software cares for all that stuff.

Unfortunately, transparency and flexibility for more advanced users - like being able to handle directories made by the user or backing up photos - are sacrificed for the sake of simplicity in F-Spot... or the developers haven't had the time to implement this stuff yet. Because to me, F-Spot looks like it's not yet finished...

The reason I use it is... well, it came with ubuntu and it does the job. I never needed a photo management software before I got my DSLR, so I didn't know about any alternatives.

My digital compact camera only had a 16MB memory card, so it was 35 photos at a time, just like on a film compact camera, only without having to wait for the pictures to get developed

[monoceros84]

I never needed a photo management software before I got my DSLR, so I didn't know about any alternatives.

Well, that's certainly a point. Yes, I have tons of images. And no, I have no special use for a management system yet. I've always found the images I was looking for.
But I am truly afraid of the future - am I able to find the images I want even in 10 years? Do I still know where the picture was taken and what the name of the people is? I doubt it. In former times this stuff was written into the photo albums. Nowadays all this extra information is not even collected. I know I am very happy when I find some old pictures from 1900 and on the backside the name of the people is written. That brings some personal value to the images. Otherwise I could cut a picture out of the newspaper and would have the same effect...
And exactly that is the reason why I want to tag my images. And why the most important point of a management program is to save this information safely - it has to exist as long as the photos are there.

[lstamm]

Part of my solution to this problem is to use the filesystem as a hierarchical database, with strict attention to naming conventions for the subdirectories and image files.  All my photos that I take are stored under the ~/photos directory, while photos that others send me are stored under the ~/pictures directory.  Then under the main sub-directory I have main topical directories, which can be further divided into more specific topical sub-directories, and  so on.

So for example, I have a ~/photos/hikes subdirectory, and since I do a lot of hiking in the Robson Valley around my home, and in particular in the Mount Robson area, I have a sub-directory called ~/photos/hikes/robsonvalley/mtrobson/kinney-lake_2007108 which contains all the photos taken on that particular hike to the Kinney Lake area near Mt. Robson on Oct. 8, 2007.  All of these photos are named with the convention, 200071008_HHMM--xxx.eee, where HHMM represents the hour and minute the photo was taken, and xxx is a topical name for the photo, and eee represents the extension (either *orf or *jpg, or occasionally *tiff, in my case).  There is also a processed/  and tmp/  sub-directory for files that are in the process of post-processing or are finished products.

I use exiftool to do the basic renaming of the files, which gives me filenames like
YYYYMMDD_HHMM--nnn.eee where nnn represents the last three digits of the camera filenames.  This is scripted, so I can do a whole directory (and sub-directories) at once. Then I have to manually change the nnn part to something meaningful, which does take up time.  I also use exiftool to add tags, comments, and a copyright notice.   And I am way behind in adding all this metadata for my photos.

But by strictly following this naming regime, I can use the normal linux file and text handling utilities, like locate, find, awk, grep. etc, to quickly find all images that meet whatever date or subject criteria I am searching for.  This seems much cleaner and easier to understand that all the other photo management tools I have looked at.

Once I get caught up adding metadata to all the images (if I ever do), I plan to write a script that will use exiftool to extract the metadata, and normal sql commands to dump it into an sqlite database file.  This script would be run as a cron job, so that I always have up to date info in the database.  Then I could query based on metadata, copyright, and file names.

I work part time in a library, so I am well aware of the difficulties in organizing a large collection of items, as well as the necessity for strict adherence to the terms and names allowed in the metadata.  Laxness in this area leads to chaos in short order.

[monoceros84]

Istamm, thank you for this deep look into your system. It doesn't look too bad since it's really independent from any software at all. Only a question: Say you have a 14 days vacation where you do some hiking, some relaxing and some city visiting. Where do you copy your pictures to? Do you split them up into different categories? That won't be good, you loose the connection then. But if you leave them together in a vacation folder you will end up with hiking pictures at different places and won't find all if you are searching for them.
The same issue appears when you are on a hiking trip and shoot a nice portrait of a friend. Or when you see some interesting animals during it that you photograph...

I hope you see what I mean. No matter how you organize those pictures - together because of the same trip or split up into topics - you will always loose information.
In a managements software all the pictures of one trip will be lying in the same folder but can be tagged e.g. with "animals", "friends" and "beach".
If I would search all of the images of say my friend Wilber I would simply cross the box in the software with the Wilber tag and all the pictures tagged with it will appear.

[lstamm]

Monoceros, yes I understand your question and it is one I have also wrestled with.  At first, I tried to solve it by utilizing symbolic links to place a link back to the original file under the various appropriate subject sub-directories.  This quickly proved unwieldy and unworkable, especially when doing some reorganization of the filesystem.

The ultimate solution is to enter the appropriate subject tags in the exif data, and then use a database search of the exif data of the entire photo collection to find all those that match your search criteria.  But in order for this to be really successful, there has to be an authoritative list of tag terms allowable, because a search for "friends" and "portraits" will not return a hit for photos tagged with "friend" and "portrait", for example.  I hope you see what the problem I am trying to illustrate.

So until I finally decide on an authoritative list for my photo collection, and actually get all the metadata entered into the photo files, I am relying on accurate file naming.

I took a cross-Canada driving trip last summer, so my photos of that trip are organized as follows: ~/photos/holidays/cross-canada_200806/{mountains,prairies,shield,st-lawrence,maritimes}, with further sub-directories under the geographic sub-directories as needed.  For example, I have a photo named ~/photos/holidays/cross-canada_200806/prairies/lake-winnipeg/20080624_1612--daniel-fishing_2.jpg which is the second of a series of photos of Daniel fishing on the shores of Lake Winnipeg on June 24, 2008, at 4:12 PM. 

Even this is not an entirely accurate method of naming, because Lake Winnipeg is located on the boundary of the prairies and the Canadian shield, so it is neither totally prairie-like nor totally shield-like.  Also I wasn't always prompt in updating the time set in my camera, nor was I always sure what the correct time-zone was, so I can't really vouch for the correctness of the timestamp in the filename. 

But issuing a command like "locate -i daniel | grep photos | grep -i fish | xargs qiv -m" will return all photos of Daniel fishing and display them with the qiv image viewer, or give an error message if they are raw files.

This is the reason I am looking for a simple image viewer that will display raw files.   If I replace "qiv" with "gqview" in the above example, it simply opens up in the directory of the first filename returned, and doesn' display all the results returned.  Other file-manager type image viewing applications have the same behaviour.  The simple image viewers like qiv, xv, or pho don't display raw files.

I am currently trying to "normalize" the metadata database of our local library's collection, which was originally created without a coherent authoritative list of allowable terms.  I can only say that it is much, much easier to do it right the first time than to correct it later.

[monoceros84]

Hhmm, writing this stuff into the file name is a possibility helping in such situations.
This whole method sounds very interesting, but also very complex and time-consuming.
Please keep me updated on the results of your search about the exif database and the image viewer. Maybe I'll become infected by your idea