map view seems to use odd EXIF tags

[Martin Gerner]

Hi all,

I've noticed some odd behaviour with regard to how images are displayed
in the map views, and I was hoping that somebody here could either
clarify whether I've misunderstood something, or confirm whether there's
a problem in Digikam.

I used a piece of software to synchronize .gpx files with .jpg photos,
with the effect of setting a number of GPS exif tags such as
GPSLatitude, GPSLongitude, etc (GPSversionID is 2.3.0.0). My
understanding is that geolocation tags can also be saved to "XMP Exif"
tags - these tags were empty after synchronization.

When I select these images in Digikam and hit Image -> Geolocation, I
can see that the latitude, longitude and altitude were read correctly
from the images, and they show up properly in the map. Great - it looks
like the synchronization worked.

However, if I close the geolocation window and instead click the "map"
toolbar button, the photos are not shown in the map. Likewise, if I open
the 'map search' side tab in the left side of the window, the photos
don't show up there either, and if I add a geolocation filter to only
include images with geolocation data, again they don't show up.

It seems odd to me that the functions that read geocoded data in the
'geolocation' window would read information from different sources to
the other windows. Also, other tools (e.g. Picasa and the
synchronization tool I used) seem to handle the location fields fine
(Picasa shows them as being properly geocoded).

If I change the location of the photos in the geolocation window and
apply the changes (from within Digikam), I can see that the XMP EXIF
geolocation fields are updated for the photos; after this, they show up
fine in the rest of the map views in Digikam.

My suspicion at the moment is that the geolocation window reads location
data from the 'plain' EXIF fields (and probably the XMP ones too), that
inconsistently the rest of the map views only read the XMP fields, and
that the reading of only the XMP fields is incorrect as it doesn't seem
to match what other similar software does. It's a pain, since it means
that Digikam doesn't operate well together with other software.

I'm not an expert on this though, so I could be wrong. Does anybody
know? I'd be happy to send an example image file to directly to anybody
who would like to reproduce this.

Thanks,
Martin


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

[Michael G. Hansen]

Hi Martin,

since you used external software to update the EXIF data, it may be that
the database of digikam was not updated yet. You can select your newly
tagged photos and do Image->"Reread metadata from images".

If that does not work, please open a bug report and post a sample image.

Best regards,

Michael

On 12/31/2013 02:39 PM, Martin Gerner wrote:

> Hi all,
>
> I've noticed some odd behaviour with regard to how images are displayed
> in the map views, and I was hoping that somebody here could either
> clarify whether I've misunderstood something, or confirm whether there's
> a problem in Digikam.
>
> I used a piece of software to synchronize .gpx files with .jpg photos,
> with the effect of setting a number of GPS exif tags such as
> GPSLatitude, GPSLongitude, etc (GPSversionID is 2.3.0.0). My
> understanding is that geolocation tags can also be saved to "XMP Exif"
> tags - these tags were empty after synchronization.
>
> When I select these images in Digikam and hit Image -> Geolocation, I
> can see that the latitude, longitude and altitude were read correctly
> from the images, and they show up properly in the map. Great - it looks
> like the synchronization worked.
>
> However, if I close the geolocation window and instead click the "map"
> toolbar button, the photos are not shown in the map. Likewise, if I open
> the 'map search' side tab in the left side of the window, the photos
> don't show up there either, and if I add a geolocation filter to only
> include images with geolocation data, again they don't show up.
>
> It seems odd to me that the functions that read geocoded data in the
> 'geolocation' window would read information from different sources to
> the other windows. Also, other tools (e.g. Picasa and the
> synchronization tool I used) seem to handle the location fields fine
> (Picasa shows them as being properly geocoded).
>
> If I change the location of the photos in the geolocation window and
> apply the changes (from within Digikam), I can see that the XMP EXIF
> geolocation fields are updated for the photos; after this, they show up
> fine in the rest of the map views in Digikam.
>
> My suspicion at the moment is that the geolocation window reads location
> data from the 'plain' EXIF fields (and probably the XMP ones too), that
> inconsistently the rest of the map views only read the XMP fields, and
> that the reading of only the XMP fields is incorrect as it doesn't seem
> to match what other similar software does. It's a pain, since it means
> that Digikam doesn't operate well together with other software.
>
> I'm not an expert on this though, so I could be wrong. Does anybody
> know? I'd be happy to send an example image file to directly to anybody
> who would like to reproduce this.
>
> Thanks,
> Martin
>
>
>
> _______________________________________________
> 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

