[Digikam-users] New User: is digiKam right for me? and if not, what alternative?

Tue Jan 29 06:30:34 GMT 2008

Am Monday 28 January 2008 schrieb Yuval Levy:
> Arnd Baecker wrote:
> > For just viewing you could consider using showfoto,
> > which is part of the digikam package.
>
> I had to do a sudo apt-get install showfoto. I looked at showfoto, as
> well as at gThumb reccomended by Yan Seiner (thanks!) gqview and again
> at digiKam.
>
> > Another programm which is well suited for a fast display of
> > images is gqview.
>
> and the winner is...
>
> ... it would be quite arrogant to declare a winner after such a short
> time for testing. moreover, there are as many different workflows as
> there are users, so what works for me might not work for you.
>
> I have a few observations though.
>
> All above tools can load the RAW images of my Canon 350D, both from a
> local copy as well as from the network drive. A testimonial to the
> maturity of some of the code.
>
> However there is a big variation in speed, and speed, i.e. the time I
> have to wait until the display is updated, is important to me. In
> testing it I made sure caches are empty.
>
> gqview was the fastest. its user interface is IMHO rough and unpleasant
> to use, but I am not sure that a list dedicated to digiKam is the right
> place to suggest improvements to qgview.
>
> digiKam was significantly slower than gqview. Unfortunately too slow for
> me. So my question is: why is it so slow (after all, most tools use
> dcraw for RAW decoding)? and: can I do something to help change that?

I can only second what Gilles has already said: compare the same things!

digiKam can't be slow in RAW decoding because if you compare it to dcraw it 
matches. In other words, it can't be faster than dcraw. If other applications 
are, they use degraded modes of dcraw like half resolution and 8 bit 
decoding, linear interpolation.

Gerhard

> > But: even for well-sorted image collections digikam provides
> > features, which I find extremely useful:
> > - rating of images:
> >   Together with the new quick filters this allows to simply
> >   display a subset of the really good images
> >   (e.g. if you want to show it to someone else who only
> >   has time to see the best 10% ;-)
> > - tagging of images:
> >   once all images are tagged properly (well, this takes a bit of time ;-)
> >   this allows for finding images with specific characteristics
> > - adding comments
> >
> > All these can be searched for very quickly and efficiently.
> > As digikam can be configured to write this information
> > into the image metadata, these could be accessed from other applications
> > as well.
>
> I like all of those features. Even if I personally don't have a use for
> them, I am sure they are useful to other people.
>
> What I am extremely allergic to are applications that write into the
> images.
>
> The paradigm should be:
> 1. don't touch the originals.
> 2. in case of doubt, all images are to be considered originals.
>
> I love XMP sidecars and application databases to contain these and more
> metadata - the more the merrier - just stay away from my files. I
> understand the good intentions, but mistakes happen. I don't need to
> recall the damage done by Microsoft's Vista to Nikon RAW files.
>
> One thing that I noticed about digiKam: I tried to delete an album and a
> scary dialog came up: "These albums will be moved to the Trash Bin". And
> a checkbox saying "Delete files instead of moving them to the trash".
>
> Album = Folder? is this going to delete the folder from my file system?
>
> or
>
> Album = abstract entity, collection of pictures as represented inside
> digiKam?
>
> I got my answer, and I did not like it: Album = Folder.
>
> Which means that when I first created an album, it duplicated the files
> from the first folder used for it. Then, when I added pictures from
> another folder to that album, it duplicated them too. When I tried to
> delete the album, the dialog did not inform me of its location. But when
> I tried to delete an individual picture, it did.
>
> Adobe Lightroom used to behave like that during beta testing. For
> release, they got the message. Now, removing the equivalent of an Album
> only removes it from the database (by default), leaving the files and
> XMP sidecar untouched. I can elect to have the files deleted as well,
> but it is an option, not the default. I can copy files into Lightroom's
> own folders, but I can also have it leave them where they are and only
> add them to the database.
>
> Is this possible with digiKam as well? I have not found out yet how.
>
> I wish the delete dialog would be less threatening to me. I wish it
> would clearly tell me whether I am deleting an abstract entity or an
> actual folder/file.
>
> > Well, there is of course much more, like support for geo-tagging,
> > or the brilliant light-table to compare images side-by-side ...
>
> yes, the light-table is brillant. I have a few ideas, but maybe others
> had them already. How about a "diff mode", where the two images are
> super-imposed?
>
> > ((enough advertisement I hope .. ;-))
>
> never enough advertisement, as long as it is not overbloated
> marketing-speak. Your "advertisement" is very informative to me. Keep it
> coming.
>
> > Gerry already explained it, see also
> > http://www.digikam.org/?q=node/219
> >
> > This problem will be solved with digikam 0.10 which uses KDE4,
> > and is under heavy development, see
> >   http://www.digikam.org/?q=about/releaseplan
>
> I understand. Given that support for network drives is a killer
> criterium for me, and that 0.10 is planned for the summer, I will not
> adopt digiKam right away. But I will have time to test it thoroughly,
> and maybe give more feedback?
>
> > For this situations there are two solutions proposed in the links given
> > in http://www.digikam.org/?q=node/219
> > (I haven't tried them myself ...)
>
> simlyinking the sqlite database file looks good to me, but IMHO album =
> folder is bad. How about having inside the sqlite table a construct
> building the album independently of the folder? where can I see the
> table definitions?
>
> > kfmclient is part of konqueror.
> > (Can be figured out via:
> >     apt-file search kfmclient
>
> sudo apt-get install apt-file
> sudo apt-file update
> the search returned nothing
>
> probably my mistake as a newbie.
>
> >   aptitude install konquerora
> > should cure the problem.
>
> it might cure a problem, but it contributes to a much larger problem:
> clutter on my desktop. There are already too many applications. I try to
> keep it as simple as possible. I have one web browser and I don't see
> why I should install konqueror.
>
> > but I don't know kubuntu well enough ....
>
> neither do I. I use the default Ubuntu desktop. I am a dummy user. Like
> 90% of all users, I use default settings. I am looking for an
> application to browse pictures, not to replace my desktop and my web
> browser and my workflow. I expect the applications that I add to my
> toolbox to behave and integrate nicely with other applications. If it is
> possible for Windows applications to interoperate with non-Microsoft web
> browsers and mail clients, why would KDE applications impose me the use
> of Konqueror?
>
> I took the plunge into the cold water. After installing Konqueror and
> going again to the help button, Konqueror is triggered, with a URL
> help:/digikam/index.html and all I see on the screen is that "There is
> no documentation available for "/digikam/index.html"
>
> I'm willing to donate some time and help improve such situations. What
> would you suggest I do next?
>
> Yuv
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users

-- 
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20080129/3d998ce2/attachment.sig>