Confused about "created" date/time on some photos

Hi there,

I'm new to digikam (using version 0.10 on openSuse 11), but am enjoying
it all so far, so thanks!

However I have some photos that I "processed" years ago (2004). In doing
so I (unknowingly) wiped all the EXIF data from them (I will thus refer
to them as "unEXIFed"). Naturally digikam had to guess their "creation"
date from the file modification time (earlier this year when they were
copied to their current location).

Fortunately I still had the original photos lying around, and was able
to use `exiftool` to copy the EXIF tags back into the processed
versions, _replacing_ an unEXIFed file with an "EXIFed" file (while
digikam was not running). I expected that when digikam was restarted it
would notice that these tags had been changed, rescan them and all would
be OK. Unfortunately not, despite the correct (2004) EXIF tags now
showing up in the digikam right-hand sidebar when I select the image(s),
it was still using the _unEXIFed_ modification dates as "creation" date
for the now EXIFed files. So I ran a full image/DB metadata sync (from
the "Tools" menu). Still no luck :(

A look in the digikam DB (using sqlite3) shows a few interesting things.
Firstly there seems to be two entries for the offending images in the
Images table: one with 'album' = "" and one with the correct 'album' id.
The hashes of these two entries are different however; and the
'Images,modificationDate' fields match that of the unEXIFed images and
the EXIFed one respectively. Seems like the one with 'album' = "" is
left-over from the (overwritten) unEXIFed file. Expected behaviour?

Secondly the 'ImageInformation.creationDate' values for these images are
 the same for both entries (EXIFed and unEXIFed): the file modification
date for the unEXIFed file. So it looks like the scan definitely hasn't
picked the EXIF date from the EXIFed file.

In general I'm a bit confused about what's gone on here.

Is there anyway that I can fix these dates up?

Is it safe to just delete the the rows with album = ""?

Should I file a bug?

Thanks very much,
Michael Liddle.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Hi again,

Just a report on what I've managed to achieve since posting:

Michael Liddle wrote:
> Is there anyway that I can fix these dates up?

Deleting the entries for the offending files from the Images table
forced them to be re-read, correctly. So FWIW my problem is effectively
fixed. Still might be something to look into however...

> Is it safe to just delete the the rows with album = ""?

Seemed to be, I tried it on a copy of my database and have had no
troubles (though I've not investigated much).

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

[Marcel Wiesweg]

> Hi again,
>
> Just a report on what I've managed to achieve since posting:
>
> Michael Liddle wrote:
> > Is there anyway that I can fix these dates up?
>
> Deleting the entries for the offending files from the Images table
> forced them to be re-read, correctly. So FWIW my problem is effectively
> fixed. Still might be something to look into however...

It's a deliberate decision not to do a full rescan on modification. A full
rescan need to be triggered manually. (This may be slightly broken currently)
You found the "hard" way to force a complete rescan.

>
> > Is it safe to just delete the the rows with album = ""?
>
> Seemed to be, I tried it on a copy of my database and have had no
> troubles (though I've not investigated much).

They are already in the status "removed". You are free to delete them
completely.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Marcel Wiesweg wrote:
>> Michael Liddle wrote:
>>> Is there anyway that I can fix these dates up?
>> Deleting the entries for the offending files from the Images table
>> forced them to be re-read, correctly. So FWIW my problem is effectively
>> fixed. Still might be something to look into however...
>
> It's a deliberate decision not to do a full rescan on modification. A full
> rescan need to be triggered manually. (This may be slightly broken currently)
> You found the "hard" way to force a complete rescan.

OK, as I said in my original post though, I tried "Tools -> Synchonise
all images with database" too, but that did not work either. Is that
what you mean by "may be slightly broken"?

>>> Is it safe to just delete the the rows with album = ""?
>> Seemed to be, I tried it on a copy of my database and have had no
>> troubles (though I've not investigated much).
>
> They are already in the status "removed". You are free to delete them
> completely.

So would they have been cleaned up automatically at some stage, had I
not jumped the gun?

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

On Monday 15 June 2009 20:50:53 Michael Liddle wrote:

Hello,

Mail below maybe of some interest to you if I understand correctly:

Re: [Digikam-users] Problem concerning the displayed creation date of files
without EXIF data.


From:
Thomas <[hidden email]>
  To:
"digiKam - Home Manage your photographs as a professional with the power of
open source" <[hidden email]>
  Date:
2009-05-24 13:02
   
> What you need is to put modification date somewhere in digikam database but
I
> don't know where...

Still, I do not know where digikam gets the creation date from if there
is no metadata in the file.
But "database" was a good hint. I could take the modifications dates
(which are in my case the real dates of taking the movies) and set them
as creation dates by directly modifying the digikam database.

For all people with a similar problem, here is the way I did it:
I opened the digikam database file (in my case: digikam4.db), which is a
sqlite database, with sqliteadmin running under wine. There I performed
the following SQL query:

UPDATE ImageInformation
SET creationDate = (SELECT Images.modificationDate FROM Images WHERE
ImageInformation.imageid = Images.id)
WHERE digitizationDate is null

The "WHERE digitizationDate is null" is used to adjust the creation date
only of those files without metadata.

For me this query worked fine. But of course someone should only try
this if he/she knows what this stuff is doing. Adapting the digikam
database directly could destroy it! So always make a backup before.

So, I am happy now :o)
Thanks for the hint with the database. And maybe, I could help somebody
with the sql stuff.

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