[Digikam-users] Migration problems - Digikam 1.8 to 2.0

Jean-Fran├žois Rabasse jean-francois.rabasse at wanadoo.fr
Tue Sep 13 01:08:00 BST 2011


On Mon, 12 Sep 2011, David Vincent-Jones wrote:

> There is however a school of thought that maintain that writing
> data directly into an image file can be a source of corruption and
> that such an approach to the raw image file is totally
> unacceptable.

Hum, is that a reason ? I think it's a general problem with any
computer data and data handling software. From the moment one uses a
software to handle data, there's always the risk the software be
buggy and corrupt your data. That's sure.

And the potential risk is there, whatever the data is, digital
photo, text document, sound file, etc. The choice is either to do
nothing with data, or to take a risk. I think raw files formats are
useless if you don't produce, at one time or the other, another more
useable file.

What about a buggy raw converter, dcraw, ufraw, other, that produces
corrupted jpeg ? Ok, you keep the raw file intact, but what else if
you can't produce a jpeg ?

My opinion is that the major risk of data corruption is data loss
due to hard drives failures. This happens quite more often than by
software corruption. (There's an excellent chapter in the digiKam
handbook, "Digital Asset Management with digiKam", that states than
hardware problems and human errors are far more often than software
problems in data loss or corruption, in the section "What are then
the main factors od digital data loss".)

And the only safe workaround is backup, backup, backup...
Having a file in some "read-only" mode on a disk is *not* a
security. The only security is a backuped file.

I don't agree with the mentionned school of thought because I think
it's a wrong answer to a good question. The good question is "how
can I assert my precious pictures will stay alive for a long time ?"
And the wrong (IMHO) answer is "well, don't touch them".

I prefer an answer such as "well, backup them and store in a safe
place, then copy all on your drives and work with good software".
Of course, you won't have risk zero, but you have your backups.

And having a backup of raw files, as from the camera, plus a backup
of hard drive directories with tagged images files doesn't appear to
be a problem. Where would be the problem ? The cost of CD/DVD
supports ? Tsss, how did you paid for your digital camera, lenses et
al., to make your precious pictures...

As for me, I don't care of data corruption on a raw file if I know
my raw files, as from my SD cards, are burnt on CD/DVD. And even
without writing data to my raw files, I'd do backups anyway because
I reasonably trust the software I use, but I don't trust my hard
drives. I *know* they will fail up in the next 3 or 4 years and I
want my photos to last more than a few years. So...

And, by the way, the very first metadata writer in raw images files
is the camera manufacturer:-) Some camera firmware have happened to
produce erroneous EXIF encoding. Should camera makers software be
more trustable than digital photos management software ? Perhaps,
but not sure; both are made by humans, and humans are never perfect.

I fully agree with Martin when he says :

> On Mon, 2011-09-12 at 23:27 +0200, Martin Burnicki wrote:

> > I think one of the best advantages of digital photos is that you
> > can store data inside the image file, i.e. camera and lens
> > information, but also comments, copyright, geo tags, etc.

Sure. And I'll go a little further, if files formats provide
standards to embed metadata, EXIF, IPTC, XMP et al., it's to be used
and it's useful.

And keep CD/DVD backups of the original files, and work on copies on
your hard drives, with metadata embedded. And you discover your
software corrupts all your files because there's a severe bug in the
"write metadata" routines, throw away the software and restore from
Personal or professional photos are worth a few CD/DVD supports,
or even small USB drives used for archiving purposes.

(And even CD/DVD supports are not eternal and should be rewritten
every 3 or 4 years on fresh new supports. And USB drives should be
replicated and stored in two different places, one at home and a copy
at office, just in case you get fire at home. Etc.)

Personal or professional data are precious, backup solutions are
cheap. The only reason to refuse to write something into a raw file
would be to refuse also to have a backup of the original raw file.
Sounds dangerous...

Martin said also :

> > This is also a good thing if you should sometimes decide to use
> > a different photo management software than DK. OK, OK, this will
> > never happen as long as DK is such an excellent program ; -))

Right:-) But... One can also decide to use digiKam instead of
another photo management software, and expect to get back images

I did that, six months ago, importing into digiKam about 5000 photos
with metadata. It's not straightforward because metadata standards
describe very well fields formats and structure, but don't describe
with the same accuracy what should be stored and where. And each
software does different things.

E.g. I had my images titles into the XMP Dublin Core title field,
and a free text image description in the XMP DC description field.
But digiKam uses the xmp.dc.description as caption for the images,
and I had to move my titles from xmp.dc.title to xmp.dc.description,
and save my descriptions into the unused field xmp.dc.coverage,
juste because I don't want to loose it.

So, having metadata in images files is a great thing, you keep
information along with the image. But moving from software to
software will probably always require a bit of work to extract data
from some fields and rewrite into others. And it's the kind of work
small shell scripts can do, using some command line metadata editors
(exiftool, exiv2,... )

Even having to build such shell scripts takes far less time than
reindexing, retagging hundreds or thousands of images by hand.


More information about the Digikam-users mailing list