Re: Editing directory names.

[Indulis Bernsteins <indulis b au1 ibm com>]

The problems described are a result
of the "file-oriented" approach to managing photos.

We don't do it for MP3s, I don't see
why it is a good idea for photos.

With MP3s, it doesn't matter if I have
half an album in one directory, and the other half in another. I can still
ask my music manager  for all tracks on the album  "Time
capsule" by the B52s, and the GUI presents me the album.  No
fuss- it doesn't care where the files live, or where I have moved the music
to, If I move the files, I just tell the music manager to rescan the directories
and it is done.

With this approach, files are seen as
a "behind the scenes" resource, not the primary way in which
you view and manage your data.  The filesystem hierarchy is relatively
unimportant.

I am using Lightroom by Adobe which
uses this "photo-centric" rather than "file-centric"
approach.  If there are files missing from where I last had them it
notices, and asks me where to look.  This is pretty neat, because
I am often doing some editing here on the laptop, some there on my fileserver.
And photos get moved from one to the other,  Even on my server, I
occasionally do a  apring clean of my filesystems, so need any photo
manager ot be able to easily cope with a move.  With LR I can view
a set of photos by metadata, when I "checked them in", or directory
if I really want to.

If f-spot wanted to do something similar,
all the metadata is there to find photos by camera taken with, date, etc
etc etc, so you can pretty easily match up the file by checking (in order
of priority)
- metadata for camera & photo ID
matches
- metadata for date/time matches
- size of file matches
- DCIM name embedded in filename matches

Or a score based on a combination of
the above.

Other benefits are that you can easily
come up with a "delete duplicates", or even a retention policy,
where you can specify different filesystems or physical devices to keep
multiple copies on, and f-spot knows if it needs to either delete unnecessary
duplicates, or make additional ones for redundancy.  Or delete JPEGs
older than 1 year if there is a larger version available.  Lots that
can be done to make f-spot extensions that make life easier for us when
the "file-oriented" approach is changed to a "photo-oriented"
approach based on the photo metadata. 

Anyway, I raised this about a year ago
and was poo-pooed that f-spot is for "consumers" and that this
is somehow a justification for a simplistic (and can I say dated?) approach
to managing photos.  Well, I think personally that a photo-centric
(could also call it a metadata-centric) approach can make the job of managing
photos a LOT easier than the file-oriented approach, and if it makes life
easier for those of us with 10,000 photos, it will probably also be easier
for those with 1,000!  

I even thought of coding a fuser filesystem
that pretended to f-spot and other file-oriented software that it was looking
at static files, whereas behind the scenes I'd automatically create links
to the photos.  Then I could have a directory of /camera-body-serial/year/month
(read from the photo metadata), and just keep my photos whereever I want
to without f-spot knowing when I move them around, and just let the fuser
filesystem mask the file moves for me.

Indulis
(still using Windows and Adobe LR for my raw editing/workflow
for the time being)