[Jean-François Rabasse-2]

Hi Martin,

Some comments, as I geotag images files from GPX tracks logs too,
using an external program.

On Tue, 31 Dec 2013, Martin Gerner wrote:

> I used a piece of software to synchronize .gpx files with .jpg photos,
> with the effect of setting a number of GPS exif tags such as GPSLatitude,
> GPSLongitude, etc (GPSversionID is 2.3.0.0). My understanding is that
> geolocation tags can also be saved to "XMP Exif" tags - these tags were
> empty after synchronization.

Yes, Exif properties « can be saved » into proper XMP Exif schema, but this
isn't a law. It's up to the writing software to choose to update data in
the Exif section, or the XMP section, or both.
If your GPS correlation software updates only the Exif section, your
XMP data remain empty, or worse, can contain values from a previous GPS
correlation done with a different software.

Digikam keeps images GPS position in its database. These values will be
read when scanning for new images and reading their metadata, and will be
updated when you edit positions, inside Digikam.

> My suspicion at the moment is that the geolocation window reads location
> data from the 'plain' EXIF fields (and probably the XMP ones too), that
> inconsistently the rest of the map views only read the XMP fields, and
> that the reading of only the XMP fields is incorrect as it doesn't seem
> to match what other similar software does. It's a pain, since it means
> that Digikam doesn't operate well together with other software.

No, Digikam functions don't read position data from Exif, or XMP, but
from the Digikam database. So they use what has been loaded when reading
images metadata.

But, when you write metadata to your images, or sidecar files, database
values are also exported into the Exif XMP schema.

And that's why, when you edit internally, database values are updated
then metadata is exported viw XMP schema :

> If I change the location of the photos in the geolocation window and apply
> the changes (from within Digikam), I can see that the XMP EXIF geolocation
> fields are updated for the photos; after this, they show up fine in the
> rest of the map views in Digikam.
(Show up fine because the database has been updated, not because the data
has been XMP exported.)


I agree with Michael saying :

On Tue, 31 Dec 2013, Michael G. Hansen wrote:

> since you used external software to update the EXIF data, it may be that
> the database of digikam was not updated yet. You can select your newly
> tagged photos and do Image->"Reread metadata from images".

You should check. If you first geocorrelate your images then start Digikam
and get the images as new images, metadata will be read.
But if you geocorrelate images already managed in Digikam, you have to
trigger « Reread metadata » so that Digikam updates its database.


As for compatibility with other software, my personal opinion is that
consistency must be guaranteed. GPS positions should be edited with one
and only one software, not different ones. This could ensure Exif GPS
data, or XMP GPS data be the same.

Most software will be able to read data in a fixed order, Exif data first
then XMP data. But I have no idea of what could they do, facing an
inconsistency. Could probably lead to weird results.

As for me, I never faced that kind of problem because I edit positions
with an external program and writes only XMP Exif GPS data. So, the
original Exif GPS data in my images are always empty.
And I use Digikam only to « see » positions, not to edit.
(Of course, rereading metadata is required when I update positions from
outside.)

Regards, and Happy New Year :)
Jean-François

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

[Martin Gerner]

Hello Jean-François and Michael -

Thank you for your replies - I have a better understanding of how Digikam operates now, and what you say makes sense. Re-reading the metadata of the images don't seem to change anything unfortunately, so it probably only considers the XMP section. I'll raise a bug for this.

Jean-François, I'm guessing that the software you use for correlating .gpx tracks with images does write to the XMP fields? What software is it?

Thanks,
Martin

On 31/12/13 16:52, Jean-François Rabasse wrote:

Hi Martin,

Some comments, as I geotag images files from GPX tracks logs too,
using an external program.

On Tue, 31 Dec 2013, Martin Gerner wrote:

I used a piece of software to synchronize .gpx files with .jpg photos,
with the effect of setting a number of GPS exif tags such as GPSLatitude, GPSLongitude, etc (GPSversionID is 2.3.0.0). My understanding is that geolocation tags can also be saved to "XMP Exif" tags - these tags were
empty after synchronization.

Yes, Exif properties « can be saved » into proper XMP Exif schema, but this
isn't a law. It's up to the writing software to choose to update data in
the Exif section, or the XMP section, or both.
If your GPS correlation software updates only the Exif section, your
XMP data remain empty, or worse, can contain values from a previous GPS
correlation done with a different software.

