[Digikam-users] database troubles

[Jean-François Rabasse]

On Tue, 29 Jan 2013, Volker Henn wrote:

> Dear Jean-François
> I see that you agree to all these database troubles. But since DK sometimes
> destroys the pictures when rotating or changing the exif-rotation flag, I do
> nut trust DK in writing these information directly to the image.
> Also it is not clear to me if  'synchronize' is from database to picture or
> vice versa.

Hello Volker,

Well, you're probably right.

My opinion is that when using software that handle data, the « risk zero »
doesn't exist. Some people have already had text documents distroyed or
corrupted when using word processing programs.
(I've once lost an image in a stupid way. I was editing with GIMP, during
a storm, and had an electrical power failure in all my home. After power 
back, reboot the computer, run fsck, and the image was lost.)

All software have their strenghts and weaknesses and the important thing
isn't to expect a software « zero defects, bug free, etc. », but to know
its weaknesses.

I like using Digikam (I would probably not be on that mail list if not:-)
but I'm aware of some problems and just try to pass through.

As for images integrity, I try to always be in the situation where
a destroyed image is never catastrophic. And this can be achieved with
simple workflow :
- Remove a SD card from the camera (and put an empty one to have camera
   ready for next trip).
- Create a folder (subdirectory) with SD card content.
- If I have no time to start processing, I do a copy on an USB drive.
- Start work, edit images, edit metadata, etc.
- It's easy to verify, outside Digikam, that images files are correct,
   via a viewer like Gwenview (reads image data and metadata).
   When all is correct, and before turning off my computer, I do a copy
   again of edited images on USB drive, just in case.
etc.

If an accident destroys an image, I may have lost 1/2 hour work, but
the image is still somewhere (USB drive copy or original SD card).

That's why I accept the risk because consequences are low. And the 
advantages are what I listed in my previous e-mail, items 1 to 5.
Anyway, I never let a software, Digikam or GIMP or other, handle an
image file if I haven't at least one copy somewhere.
This is a simple numeric philosophy : if I go for an afternoon photo
trip, come back home with, say, 50 images. Probably I will really like
10 of them. But my afternoon (4 or 5 hours) is worth spending 25 seconds
to do a backup copy on my local drive and an USB drive :-)
And after that I can start Digikam, Gimp, other...
Time is precious, images are precious, USB storage is cheap and fast
and it's little to pay for security and anti accidents insurance.


About synchronization :

> Also it is not clear to me if  'synchronize' is from database to
> picture or vice versa.

Well, it's not always clear. Ideally it should be both ways. From my own
experience, synchronization from DB to image (i.e. « Write metadata to
file ») makes the image infos reflect the database current state for that
image.
The reverse isn't true. « Reread metadata from image » updates the DB
info correctly with scalar data, e.g. image title or caption/description.
But not with tagslists. Tags read from image are added to current tagslist
(in the DB) for that image.
To reflect a correct state, all tags should be removed in DK, prior to 
metadata reloading. I remember this issue has been discussed some months
ago in a thread « reorganizing tags » or something like that.

Regards,
Jean-François