New User: is digiKam right for me? and if not, what alternative?

[Yuval Levy-7]

Hi all,

I've just installed digiKam on ubuntu 7.10 for a test drive.
  $ sudo apt-get install digikam

I am PC-proficient, though my experience with Linux is limited. I run a
few FreeBSD servers, and on the desktop I am still mostly using Windows,
although I have been dual booting with ubuntu for about a year, I can
find my way around, and I intend to switch away from Windows one day.

Photography-wise, I have an archive of approximately 600GB. I shoot
almost exclusively RAW. The files are well sorted. All I need is an
application to quickly browse through my existing folders, display the
RAWs efficiently, and pass them to another application for conversion /
editing / whatever.

First thing that digiKam asks me on startup is an Album Library Folder
which from reading the documentation on the website I understand is the
folder where the images are stored. In BOLD the window asking for the
folder says "do not use a mount path hosted by a remote computer".

Why?

I store my images on a RAID on a file server. My internal network is
Giga-Ethernet. I open the files directly there, online, from
Photoshop/Windows, with no noticeable speed penalty. I don't want to
store images locally since I use many computers to access them and I do
not want to invest in each client the same amount of redundancy and
backup that I have in the server.

If this is not an option with digiKam, what other RAW-browsing tool
would you recommend?

Furthermore, I noticed a few details on startup.

When I click on the "help" button it says "could not launch KDE Help
Center". How do I install help? and why does help not install with the
package itself?

I accept the default path for the Album Library Folder just to check out
the application and digiKam starts with a beautiful page. It seems to be
  a page with hyperlinks (underline blue) and I have a web browser
(Firefox) installed. Instead it gives me an error message saying "Could
not launch the browser: Could not find service kfmclient". Why?

Thanks in advance for your help
Yuv
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Yan Seiner]

Yuval Levy wrote:

> Hi all,
>
> I've just installed digiKam on ubuntu 7.10 for a test drive.
>   $ sudo apt-get install digikam
>
> I am PC-proficient, though my experience with Linux is limited. I run a
> few FreeBSD servers, and on the desktop I am still mostly using Windows,
> although I have been dual booting with ubuntu for about a year, I can
> find my way around, and I intend to switch away from Windows one day.
>
> Photography-wise, I have an archive of approximately 600GB. I shoot
> almost exclusively RAW. The files are well sorted. All I need is an
> application to quickly browse through my existing folders, display the
> RAWs efficiently, and pass them to another application for conversion /
> editing / whatever.
>  

It sounds like you want something like gthumb - which is what I use for
browsing images.  I don't know if gthumb supports RAW - I use
high-quality jpeg mostly because I don't have to worry about conversion
outside the camera.

digikam is for downloading cameras + more.


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

[Gerry Patterson]

On Jan 19, 2008 8:35 PM, Yuval Levy <[hidden email]> wrote:

Hi all,

I've just installed digiKam on ubuntu 7.10 for a test drive.
 $ sudo apt-get install digikam

I am PC-proficient, though my experience with Linux is limited. I run a
few FreeBSD servers, and on the desktop I am still mostly using Windows,
although I have been dual booting with ubuntu for about a year, I can
find my way around, and I intend to switch away from Windows one day.

Photography-wise, I have an archive of approximately 600GB. I shoot
almost exclusively RAW. The files are well sorted. All I need is an
application to quickly browse through my existing folders, display the
RAWs efficiently, and pass them to another application for conversion /
editing / whatever.

First thing that digiKam asks me on startup is an Album Library Folder
which from reading the documentation on the website I understand is the
folder where the images are stored. In BOLD the window asking for the
folder says "do not use a mount path hosted by a remote computer".

Why?

I store my images on a RAID on a file server. My internal network is
Giga-Ethernet. I open the files directly there, online, from
Photoshop/Windows, with no noticeable speed penalty. I don't want to
store images locally since I use many computers to access them and I do
not want to invest in each client the same amount of redundancy and
backup that I have in the server.

If this is not an option with digiKam, what other RAW-browsing tool
would you recommend?

Furthermore, I noticed a few details on startup.

When I click on the "help" button it says "could not launch KDE Help
Center". How do I install help? and why does help not install with the
package itself?

I accept the default path for the Album Library Folder just to check out
the application and digiKam starts with a beautiful page. It seems to be
 a page with hyperlinks (underline blue) and I have a web browser
(Firefox) installed. Instead it gives me an error message saying "Could
not launch the browser: Could not find service kfmclient". Why?

Thanks in advance for your help
Yuv
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi Yuv,

