Digikam file management

[stefan-119]

Hi,

I'm a not-yet digikam user. There are some things about digikam which  
I just can't get from the websites feature list. As building on OSX is  
a bit time consuming, I'd like to ask about them here first.

As I tend to use my photos in other applications too, I need to have  
them neatly organised on the filesystem. All tags, categories and  
albums are nice features inside digicam, but how does this translate  
to the 'outside'?

Does a move/copy inside digicam reflect on the filesystem?
Does a (auto-)rename reflect on the filesystem?
Can I copy the EXIF dates onto the file dates?
Does Digikam keep track of multiple copys of the same file and does it  
use symlinks to reduce disk space?
Can Digikam handle photos on external media? Like with still  
displaying a thumbnail and info, but asking for the hdd/dvd/cd for the  
actual image file?

Bonus: Can it save Albums created by e.g. tag search as file system folders?

None of the big commercial tools does all that. What about digikam?
Looks quite good otherwise!

Thank for your answers.

Stefan



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

[Micha? Smoczyk]

[hidden email] wrote:

> Does a move/copy inside digicam reflect on the filesystem?
Yes

> Does a (auto-)rename reflect on the filesystem?
Yes

> Does Digikam keep track of multiple copys of the same file and does it  
> use symlinks to reduce disk space?
I think no, it doesn't.

--
/\/\ichau, admin [malpka] nocnyrzepin [kropa] net
http://www.nocnyrzepin.net


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

[Markus Spring]

Micha? Smoczyk schrieb:
> [hidden email] wrote:
>> Does Digikam keep track of multiple copys of the same file and does it  
>> use symlinks to reduce disk space?
> I think no, it doesn't.
Myself I have often about the possibility to replace copying by linking and I
would see this as a really important feature.
Are there any technical reasons against it?

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

[Tim Jenness]

On Wed, Jul 29, 2009 at 8:01 AM, Markus Spring <[hidden email]> wrote:

Micha? Smoczyk schrieb:

> [hidden email] wrote:
>> Does Digikam keep track of multiple copys of the same file and does it
>> use symlinks to reduce disk space?
> I think no, it doesn't.

Myself I have often about the possibility to replace copying by linking and I
would see this as a really important feature.
Are there any technical reasons against it?

I've wondered about this as well. Many times I create a temporary album and copy files into it for exporting. Takes a long time to copy all the files in and then and it takes a lot of disk space.

It would really have to be hard-links to make things easier to track. With a soft link you have to remember which one is the primary file and if someone deletes that from the album you need to change all the soft links and make one of them into a file. Much more painful than letting the file system keep track (although I imagine you still have problems with keeping the database metadata in sync).

I'm not sure whether hard links are portable to windows though or if KDE gives you access to them.

Tim

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

[Gilles Caulier-4]

2009/7/29 Tim Jenness <[hidden email]>:

>
>
> On Wed, Jul 29, 2009 at 8:01 AM, Markus Spring <[hidden email]> wrote:
>>
>> Micha? Smoczyk schrieb:
>> > [hidden email] wrote:
>> >> Does Digikam keep track of multiple copys of the same file and does it
>> >> use symlinks to reduce disk space?
>> > I think no, it doesn't.
>> Myself I have often about the possibility to replace copying by linking
>> and I
>> would see this as a really important feature.
>> Are there any technical reasons against it?
>
> I've wondered about this as well. Many times I create a temporary album and
> copy files into it for exporting. Takes a long time to copy all the files in
> and then and it takes a lot of disk space.
> It would really have to be hard-links to make things easier to track. With a
> soft link you have to remember which one is the primary file and if someone
> deletes that from the album you need to change all the soft links and make
> one of them into a file. Much more painful than letting the file system keep
> track (although I imagine you still have problems with keeping the database
> metadata in sync).
> I'm not sure whether hard links are portable to windows though or if KDE
> gives you access to them.
> Tim

tags == portable hard links (:=)))

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

[Markus Spring]

