Bug 126821 - Handle existing read-only photo trees without copying (i.e. virtual albums)
Summary: Handle existing read-only photo trees without copying (i.e. virtual albums)
Alias: None
Product: digikam
Classification: Unclassified
Component: Database-Albums (show other bugs)
Version: 0.8.1
Platform: Debian testing IRIX
: NOR wishlist with 42 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2006-05-05 23:50 UTC by wjl
Modified: 2017-07-25 18:53 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.3.0


Note You need to log in before you can comment on or make changes to this bug.
Description wjl 2006-05-05 23:50:36 UTC
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.
Comment 1 mauro 2007-02-12 00:51:27 UTC
This wishlist item it's SO important for professional use, because it's really normal to use photos on multiple hard disks! copying photos to a unique folder is non-sense if you are looking to build a huge database. Mine is about 15000 images, I couldn't stock them in only one local folder of digikam!

please resolve this issue!
Comment 2 Gerhard Kulzer 2007-02-12 09:10:45 UTC
I agree that multiple root directories should be supported by digiKam. It is planned.
In the mean time you can mount all your different locations under the one root directory for digiKam, unless - and that's probably not your case - the root is a nfs share. NFS doesn't work with sqlite3, our database. But as a sub-directory nfs should be ok. Only the digikam.db file must not be on nfs.

Comment 3 Arnd Baecker 2008-01-03 19:27:41 UTC
*** Bug 150181 has been marked as a duplicate of this bug. ***
Comment 4 caulier.gilles 2011-12-13 08:55:28 UTC
For me, Since 1.x release digiKam support multiple repositories as root collection, as local, removable, and remote media.

I think this file can be closed now. Right ?

Gilles Caulier
Comment 5 Kvaks 2012-05-18 13:49:54 UTC
There's still the issue of virtual albums/collections. File stays in one folder on the file system, but the image can be added/removed to any virtual album(s) independent of file location. This is a really useful feature missing in Digikam. Using tags for this purpose is a poor substitute, even if it's a similar feature.
Comment 6 caulier.gilles 2014-08-28 16:28:00 UTC
The multiple root albums (collections) are supported since a while.

Removable media are supported too in setup collection dialog

Gilles Caulier
Comment 7 caulier.gilles 2014-08-28 16:29:54 UTC
Problems remaining about removable media management are registered to bug # 114539

Gilles Caulier