We meet again. :-)

The original reason as to why it isn't recommended to use a remote file server for pictures with digikam was a limitation of the sqlite database backend of digikam. Something to do with the locking inadequacies of NFS.  There were some work arounds but I am not sure if they have been completely resolved yet.  Someone else on this list would be better able to answer this question.  There are some excellent people and some very good developers are working on digikam.

As for the problems you have starting up, are you using kubuntu or ubuntu?  Or perhaps a better question would be: are you using the K Desktop Environment?  If not you, may not have all of the dependencies installed.  I would think the packager would have resolved this, but perhaps not.  You could try to apt-get install 'kubuntu-desktop' and startup in KDE just to see if you have the same problems.

Over half a terabyte of RAW images?!  Wow.

Best Regards,

- Gerry

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

[Arnd Baecker]

[[This is my 10th attempt to reply to this mail, but all my
previous tries were considered as spam. So this time I will
split it into two parts]]

Hi Yuv,

great to see you here - hope we can convince you to stay ;-)

On Sat, 19 Jan 2008, Yuval Levy wrote:

> Hi all,
>
> I've just installed digiKam on ubuntu 7.10 for a test drive.
>   $ sudo apt-get install digikam
>
> I am PC-proficient, though my experience with Linux is limited. I run a
> few FreeBSD servers, and on the desktop I am still mostly using Windows,
> although I have been dual booting with ubuntu for about a year, I can
> find my way around, and I intend to switch away from Windows one day.
>
> Photography-wise, I have an archive of approximately 600GB. I shoot
> almost exclusively RAW. The files are well sorted. All I need is an
> application to quickly browse through my existing folders, display the
> RAWs efficiently, and pass them to another application for conversion /
> editing / whatever.

[reply in 1.) in the next mail ]

> First thing that digiKam asks me on startup is an Album Library Folder
> which from reading the documentation on the website I understand is the
> folder where the images are stored. In BOLD the window asking for the
> folder says "do not use a mount path hosted by a remote computer".
>
> Why?

[reply in 2.) in the next mail ]

> I store my images on a RAID on a file server. My internal network is
> Giga-Ethernet. I open the files directly there, online, from
> Photoshop/Windows, with no noticeable speed penalty. I don't want to
> store images locally since I use many computers to access them and I do
> not want to invest in each client the same amount of redundancy and
> backup that I have in the server.

[reply in 3.) in the next mail ]

> If this is not an option with digiKam, what other RAW-browsing tool
> would you recommend?
>
> Furthermore, I noticed a few details on startup.
>
> When I click on the "help" button it says "could not launch KDE Help
> Center". How do I install help? and why does help not install with the
> package itself?
>
> I accept the default path for the Album Library Folder just to check out
> the application and digiKam starts with a beautiful page. It seems to be
>   a page with hyperlinks (underline blue) and I have a web browser
> (Firefox) installed. Instead it gives me an error message saying "Could
> not launch the browser: Could not find service kfmclient". Why?

[reply in 4.) in the next mail ]

Sorry for this unusual reply, surely not a practice
to be followed if not necessary .... ;-),

Best, Arnd

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

[Arnd Baecker]

[[ and now the real reply ;-) ]]

1.)
===

For just viewing you could consider using showfoto,
which is part of the digikam package.
Another programm which is well suited for a fast display of
images is gqview.

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.

Well, there is of course much more, like support for geo-tagging,
or the brilliant light-table to compare images side-by-side ...

((enough advertisement I hope .. ;-))

2.)
===

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

3.)
===

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 ...)

4.)
===

kfmclient is part of konqueror.
(Can be figured out via:
    apt-file search kfmclient
if you installed the apt-file package and the corresponding
data-base  is up-to-date; this can be achieved with `apt-file update`)

So
  aptitude install konqueror
should cure the problem.

On debian etch:
  aptitude show digikam
gives
  Recommends: digikamimageplugins, kipi-plugins, kdeprint, konqueror
  Suggests: digikam-doc
Depending on the package-manager konqueror should be installed
as well; it might be that this is not done automatically,
but I don't know kubuntu well enough ....

You also might want to check whether digikamimageplugins, kipi-plugins,
kdeprint and digikam-doc are installed
(E.g. via:    dpkg -l | grep  kipi-plugins     etc.)

Hope this helps a bit, best,

Arnd

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

[Yuval Levy-7]

Hi Arnd,

Arnd Baecker wrote:
> Hi Yuv,
>
> great to see you here - hope we can convince you to stay ;-)

great to see you and Gerry over here :-) I am sure it is a nice place
hang around. my observation follow in the next mail ...