Tim Jenness schrieb:
> I've wondered about this as well. Many times I create a temporary album
> and copy files into it for exporting. Takes a long time to copy all the
> files in and then and it takes a lot of disk space.
Same situation here
> It would really have to be hard-links to make things easier to track.
definitely
> ...
> I'm not sure whether hard links are portable to windows though or if KDE
> gives you access to them.
Definitely not portable. But you could make the copy process make to try the
hardlinking first and if that fails to resort to the normal copy.

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

On Wednesday 29 July 2009 20:45:47 Tim Jenness wrote:

> I've wondered about this as well. Many times I create a temporary album and
> copy files into it for exporting. Takes a long time to copy all the files
> in and then and it takes a lot of disk space.
>
Have to second Gilles: why not use tags and virtual albums? If you want to
process in special way you still need real copies if not tags are enough.

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

[Markus Spring]

Mikolaj Machowski schrieb:
> Have to second Gilles: why not use tags and virtual albums? If you want to
> process in special way you still need real copies if not tags are enough.

3 cases:
* burn a cd - impossible from tags only
* create an album with for example Jalbum
* upload it to a printing service on the net (this is a big advantage of picasa
that you can do this out of the application)

In all those 3 cases copying the files into a separate folder is necessary

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

On Wednesday 29 July 2009 17:36:44 [hidden email] wrote:

> Hi,
>
> I'm a not-yet digikam user. There are some things about digikam which
> I just can't get from the websites feature list. As building on OSX is
> a bit time consuming, I'd like to ask about them here first.
>
> As I tend to use my photos in other applications too, I need to have
> them neatly organised on the filesystem. All tags, categories and
> albums are nice features inside digicam, but how does this translate
> to the 'outside'?
>
> Does a move/copy inside digicam reflect on the filesystem?

Yes.
> Does a (auto-)rename reflect on the filesystem?
Yes.
> Can I copy the EXIF dates onto the file dates?
Not yet.
> Does Digikam keep track of multiple copys of the same file and does it
> use symlinks to reduce disk space?
No (symlinks aren't portable).
> Can Digikam handle photos on external media?
Yes..
> Like with still
> displaying a thumbnail and info, but asking for the hdd/dvd/cd for the
> actual image file?
... and 'I don't know'. There are all necessary fundamentals (recent move to
thumbnails database) but I am not sure if this feature was finalized.
>
> Bonus: Can it save Albums created by e.g. tag search as file system
> folders?
Not automatically: create virtual album, select all, context menu, "New album
from selection".

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

[Tim Jenness]

On Jul 29, 2009, at 8:52 AM, Gilles Caulier wrote:
>
> tags == portable hard links (:=)))
>

Yes. And that's what I've been using. But creating temporary tags is  
painful at times (and it's only in beta3 that the combined date view  
independent of albums was possible) and I definitely don't want to  
have to write the temporary tag to the file and then have to remove it  
again. Of course I could disable the writing of metadata to files and  
then turn it back on but that is a pain and I will probably forget.  
And do all options available with albums work for tag selections?

--
Tim Jenness



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

[Gilles Caulier-4]

2009/7/29 Mikolaj Machowski <[hidden email]>:

> On Wednesday 29 July 2009 17:36:44 [hidden email] wrote:
>> Hi,
>>
>> I'm a not-yet digikam user. There are some things about digikam which
>> I just can't get from the websites feature list. As building on OSX is
>> a bit time consuming, I'd like to ask about them here first.
>>
>> As I tend to use my photos in other applications too, I need to have
>> them neatly organised on the filesystem. All tags, categories and
>> albums are nice features inside digicam, but how does this translate
>> to the 'outside'?
>>
>> Does a move/copy inside digicam reflect on the filesystem?
> Yes.
>> Does a (auto-)rename reflect on the filesystem?
> Yes.
>> Can I copy the EXIF dates onto the file dates?
> Not yet.
>> Does Digikam keep track of multiple copys of the same file and does it
>> use symlinks to reduce disk space?
> No (symlinks aren't portable).
>> Can Digikam handle photos on external media?
> Yes..
>> Like with still
>> displaying a thumbnail and info, but asking for the hdd/dvd/cd for the
>> actual image file?
> ... and 'I don't know'. There are all necessary fundamentals (recent move to
> thumbnails database) but I am not sure if this feature was finalized.

