[Digikam-devel] [Bug 126821] New: handle existing read-only photo trees without copying (i.e. virtual albums)

[wjl at icecavern.net]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=126821         
           Summary: handle existing read-only photo trees without copying
                    (i.e. virtual albums)
           Product: digikam
           Version: 0.8.1
          Platform: Debian testing
        OS/Version: IRIX
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
        AssignedTo: digikam-devel kde org
        ReportedBy: wjl icecavern net


Version:           0.8.1 (using KDE KDE 3.5.2)
Installed from:    Debian testing/unstable Packages
OS:                Irix

digiKam really ought to handle pre-existing read-only trees of photos, with the following characteristics. What I'm describing here is how I imaging this feature working. Obviously improvements/tweaks/changes would be fine as long as the main idea is preserved:

  * The original source location is not modified in any way. The location may be read-only, or we just don't want digiKam messing with the directory. Any album meta-data is stored locally.

  * Upon initial "import", digiKam does *NOT* copy all the files to a local album, but instead scans the files, and locally stores metadata about the album (e.g. paths, filenames, thumbnails, whatever). 

  * Using the data from scanning the source location, digiKam would create "virtual" albums (e.g. initially per-directory of the imported source) that work like normal albums, but don't ever copy the actual images locally.

  * If files from these albums are moved between other "virtual" albums, the actual file is not moved or copied, just the meta-info about what album the file is in is updated.
 
  * Any operation which requires modifying the virtual album itself would not affect the original files, but would create a local copy; e.g. copying to a "real" album, or rotating a picture.

The reason I suggest this is because, often, users have one of the following scenerios:

  1) A group/family/organization has multiple computers, multiple cameras, multiple accounts. Different people have different permissions, want to sort albums differently, manage both "group" photos and personal photos, etc. In this case, the pre-existing read-only tree might be in another user's home directory, or shared read-only over SMB or NFS, for example.

  2) A user has pre-existing albums on read-only media, like CDs, but would like to use digikam to tag, sort, and manage photos, without copying 100's of CDs worth of photos to their local home directory (which would be infeasible because of space). (No special "media management" would be needed; some virtual albums would just have files missing when they go looking in /media/cdrom/some/path/name and don't find a file.)

For a real concrete example, my wife and I both share a 6 GiB gallery of photos that is read-only on a computer (not either of our desktop computers--we have *many* computers), accessed via NFS. I download pictures we take from our cameras onto the server via script with gphoto2 and they are stored automatically into year/month areas. It would be nice if we could each use digiKam to via and sort these photos to our own liking. Unfortunately, neither of us can ever get started, because either 1) we point our album at the server, and get errors because it's read-only (and so wouldn't really work anyway), or 2) import the photos, which would mean we EACH have a wasteful 6 GiB, out-of-sync album copy and would have to continually update it.

Anyway, maybe this is beyond the intended scope of digiKam, but it seems like a really important feature for anyone that isn't committed to using digiKam exclusively and then only on a single-user read/write set of photos.