Digikam keeps images GPS position in its database. These values will be
read when scanning for new images and reading their metadata, and will be
updated when you edit positions, inside Digikam.

My suspicion at the moment is that the geolocation window reads location data from the 'plain' EXIF fields (and probably the XMP ones too), that
inconsistently the rest of the map views only read the XMP fields, and that the reading of only the XMP fields is incorrect as it doesn't seem
to match what other similar software does. It's a pain, since it means that Digikam doesn't operate well together with other software.

No, Digikam functions don't read position data from Exif, or XMP, but
from the Digikam database. So they use what has been loaded when reading
images metadata.

But, when you write metadata to your images, or sidecar files, database
values are also exported into the Exif XMP schema.

And that's why, when you edit internally, database values are updated
then metadata is exported viw XMP schema :

If I change the location of the photos in the geolocation window and apply
the changes (from within Digikam), I can see that the XMP EXIF geolocation
fields are updated for the photos; after this, they show up fine in the rest of the map views in Digikam.

(Show up fine because the database has been updated, not because the data
has been XMP exported.)


I agree with Michael saying :

On Tue, 31 Dec 2013, Michael G. Hansen wrote:

since you used external software to update the EXIF data, it may be that
the database of digikam was not updated yet. You can select your newly tagged photos and do Image->"Reread metadata from images".

You should check. If you first geocorrelate your images then start Digikam
and get the images as new images, metadata will be read.
But if you geocorrelate images already managed in Digikam, you have to
trigger « Reread metadata » so that Digikam updates its database.


As for compatibility with other software, my personal opinion is that
consistency must be guaranteed. GPS positions should be edited with one
and only one software, not different ones. This could ensure Exif GPS
data, or XMP GPS data be the same.

Most software will be able to read data in a fixed order, Exif data first
then XMP data. But I have no idea of what could they do, facing an inconsistency. Could probably lead to weird results.

As for me, I never faced that kind of problem because I edit positions
with an external program and writes only XMP Exif GPS data. So, the
original Exif GPS data in my images are always empty.
And I use Digikam only to « see » positions, not to edit.
(Of course, rereading metadata is required when I update positions from
outside.)

Regards, and Happy New Year :)
Jean-François

_______________________________________________
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

[Jean-François Rabasse-2]

Hello all and Happy New Year, full of attractive images ;)

On Tue, 31 Dec 2013, Martin Gerner wrote:

> Hello Jean-François and Michael -
>
> Thank you for your replies - I have a better understanding of how Digikam
> operates now, and what you say makes sense. Re-reading the metadata of the
> images don't seem to change anything unfortunately, so it probably only
> considers the XMP section. I'll raise a bug for this.
>
> Jean-François, I'm guessing that the software you use for correlating .gpx
> tracks with images does write to the XMP fields? What software is it?