Yes, it's not yet finalized, but all is ready to do it...

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

On Wednesday 29 July 2009 22:18:37 Markus Spring wrote:
> Mikolaj Machowski schrieb:
> > Have to second Gilles: why not use tags and virtual albums? If you want
> > to process in special way you still need real copies if not tags are
> > enough.
>
> 3 cases:
> * burn a cd - impossible from tags only
> * create an album with for example Jalbum

In those two cases definitely should be fixed in digiKam handling of tags and
not by introducing non-portable, hackish feature.

BTW - don't know how exactly JAblum works but if it can accept list of files
from command line you can use "Open with..." menu.

> * upload it to a printing service on the net (this is a big advantage of
> picasa that you can do this out of the application)

Probably could be achieved by future Nepomuk interface.

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

[stefan-119]

Thank you for you answers. Sounds very, very promissing to me. I will  
give it a try. I was very disappointed with even the expensive tools  
like lightroom and aperture, let alone iPhoto.

They tend to either sort my images into cryptic databases not  
accessible from other tools, or just leave them where they are without  
imposing some ordering or naming scheme.

The 'use symlinks for space efficency' question should have been  
marked as 'bonus' too. I know that it would be a major task to  
implement. They are not portable if you use the filesystem ones and  
very difficult to use if implemented entirely in digikam.

