Bug 319492 - Scan of new items seems to ignore or badly interpret jpeg EXIF information
Summary: Scan of new items seems to ignore or badly interpret jpeg EXIF information
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Metadata-Exif (show other bugs)
Version: 5.4.0
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-05-07 20:33 UTC by lig
Modified: 2020-08-04 21:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 7.1.0
Sentry Crash Report:


Attachments
screen shot of the good case (the last two sections are missing in the other case) (86.94 KB, image/png)
2013-05-07 20:39 UTC, lig
Details
pictures freshly generated while running digikam (141.99 KB, image/png)
2016-07-13 20:11 UTC, lig
Details
after rereading meta date for this single picture (141.30 KB, image/png)
2016-07-13 20:13 UTC, lig
Details
my settings (which might be important) (196.64 KB, image/png)
2016-07-13 20:14 UTC, lig
Details

Note You need to log in before you can comment on or make changes to this bug.
Description lig 2013-05-07 20:33:10 UTC
I observed a very strange behaviour using digikam together with hugin.

workflow: 
jpegs imported from camera with digikam, creation of panoramas wih hugin on these files, panorama jpeg exif only contains limited information: section file properties (name, owner etc.), picture properties (color depth etc.)

If pictures are transferred directly from camera to computer via Nautilus and the panorama is created the EXIF information is complete: It now contains section on photo such as time taken, camera model and also the  information inserted by hugin which projection was used. All this information is displayed correctly in digikam.
 

Reproducible: Always
Comment 1 caulier.gilles 2013-05-07 20:34:43 UTC
Which digiKam version you use ?
Comment 2 lig 2013-05-07 20:39:46 UTC
Created attachment 79766 [details]
screen shot of the good case (the last two sections are missing in the other case)
Comment 3 lig 2013-05-07 20:40:37 UTC
It is version 2.8 only, I guess the newest one ready for Ubuntu
Comment 4 lig 2013-05-09 12:38:49 UTC
I found (my) mistake. Hugin generate the picture in a folder already included in a collection of  digikam. It seems there is no automatic meta data screening when new picture are detected upon start-up (Or is there an option to turn it on ????).
I manually choose reread metadata from pictures and there we go ... 

Greetings, 

Georg
Comment 5 caulier.gilles 2015-06-30 08:07:58 UTC
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?
Comment 6 lig 2015-06-30 20:12:39 UTC
Dear Gilles,

I am now on 4.11.

The problem somehow persists. I played around a bit.

Case 1: Hugin panorama is generate while digikam is not running:
==> New pic is shown, all Metadata shows up correctly (Dateieigenschaften, Eigenschaften für Einträge, Fotoeinträge, digikam-Einstellungen [in the latter the projection information added by higin]

Case 2: Hugin panorama is generated while digikam is running:
==> New pic is shown, Metadata is incomplete (shows only Dateieigenschaften, Eigenschaften für Einträge), date shown below pic is wrong (date of file generation of this panorama)
When initiating manually to reread meta data, Metadata is updated and nearly complete 
 (Dateieigenschaften, Eigenschaften für Einträge, digikam-Einstellungen but missing Fotoeinträge) date is correct
digikam is closed and started again
Now metadata is complete again (identical to case 1)

Case 3:  Hugin panorama is generated while digikam is running:
as above but no manual rereading of metadata
digikam is closed and started again
Metadata is unchanged (incomplete, wrong date) as before closing digikam

Hope this helps - there seems to be only a partial meta data updating when pictures appear while digikam is running.

Greetings,

Georg
Comment 7 caulier.gilles 2015-06-30 20:16:12 UTC
re-opened
Comment 8 caulier.gilles 2016-07-06 19:56:50 UTC
This file still valid using last digiKam 5.0.0 ?

Gilles Caulier
Comment 9 lig 2016-07-06 20:24:33 UTC
Hi Gilles,

have not updated yet. Just now installed with philip ppa.

First impression is good. Short question: Digikam5 will not use the settings made in digikam4? And will build a new sql database?

I will report on the issue after some testing.

Georg
Comment 10 lig 2016-07-13 20:09:38 UTC
Some first test show that problem is still present:

Digikam was running
HDR processing in the background
New pictures appear in album
Metadate incompletely read (see first attachment)

digikam closed and reopened

Metadata stlll incomplete and timestamp of date of creation

Upon item rereading metadata complete date is shown (see second attachment)

I also include a picture of my settings.
Comment 11 lig 2016-07-13 20:11:56 UTC
Created attachment 100076 [details]
pictures freshly generated while running digikam
Comment 12 lig 2016-07-13 20:13:35 UTC
Created attachment 100077 [details]
after rereading meta date for this single picture
Comment 13 lig 2016-07-13 20:14:54 UTC
Created attachment 100078 [details]
my settings (which might be important)
Comment 14 caulier.gilles 2016-11-25 14:37:20 UTC
What's about this file using digiKam AppImage bundle 5.4.0 pre release given at this url :

https://drive.google.com/drive/folders/0BzeiVr-byqt5Y0tIRWVWelRJenM

Gilles Caulier
Comment 15 lig 2016-11-25 17:18:53 UTC
Hi Gilles,

I tested the case again.

A HDR and four LDR are generated while digikam is running (5.30 and 5.40 appimage).

The new pictures are seen upon creation. Metadata is incomplete (only section File properties and properties of picture (jpg, size, etc.). Date shown is new creation date.

Upon manual rereading of metadata: Date is corrected to date from EXIF (which is set by my script to the EXIF date from the underlying picture stack) and keyword HDR (which my script adds) is displayed under section digikam properties.

Section picture properties (camera model and the other EXIF data) only reappears upon restarting digikam.

Identical behaviour is seen for both versions.

Hope this helps in finding the bug.

Georg
Comment 16 lig 2017-08-15 20:04:11 UTC
Hi Gilles,

I am now on 5.6.01 appimage.

Case 1: New files generated while running digikam. There is now complete information on the right hand side for the new pics. However the internal date (shown just below the picture is wrong, time of creation and not time of shooting). The tag HDR is shown on the right hand side (but not below picture). Upon rereading metadata these mistakes are corrected.


Case 2: Files are generated while digikam is not running. When digikam has started up the new files are correct (right hand side info, tag, date) - Just perfect.

Best regards,

Georg
Comment 17 caulier.gilles 2020-08-03 04:51:57 UTC
digiKam 7.0.0 stable release is now published:

https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/

We need a fresh feedback on this file using this version.

Best Regards

Gilles Caulier
Comment 18 lig 2020-08-04 19:18:27 UTC
Dear Gilles,

thanks for the new version. First experiences are good.

I tested again what happens upon generation of a picture when digikam is running. The new picture appears in the folder and the metadata (below picture and on left side is correct). No requirement to reread metadata or to close/reopen digikam.

Seems to be solved. Thanks!