Well, I currently use a test version of a correlating program I'm writing.
(The major reason is that I'm a bit unhappy with existing programs. My GPS
log device is a MobileAction GT120, a small, light weight, low cost, and
handy device, but small device means small antenna and not that great signal
to noise ratio, giving some spurious positions from time to time. When the
device aquires a position, at 5 seconds interval, and that new position is
200 meters from the previous one, either you are a olympic level runner,
or the point is stupid.
Usual correlators can filter and discard points based on a minimal number
of satellites, but no one I know can discard on a velocity criterion.
And that's what I plan to do...)

But apart from that I've also being using exiftool for a long time, and
still use it.

And you guess right, my GPS data is XMP data.
This, for philosophical reasons : many users - including me - consider that
Exif data is technical data written into the image file by a camera, and
should be considered as locked read-only data forever.
XMP schemas provide all the necessary editable informations and I personaly
don't know any usecase where original Exif data should be modified.
Of course, it's nothing but an opinion.

So, I usually create XMP sidecar files from my original images, e.g. :
   exiftool -tagsfromfile XXX.JPG XXX.JPG.xmp

then do GPS correlation directly on the XMP files :
   exiftool -geotag tracklog.gpx XXX.JPG.xmp
with possible -geosync adjustements.

or, in a whole folder :
   exiftool -geotag tracklog.gpx *.xmp

That way, I never modify my original image file and original Exif section.
All metadata edition, title, rating, tags, description, copyright, et al.
is done at XMP sidecar file level.

This is the way I work, but I think same processing can be achived with
Digikam, from the moment your metadata setup is « Write to sidecar files
only ». Digikam can also create XMP sidecar files (using the libexiv2,
a little less complete than files produced by exiftool).


Regards,
Jean-François

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

[Jean-François Rabasse-2]

Hello,

On Wed, 8 Jan 2014, Peter Albrecht wrote:

> Hi Jasper,
>
> I try to use the digiKam db only as a fast cache for image
> meta information.
> -> I configured digikam to store all important info (for me:
> Tags, Comments, Rating) in the JPG's metadata (EXIF/XMP).
>
> At my last migration from 32 Bit to 64 Bit, I started with a
> fresh digikam installation and copied only the jpg files to
> the new installation.
> Digikam db and thumbnail db were recreated well.
>
> I did not copy digikam settings, but went through all of
> them again. Once in a while, new interesting settings are
> added, which I wouldn't have found otherwise.
>
> This worked well for me. Maybe other people with other
> settings/conditions might have problems with this way.

I totaly agree with Peter.
This may seem a somewhat rough method, but it's safe and portable
for any environment changes, Digikam versions changes, etc., without
having to cope with - possibly - migration problems and - possibly -
metadata losses.

I work exactly the same way. The only - minor - drawback is that
rebuilding all from scratch may take a couple of minutes. Not really
a problem when the operation is done once a month or every two months.

And, as says Peter :
> I try to use the digiKam db only as a fast cache for image
> meta information.
Digikam database is an application specific, working data format.
It's fast for images filtering or collections searching, but should
not be considered as a reliable, long lifetime, metadata archiving
system.
And, as all can be rebuilt via « Read metadata from images », it's
not to be considered as critical information.

(Also, metadata into images files is the only way to share informations
with family, friends, and any people who are not Digikam users.)

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Daniel Bauer-2]

Am 09.01.2014 10:22, schrieb Jean-François Rabasse:

>
> Hello,
>
> On Wed, 8 Jan 2014, Peter Albrecht wrote:
>
>> Hi Jasper,
>>
>> I try to use the digiKam db only as a fast cache for image
>> meta information.
>> -> I configured digikam to store all important info (for me:
>> Tags, Comments, Rating) in the JPG's metadata (EXIF/XMP).
>>
>> At my last migration from 32 Bit to 64 Bit, I started with a
>> fresh digikam installation and copied only the jpg files to
>> the new installation.
>> Digikam db and thumbnail db were recreated well.
>>
>> I did not copy digikam settings, but went through all of
>> them again. Once in a while, new interesting settings are
>> added, which I wouldn't have found otherwise.
>>
>> This worked well for me. Maybe other people with other
>> settings/conditions might have problems with this way.
>
> I totaly agree with Peter.
> This may seem a somewhat rough method, but it's safe and portable
> for any environment changes, Digikam versions changes, etc., without
> having to cope with - possibly - migration problems and - possibly -
> metadata losses.
>
> I work exactly the same way. The only - minor - drawback is that
> rebuilding all from scratch may take a couple of minutes. Not really
> a problem when the operation is done once a month or every two months.
>
> And, as says Peter :
>> I try to use the digiKam db only as a fast cache for image
>> meta information.
> Digikam database is an application specific, working data format.
> It's fast for images filtering or collections searching, but should
> not be considered as a reliable, long lifetime, metadata archiving
> system.
> And, as all can be rebuilt via « Read metadata from images », it's
> not to be considered as critical information.
>
> (Also, metadata into images files is the only way to share informations
> with family, friends, and any people who are not Digikam users.)
>

Sorry, I disagree.

It is not always desirable that everybody can access tags, ratings etc.
(3 examples: models tagged with real name, but published with artist
name only; selection ratings, comments on customers images that are not
meant for their eyes; personal comments/reminders).

At least for me it is absolutely no option to save this information in
the image files, and the reliability of the database therefore is very
important for me...

Daniel

--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
google+: https://plus.google.com/109534388657020287386
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse-2]

Hi Daniel,

On Thu, 9 Jan 2014, Daniel Bauer wrote:

> Sorry, I disagree.
>
> It is not always desirable that everybody can access tags, ratings etc.
> (3 examples: models tagged with real name, but published with artist name
> only; selection ratings, comments on customers images that are not meant for
> their eyes; personal comments/reminders).

Sure, I totally agree with you, it's not - always - desirable.