As for the 'just use tags' answer: they are just no good if you use  
your photos outside of digikam. I for example use my pictures in  
OpenOffice, Keynote, Hugin, Gimp, Firefox and Safari, SketchUp, Mail,  
iMovie and JOSM (probably forgetting a few). You can't possibly  
implement all that functionality in digikam (a.k.a. 'lets burn cds  
from inside digikam').

Just fooling around: A great way of building a bridge would be a small  
widget-like  application just as a browser into the digikam database  
(with tags and such) which would allow drag-and-drop like from a  
filesystem browser into external programms. (Don't take that too  
seriously. It's not a feature request or anything.)

Nobody has build a ready to use MacOSX package for beta3 yet, right?  
So lets start doing it the long way then ...

thx again,

Stefan



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

Your wish is related to this one :
https://bugs.kde.org/show_bug.cgi?id=195426
and this one :
https://bugs.kde.org/show_bug.cgi?id=109631

I think the kio slave solution would work only inside kde apps, isn't it ?

Julien

[hidden email] a écrit :

>
> As for the 'just use tags' answer: they are just no good if you use  
> your photos outside of digikam. I for example use my pictures in  
> OpenOffice, Keynote, Hugin, Gimp, Firefox and Safari, SketchUp, Mail,  
> iMovie and JOSM (probably forgetting a few). You can't possibly  
> implement all that functionality in digikam (a.k.a. 'lets burn cds  
> from inside digikam').
>
> Just fooling around: A great way of building a bridge would be a small  
> widget-like  application just as a browser into the digikam database  
> (with tags and such) which would allow drag-and-drop like from a  
> filesystem browser into external programms. (Don't take that too  
> seriously. It's not a feature request or anything.)
>
>  

Hi Stefan,

Your wish is related to this one :
https://bugs.kde.org/show_bug.cgi?id=195426
and this one :
https://bugs.kde.org/show_bug.cgi?id=109631

I think the kio slave solution would work only inside kde apps, isn't it ?

Julien

> Nobody has build a ready to use MacOSX package for beta3 yet, right?  
> So lets start doing it the long way then ...
>
> thx again,
>
> Stefan
>
>
>
> _______________________________________________
> 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

[Markus Spring]

Mikolaj Machowski schrieb:
>> 3 cases:
>> * burn a cd - impossible from tags only
>> * create an album with for example Jalbum
>
> In those two cases definitely should be fixed in digiKam handling of tags and
> not by introducing non-portable, hackish feature.

I would not use the word "hackish" for a major feature of unix file systems.
Talking about hard links, I see it these a rather intelligent way to save space
while providing the same file at different locations. symlinks are a bit more
difficult to handle but still work perfectly at the basis of our operating
system. That their implementation in Windows is broken by design is not a
problem of the symlinks.

I am not shure if the approach to do everything from inside digikam is really a
good one. Unix grew on the principle of having small dedicated tools that could
be stacked. I do not see why this should not be valid any more.

Having a copy function that tries to hardlink and resorts to copying if
hardlinking is impossible should not break any mechanisms

> BTW - don't know how exactly JAblum works but if it can accept list of files
> from command line you can use "Open with..." menu.
No, as far as I know Jalbum works with its own file-open dialog.

>> * upload it to a printing service on the net (this is a big advantage of
>> picasa that you can do this out of the application)
Well, but until this is available an improved/speed up copy functionality would
bring an improvement for a lot of operations.

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

[stefan-119]

I know I should be in favour of the hardlinks, as I requested them, but...

>
> Having a copy function that tries to hardlink and resorts to copying if
> hardlinking is impossible should not break any mechanisms
>

It would be a bit more to it than replacing/extending the copy mechanism.
Whenever you change a property of a hardlinked file, you have to ask  
the user if he wants to change just the one file (and thereby create a  
new independent copy) or alter all files. I don't know the  
architecture of digikam, but I suppose this would mean a lot of places  
where a routine like that needs to be implemented.

It would be a major feature at least for the *nix systems nevertheless...

Stefan



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

[Markus Spring]

[hidden email] schrieb:
> It would be a bit more to it than replacing/extending the copy mechanism.
> Whenever you change a property of a hardlinked file, you have to ask  
> the user if he wants to change just the one file (and thereby create a  
> new independent copy) or alter all files. I don't know the  
> architecture of digikam, but I suppose this would mean a lot of places  
> where a routine like that needs to be implemented.
ok, I forgot to think about this field of problems.
As directory-relateed properties I see last access, modification, access rights.
These are kept synchronous with hardlinked files.

I just tested and made a hardlink copy of a jpg file and then modified it with
digikam's image editor. The result is as such:

springm@denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22 22:59 farbkreis.jpg
1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22 22:59 test.jpg

# now modifying the file test.jpg and saving it in the image editor

springm@denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
1744903131 220 -rw-rw-r-- 1 springm springm 221702 2008-11-22 22:59 farbkreis.jpg
1761442766  60 -rw-rw-r-- 1 springm springm  60691 2009-07-30 13:33 test.jpg
springm@denkbrett:~/Bilder/test$

obviously the image editor writes a new file, removes the original one and
renames the new file to the original name. So at least in this respect we would
not have any difficulties. For other operations this has to be tested.

I think this is the behaviour that most users would expect: a copied file is a
copy and treated separatedly from the original.
But to avoid all troubles I could imagine to make this an 'expert option' and
offer it additionally to the traditional copy method.

> It would be a major feature at least for the *nix systems nevertheless...
Definitely!

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

[Marcel Wiesweg]

> As for the 'just use tags' answer: they are just no good if you use
> your photos outside of digikam. I for example use my pictures in
> OpenOffice, Keynote, Hugin, Gimp, Firefox and Safari, SketchUp, Mail,
> iMovie and JOSM (probably forgetting a few). You can't possibly
> implement all that functionality in digikam (a.k.a. 'lets burn cds
> from inside digikam').
>
> Just fooling around: A great way of building a bridge would be a small
> widget-like  application just as a browser into the digikam database
> (with tags and such) which would allow drag-and-drop like from a
> filesystem browser into external programms. (Don't take that too
> seriously. It's not a feature request or anything.)

You can drag from digikam to any place that accepts drags like you do from a
filesystem browser. The problem (which I also encounter sometimes) is that
often e.g. web upload services implemented in Java dont accept normal drags.

Btw, it would a pretty simple job for a KIPI plugin to "Create folder with
symlinks" of the current (virtual) album in digikam.

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

[Geert Janssens]

On Thursday 30 July 2009, Markus Spring wrote:
> [hidden email] schrieb:
> > It would be a bit more to it than replacing/extending the copy mechanism.
> > Whenever you change a property of a hardlinked file, you have to ask
> > the user if he wants to change just the one file (and thereby create a
> > new independent copy) or alter all files. I don't know the
> > architecture of digikam, but I suppose this would mean a lot of places
> > where a routine like that needs to be implemented.
>
I was going to write a similar remark, but you beat me to it. :-)

> ok, I forgot to think about this field of problems.
> As directory-relateed properties I see last access, modification, access
> rights. These are kept synchronous with hardlinked files.
>
> I just tested and made a hardlink copy of a jpg file and then modified it
> with digikam's image editor. The result is as such:
>
> springm@denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
> 1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22 22:59
> farbkreis.jpg 1744903131 220 -rw-rw-r-- 2 springm springm 221702 2008-11-22
> 22:59 test.jpg
>
> # now modifying the file test.jpg and saving it in the image editor
>
> springm@denkbrett:~/Bilder/test$ ls -lisa farbkreis.jpg test.jpg
> 1744903131 220 -rw-rw-r-- 1 springm springm 221702 2008-11-22 22:59
> farbkreis.jpg 1761442766  60 -rw-rw-r-- 1 springm springm  60691 2009-07-30
> 13:33 test.jpg springm@denkbrett:~/Bilder/test$
>
> obviously the image editor writes a new file, removes the original one and
> renames the new file to the original name. So at least in this respect we
> would not have any difficulties. For other operations this has to be
> tested.
>

This is interesting, but non-consistent. If the file being edited is
hardlinked by other files, changing the original file should reflect this
change in all files. That's how I would expect a link to behave. In fact, I
tend to consider this a bug, given the link vs copy metaphors being used.

Also this is not only about the image editor. You can change your hardlinked
files with other editors, like the Gimp, Krita,... All these editors should
exhibit the same behavior with hardlinked files or we're up for some major
confusion.

> I think this is the behaviour that most users would expect: a copied file
> is a copy and treated separatedly from the original.
> But to avoid all troubles I could imagine to make this an 'expert option'
> and offer it additionally to the traditional copy method.
>
Indeed.

And quite honestly, I don't think it's digikam that should define how
hardlinks should be treated. The scope of it is much wider than one image
management tool.

I think it would better if this were defined and implemented at the desktop
level (ie KDE/Gnome/Freedestkop.org in general). Digikam would then free to
add this feature as defined by KDE/Freedesktop.org in a way that is consistent
across applications.

> > It would be a major feature at least for the *nix systems nevertheless...
>
> Definitely!
>
> Markus
> _______________________________________________
> 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

[Markus Spring]

Geert Janssens schrieb:

> On Thursday 30 July 2009, Markus Spring wrote:
>> obviously the image editor writes a new file, removes the original one and
>> renames the new file to the original name. So at least in this respect we
>> would not have any difficulties. For other operations this has to be
>> tested.
>>
> This is interesting, but non-consistent. If the file being edited is
> hardlinked by other files, changing the original file should reflect this
> change in all files. That's how I would expect a link to behave. In fact, I
> tend to consider this a bug, given the link vs copy metaphors being used.
>

This probably can considered as a bug, but I see it as a widely used behaviour
pattern, used to avoid data loss in the most critical phase of program execution
of writing modified content.
When I write utilities for my own usage, I do often resort to this solution.
When the program fails or is killed in the moment of writing, the old file is
left intact and the residues of the incompletely written new file can be
discarded later. So I would not see this as a bug but as a valuable feature,
especially when dealing with image files of which many of the users don't make
backups first.

> Also this is not only about the image editor. You can change your hardlinked
> files with other editors, like the Gimp, Krita,... All these editors should
> exhibit the same behavior with hardlinked files or we're up for some major
> confusion.
just checked the gimp: it indeed writes the file directly. So there definitely
is confusion ahead.

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