> Sorry for this unusual reply, surely not a practice
> to be followed if not necessary .... ;-),

... hoping not to trigger the spam filter again :-)

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

[Yuval Levy-7]

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?

> 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
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Gilles Caulier-4]

2008/1/28, Yuval Levy <[hidden email]>:

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?

Because decode in 8 bits color depth or in 16 bits color depth a RAW files is not the same

gqview do not support 16 bits color depth and i suspect than it use an half decoding version of RAW file to speed up loading. This is fine for viewing, and only viewing, but not to edit.
 

digiKam use also this wait to display faster RAW picture on Light Table.

Gilles Caulier

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

[Gilles Caulier-4]

2008/1/28, Yuval Levy <[hidden email]>:

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?


> 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.

??? Why ???
 

How about having inside the sqlite table a construct
building the album independently of the folder? where can I see the
table definitions?

http://www.digikam.org/?q=docs
 

> 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"

documentation is a huge separate package to Install...

If you prefert read it from the web :

http://docs.kde.org/kde3/en/extragear-graphics/digikam/index.html

Gilles Caulier

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

[Gerhard Kulzer-3]

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
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users

--
><((((º> ¸.·´¯`·... ><((((º> ¸.·´¯`·...¸ ><((((º>
http://www.gerhard.fr

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

[Yuval Levy-7]

Gerhard Kulzer wrote:

>> 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.

have I hurt some feelings here?

with all due respect, I have not compared the quality. I have not
compared bit depth nor accuracy. I did not check if it removes chromatic
aberration, nor if it applies a noise filter.

Because at this stage, *speed* is the factor that counts, at a thumbnail
quality, displayed on an 8bit LCD. A better than needed quality for a
longer processing time is not an improvement to me.

All the other qualities become important at a later stage, when
*developing* an image from a RAW file.

Today I got back with 2x 2GB Flash cards full of RAWs. I will end up
using maybe 10% of that, and for that 10% I will want all the accuracy
you are asking me to compare. But while just browsing the catalog I
don't need that.

There are two type of process: interactive and automated. The most
important factor for interactive processes is *time*, because human time
is limited and expensive.

Probably Canon's DPP, Adobe's Lightroom, Apple's Aperture and other
professional tools use two different algorythms, one for the thumbnails
and for browsing; the other for exporting images from the RAW files. I
don't really care how they do it - the browsing is faster and this is
what counts to me.

human time is expensive. A tool that makes me wait for a higher quality
conversion than what I need is *worse* IMO than a tool that adapts its
quality to my needs and saves my time.

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

[Yuval Levy-7]

Gilles Caulier wrote:
>     simlyinking the sqlite database file looks good to me, but IMHO album =
>     folder is bad.
>
>
>
> ??? Why ???

because it is an artificial limitation to a single mode of working,
while human beings work in different modes.

I've seen photographers who simply arrive to the office and dump their
flash card onto one single folder. So their folder structure is
something like:
pictures/DCIM/390CANON/
pictures/DCIM/391CANON/
pictures/DCIM/392CANON/
...

they don't bother to do anything else.

Then there are those like me who store their pictures in one folder per
shooting, sorted by date and with names that have some indication as to
the location or subject:
pictures/071124montreal
pictures/071125pontjacquescartier
pictures/071125pressconference


I happen to do work for a client over multiple days, and sometimes even
multiple locations, which results in multiple folders. In Adobe
Lightroom I just add all of those different folders to one album, and so
I can have an album per client, while still keeping my principal
structure above.

I retain copyright to most of my shooting, so the client perspective
(the albums) is only important until the work for the client finished.
but the chronological perspective is more important to me, for later. it
gives me a sense of how I spent the last months and years.

such a long text to just give one answer: FLEXIBILITY.

thanks for the links to the DBschemas. I'll have a look at them, and if
you're interested I will comment.

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

[Arnd Baecker]

Hi Yuv,

you raised quite a few points (not unlikely that some will
fall through  the cracks... ;-), but let me try to answer part of them:

On Mon, 28 Jan 2008, Yuval Levy wrote:

> Arnd Baecker wrote:

[...]

> > 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.

The important sentence in my mail was
"""As digikam *can* be configured to write this information
into the image metadata, """ (emphasis added ;-).
So the point is: this is configurable.

In addition this is also a question of the workflow:
for example, I copy all my images via card-reader
to one hard-disk and leave that completely untouched
(Apart from deleting the bad images immediately)
From there another copy is done to the tree in which
is under the "control" of digikam. These images
then get changed, e.g. by adding GPS info etc.
So by this it is ensured, that there is always an untouched copy,
straight from the camera (ignoring data-integrity problems
for the moment ;-).

> 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.

OK, that makes sense to me. Could you file a wish
in the bug-tracker (See "Reporting bugs and wishes" at
http://www.digikam.org/?q=contrib) to report the location
of the album when it is to be deleted ?

> 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.

Currently this is not possible.
For digikam >=0.10 (which uses Qt4/KDE4) multiple
root albums will be realised.

There are quite a few changes in the database for >=0.10, see e.g.
http://www.digikam.org/?q=node/257
http://www.digikam.org/?q=node/256
and in the wiki
http://wiki.kde.org/tiki-index.php?page=digikam
under
http://wiki.kde.org/tiki-index.php?page=Digikam+development+discussion

For digikam >=0.10 the database schema are described in
http://websvn.kde.org/trunk/extragear/graphics/digikam/DBSCHEMA.ODS?view=log
and a similar document exists for 0.9.x:

> 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.

(see above ;-)

> > 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?

Personally I don't think I would use that much - but
there are many features I don't use ;-).
Sounds like another wish for the bug-tracker...

[...]

> > 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?

Constructive feedback is always welcome!
What is important: in order to ensure that good
ideas are not forgotten, they need to be put into
the bug-tracker. This ensures that other people can vote
for the wish, that their comments are preserved, that
patches can be added and duplicates can be added.
(Browsing through the 400+ bugs/wishes for digikam
is interesting on its own ;-).

It also has the advantage (at least in an ideal world),
that only one issue is discussed at a time,
in contrast to e-mail discussions, which tend
to have (too) many different aspects in one thread ... ;-)

[...]

Best, Arnd

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

[Arnd Baecker]

On Tue, 29 Jan 2008, Yuval Levy wrote:

> Gilles Caulier wrote:
> >     simlyinking the sqlite database file looks good to me, but IMHO album =
> >     folder is bad.
> >
> > ??? Why ???
>
> because it is an artificial limitation to a single mode of working,
> while human beings work in different modes.
>
> I've seen photographers who simply arrive to the office and dump their
> flash card onto one single folder. So their folder structure is
> something like:
> pictures/DCIM/390CANON/
> pictures/DCIM/391CANON/
> pictures/DCIM/392CANON/
> ...
>
> they don't bother to do anything else.
>
> Then there are those like me who store their pictures in one folder per
> shooting, sorted by date and with names that have some indication as to
> the location or subject:
> pictures/071124montreal
> pictures/071125pontjacquescartier
> pictures/071125pressconference
>
> I happen to do work for a client over multiple days, and sometimes even
> multiple locations, which results in multiple folders. In Adobe
> Lightroom I just add all of those different folders to one album, and so
> I can have an album per client, while still keeping my principal
> structure above.

And for digikam you would just assign tags "Client1", "Client2"
to the corresponding images and using the tags virtual folder
view just get what you want.

So digikam allows to keep your principal structure,
and with tags you can get any view you want.

Best, Arnd


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

[Arnd Baecker]

and now to the speed issue:

On Tue, 29 Jan 2008, Yuval Levy wrote:

> Gerhard Kulzer wrote:
> >> 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.

Acutually, I just checked and the image dimension
you get are (slightly) different for gqview compared to showfoto,
because showfoto uses the "real" RAW and not the embedded image.

[...]

> Probably Canon's DPP, Adobe's Lightroom, Apple's Aperture and other
> professional tools use two different algorythms, one for the thumbnails
> and for browsing; the other for exporting images from the RAW files. I
> don't really care how they do it - the browsing is faster and this is
> what counts to me.
>
> human time is expensive. A tool that makes me wait for a higher quality
> conversion than what I need is *worse* IMO than a tool that adapts its
> quality to my needs and saves my time.

I think that what you would like to have is implemented in digikam
but not (yet) in showfoto:

Under "Configure/Albums - Interface Options"
you have: "Thumbnail click action: - Show embedded preview"
and below [x] Embedded preview load full image size.
If you de-activate the last one, displaying RAWs
is much faster.

Also note that there is one open bug about preloading raw images
  http://bugs.kde.org/show_bug.cgi?id=132047
  "Faster display of images and/or prefetch wished for"
And a related one:
  http://bugs.kde.org/show_bug.cgi?id=146260
  "first load reduced image and then full image"

So when you look through the comments for these two wishes,
there has been quite a bit of discussion and code concerning
the speed of display ... ;-)

Best, Arnd

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