But it's really easy to build, from archives images, images for public
release with metadata removed.
E.g. when I prepare a set of images for public web albums,
I usually script something like :
  convert original-image -strip image-for-public-release
and get images files without any sections, Exif, IPTC, XMP, only
raster data.

And when it is desirable, e.g. giving images of family events to family
members that don't use Digikam, standard readable metadata is here.


> At least for me it is absolutely no option to save this information in the
> image files, and the reliability of the database therefore is very important
> for me...

Hum, everyone's choice but, IMHO, you play with fire.
What means « reliability of the database » and across which time
interval ?

You shoot an image today, say early 2014, and document with tags,
comments, etc. Ok, fine.
Now what about using your work in twenty years from now ? Or, what is
the expected liftime of your work ? Can you assert today that you'll
still be using Digikam in 20 years ? And that your DK database will
still be valid in 2034, migration after migration, across versions
changes ?

This is the kind of bet I refuse to do, too dangerous.
I prefer to rely on the XMP standard, as images with embedded XMP will
still be useable in 20 years, whatever the DAM software I'll be
using at that time.
(Don't known what it will be, maybe it doesn't exist yet.)


Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 09/01/2014 15:45, Jean-François Rabasse a écrit :

> This is the kind of bet I refuse to do, too dangerous.

it is enough to move photo outside of digikam to lose the metadata from the
database...

a good alternative is to use sidecars, easy to keep with images and easy to
remove when necessary

jdd


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

[Jean-François Rabasse-2]

On Thu, 9 Jan 2014, jdd wrote:

> Le 09/01/2014 15:45, Jean-François Rabasse a écrit :
>
>> This is the kind of bet I refuse to do, too dangerous.
>
> it is enough to move photo outside of digikam to lose the metadata from the
> database...

Right :) Or to rename an edited image file between two Digikam sessions.
It's seen as a new image, and previous associated metadata vanish.

> a good alternative is to use sidecars, easy to keep with images and easy to
> remove when necessary

Yes. And it's a safe data backup. The only problem with sidecars is that
it's not fully interoperable between different applications. E.g. if you
have your metadata in Digikam DB and sidecar files, Gwenview won't show
anything. Applications like Picasa won't either, etc.

Anyway, restoring metadata into images from sidecar files is as easy
as removing metadata from images files, cf. supra.
So the idea remains the same, metadata in DB AND in XMP format, be it
a sidecar file and/or the image file itself.

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Daniel Bauer]

Hello Jean-François,

Am 09.01.2014 15:45, schrieb Jean-François Rabasse:

>
> Hi Daniel,
>
> On Thu, 9 Jan 2014, Daniel Bauer wrote:
>
>> Sorry, I disagree.
>>
>> It is not always desirable that everybody can access tags, ratings etc.
>> (3 examples: models tagged with real name, but published with artist
>> name only; selection ratings, comments on customers images that are
>> not meant for their eyes; personal comments/reminders).
>
> Sure, I totally agree with you, it's not - always - desirable.
>
> But it's really easy to build, from archives images, images for public
> release with metadata removed.
> E.g. when I prepare a set of images for public web albums,
> I usually script something like :
>   convert original-image -strip image-for-public-release
> and get images files without any sections, Exif, IPTC, XMP, only
> raster data.
>

That's more or less how I strip meta-data.

It is just too risky to have a version with and a version without
meta-data (for me): a quick wrong click and the wrong files are
published or sent with email... Or I forget to strip the tags. Or I
don't remember which version is which - even more versions and another
organization task, which I don't like (Id rather spend my time behind
the camera than in front of the computer screen, although in fact the
computer screen has alread won :-) )

So the files developped from the raws get stripped, and whatever I work
with in digikam/gimp is meta-data-less. If I need to, I add them later,
manually.

> And when it is desirable, e.g. giving images of family events to family
> members that don't use Digikam, standard readable metadata is here.
>

Of course. I don't deny the sense of using metadata in image files, for
sure they serve for many. Image banks for example need such meta tags
(but not the ones I use for my personal work flow). I mainly referred to
the phrase

"it's not to be considered as critical information."

and wanted to point out, that for /some/ it *is* critical information.

