'Album-less' digikam?

[Yannick Le Teigner]

Hi,

I wrote a small and very basic application to manage my photo collection. I don't use albums, but only use tags to organize my images. My application automatically puts the images in the correct destination folder based on the image's date (i.e. /rootfolder/2008/11/20).
Since I don't have an album concept, I display only 50 images at a time, and use prev/next buttons to paginate through my collection.
Advantage is that I only need to worry about tags, I don't need to worry about Albums and directory structure on disk.


Is it possible to apply a similar process to managing images in Digikam?
I could use only one album, but I have some concerns:
- Digikam display by default all the images in the selected album, could that impact performance for very large (unique) album?
- Similarly, all the images would be put on the same location on the hard drive, could that be a performance issue for some FS?

Any inputs would be greatly appreciated.

Thanks,
Yannick

[depot]

Hello Yannick,

I use Digikam (0.9 series) like you describe it. What I do is this:

- My images are kept in a folder called 'collection'. Inside this folder I use a year/month structure for further division. Some year/month folders contain various sub-folders. E.G. 08-12/my_birthday etc.
- I also have a folder called 'digikam_symlink_dir/all_images'. This folder contains symlinks to all the images in the 'collection' folder. There is no further division in the 'digikam_symlink_dir/all_images' folder. All symlinks are kept at root level.
- The symlinks are created/synchronized with a simple bash script.
- At the moment this folder contains over 9400 symlinks linking to an equal number of images kept in 'collection'.
- The digikam album library path is set to digikam_symlink_dir. The sub-folder 'all_images' acts as my one and only digikam album.

Performance is excellent. Core2duo machine with 4GB ram.


Advantage:
- only one 'real' album in digikam, all other albums are virtual and managed by tags
- search/browse results are always presented under the one digikam album 'all_images' (before when I selected for example all pictures tagged 'chiara' they where presented with album header banners above the pictures, thus not giving me a nice overview
- no worries about the folder names at file system level

Drawback:
- you have to manually keep the symlink folder synchronized
- all delete actions you perform from within digikam are applied to the symlink (so you delete the symlink and not the real image (I work around this by tagging the images I want to delete and after that I run a delete script over the marked for deletion selection)
- all images edit actions from within digikam create a new image file in the symlink folder, overwriting the symlink, and not updating the original image in the collection folder (this in fact is something I do not understand, I expected digikam to update the original)

Hope this helps.

Regards,

Jeroen

* http://flickr.com/photos/jeroenleijen


On Fri, Jan 23, 2009 at 03:22:01PM -0800, Yannick Le Teigner wrote:

>
> Hi,
>
> I wrote a small and very basic application to manage my photo collection. I
> don't use albums, but only use tags to organize my images. My application
> automatically puts the images in the correct destination folder based on the
> image's date (i.e. /rootfolder/2008/11/20).
> Since I don't have an album concept, I display only 50 images at a time, and
> use prev/next buttons to paginate through my collection.
> Advantage is that I only need to worry about tags, I don't need to worry
> about Albums and directory structure on disk.
>
>
> Is it possible to apply a similar process to managing images in Digikam?
> I could use only one album, but I have some concerns:
> - Digikam display by default all the images in the selected album, could
> that impact performance for very large (unique) album?
> - Similarly, all the images would be put on the same location on the hard
> drive, could that be a performance issue for some FS?
>
> Any inputs would be greatly appreciated.
>
> Thanks,
> Yannick
> --
> View this message in context: http://www.nabble.com/%27Album-less%27-digikam--tp21612720p21612720.html
> Sent from the digikam-users mailing list archive at Nabble.com.
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jonas Norlander]

2009/1/24 depot @ xs4all. nl <[hidden email]>:

>
> Hello Yannick,
>
> I use Digikam (0.9 series) like you describe it. What I do is this:
>
> - My images are kept in a folder called 'collection'. Inside this folder I use a year/month structure for further division. Some year/month folders contain various sub-folders. E.G. 08-12/my_birthday etc.
> - I also have a folder called 'digikam_symlink_dir/all_images'. This folder contains symlinks to all the images in the 'collection' folder. There is no further division in the 'digikam_symlink_dir/all_images' folder. All symlinks are kept at root level.
> - The symlinks are created/synchronized with a simple bash script.
> - At the moment this folder contains over 9400 symlinks linking to an equal number of images kept in 'collection'.
> - The digikam album library path is set to digikam_symlink_dir. The sub-folder 'all_images' acts as my one and only digikam album.
>
> Performance is excellent. Core2duo machine with 4GB ram.
>
>
> Advantage:
> - only one 'real' album in digikam, all other albums are virtual and managed by tags
> - search/browse results are always presented under the one digikam album 'all_images' (before when I selected for example all pictures tagged 'chiara' they where presented with album header banners above the pictures, thus not giving me a nice overview
> - no worries about the folder names at file system level
>
> Drawback:
> - you have to manually keep the symlink folder synchronized
> - all delete actions you perform from within digikam are applied to the symlink (so you delete the symlink and not the real image (I work around this by tagging the images I want to delete and after that I run a delete script over the marked for deletion selection)
> - all images edit actions from within digikam create a new image file in the symlink folder, overwriting the symlink, and not updating the original image in the collection folder (this in fact is something I do not understand, I expected digikam to update the original)

This is a bug that happened to me to and I spent several hours to
restore pictures from backup a couple times before I realised it was
only when I changed a tag on a symlinked picture it would happen. I
searched the net and if I remember right it is a known bug.

/ Jonas
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Yannick Le Teigner]

Hello Jeroen,

depot wrote

Performance is excellent. Core2duo machine with 4GB ram.

Good! This is reassuring to know that with close to 10k images you still have good performance. You brought me one step closer to use Digikam full time. :)

depot wrote

Drawback:
- you have to manually keep the symlink folder synchronized
- all delete actions you perform from within digikam are applied to the symlink (so you delete the symlink and not the real image (I work around this by tagging the images I want to delete and after that I run a delete script over the marked for deletion selection)
- all images edit actions from within digikam create a new image file in the symlink folder, overwriting the symlink, and not updating the original image in the collection folder (this in fact is something I do not understand, I expected digikam to update the original)

Did you try it the other way around? Storing your images in the flat directory (managed by Digikam), and have your script create the symlinks in your hierarchical directory structure? That might help with some of the drawbacks?


Thanks again,
Yannick