>> At least for me it is absolutely no option to save this information in
>> the image files, and the reliability of the database therefore is very
>> important for me...
>
> Hum, everyone's choice but, IMHO, you play with fire.
> What means « reliability of the database » and across which time
> interval ?
>
> You shoot an image today, say early 2014, and document with tags,
> comments, etc. Ok, fine.
> Now what about using your work in twenty years from now ? Or, what is
> the expected liftime of your work ? Can you assert today that you'll
> still be using Digikam in 20 years ? And that your DK database will
> still be valid in 2034, migration after migration, across versions
> changes ?

In my special case the lifetime of tags, comments etc. and of the work
itself are two different things.

Tags etc. are for me helper tools during the production and then thru
each selling process. Once finished this process I don't need this
information anymore.

But *during* the process (which might be some weeks or in some cases
two, three years) the data is important. Loss wouldn't be worlds end,
but would cause a lot of additional work, many more hours in front of
the screen...

The camera meta data are in the raw files which I never delete.

But as said: this is my personal, special case. It is just that the
proper function of the database for me is important. That's all.

But now problems are solved anyway: should I loose data, I'd just ask
the NSA or google who maybe already has reached the goal of entering
into my computer :-)

  >
> This is the kind of bet I refuse to do, too dangerous.
> I prefer to rely on the XMP standard, as images with embedded XMP will
> still be useable in 20 years, whatever the DAM software I'll be using at
> that time.
> (Don't known what it will be, maybe it doesn't exist yet.)

What makes you so sure that there will be a program capable to read XMP
or even digital images themselves in 20 years? (Only rethoric question)

Enjoy!

Daniel


--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
google+: https://plus.google.com/109534388657020287386
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Jean-François Rabasse-2]

Hello Daniel,

Seems the thread is slightly shifting from the original issue (how to
protect metadata during a system change), but it's interesting.

And thanks for your detailled « use case » and point of view.

The conclusion seems to be that data strategy is mainly a question of
data lifetime. And your case is clear, metadata is for you a working
tool for organisation, thus with a limited lifetime.
Some other use cases (e.g. searching ancient images collections by
tags and keywords, or - as you mention - images banks indexing) may
require the same lifetime for metadata and images.

The important thing is that it's up to each user to state what is
expected from metadata, and deduct the proper strategy.

> But now problems are solved anyway: should I loose data, I'd just ask the
> NSA or google who maybe already has reached the goal of entering into my
> computer :-)

:-)
Sure, in case of data losses, you can try sending an e-mail to President
Obama and ask for a backup.

> What makes you so sure that there will be a program capable to read XMP
> or even digital images themselves in 20 years? (Only rethoric question)

It's not only a rethorical question but also a strategic question.
What makes me confident are the definitions and aims of data standards.
A data format (under computer form, i.e. computer files) is a standard
under three conditions :

1. There must exist a specifications document describing in extenso the
representation (including specific encodings, e.g. ascii vs unicode for
human text, little or big endian for binary data, etc.), describing
data organisation, specifying the semantics.

2. The document must be registerd and managed by an official standards
management organisation, ANSI, ISO, IEEE, ACM, etc.

3. The specification must not reference or require the use of any existing
software, be it public or commercial, and must not be hooked to any
organisation, public or commercial.

Given all that, this mean that at any time in a future, individuals can
access the specification document from the official organisation, can
study the document, and can write a program to read/extract data from
a container file.
Of course, this seems a bit theorical and not every user can « write »
reading program. But this means that in case no programs exist in a
future, it's still possible to write one, or find someone to write it.
And in no case the situation could be « sorry, your format is too old
and all your data are lost ».

This is true for XMP. It has been formerly a format proposal,
by Adobe Systems, it is now an official standard (ISO 16684-1).

And, on the opposite, this is not true for databases formats.
With an application using, say SQLite3, and storing data in a file,
e.g. digikam4.db :), you can't expect archive the DB file and keep
it 20 or 30 years, because without the related software and libraries,
the file is useless. And it's very unlikely that SQLlite3 version 2034
will still open a 2014 digikam4.db.

Same for images files formats. Standard formats, JPEG, PNG, ..., can
be archived with confidence. It doesn't mean they still will be used;
I guess JPEG will disappear during the next 10 years, made obsolete
by JPEG2000. But it will still be possible to find or write tools to
read the image data and, possibly, migrate to another more recent
format.
This is not true for RAW files because they rely on cameras manufacturers
at some time, and nothing can guarantee that the manufacturer firm will
still exist in 20 years, or will still use the same proprietary format
and firmware.

So, here again, a matter of choice depending on the expected lifetime
of data.

Regards,
Jean-François
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users