adam/Piwigo
1
0 Fork 0
mirror of https://github.com/Piwigo/Piwigo.git synced 2026-11-03 07:22:22 +01:00
Code Issues 657 Packages Projects Releases Wiki Activity

Exif creation date is not saved for photos taken by certain devices (Huawei) #836

New Issue
Open
opened 2026-10-05 00:19:52 +02:00 by adam · 9 comments
adam commented 2026-10-05 00:19:52 +02:00
Owner
Copy link
Copy source

I realized pictures taken from for instance Huawei mobile phones do not have creation date in piwigo. There is just NULL in date_creation column in piwigo_images database table. This is bad as then features like grouping by creation date does not work properly.
You can test on some samples: https://www.flickr.com/photos/146228843@N02/sets/72157677734463334/

I realized pictures taken from for instance Huawei mobile phones do not have creation date in piwigo. There is just NULL in date_creation column in piwigo_images database table. This is bad as then features like grouping by creation date does not work properly. You can test on some samples: https://www.flickr.com/photos/146228843@N02/sets/72157677734463334/ <!-- github-sync-id:374262628 -->
adam commented 2026-10-05 00:19:53 +02:00
Author
Owner
Copy link
Copy source

Hi, I'm currently having a similar problem...DateTimeOrignal linked to date_creation then update picture meta data give it a sec n refresh....it generates the creation date but then I can't see no way to do this for all photos just individual.
I have 20,000 photos that this is happening too.... :-(

Hi, I'm currently having a similar problem...DateTimeOrignal linked to date_creation then update picture meta data give it a sec n refresh....it generates the creation date but then I can't see no way to do this for all photos just individual. I have 20,000 photos that this is happening too.... :-( <!-- github-comment-id:433324231 -->
adam commented 2026-10-05 00:19:54 +02:00
Author
Owner
Copy link
Copy source

Just looked at your photos on flicker ... Seems Hawaii use taken_on date in meta data ?? Use meta data check on piwigo see if that is the case then change the PHP respectively :-)

Just looked at your photos on flicker ... Seems Hawaii use taken_on date in meta data ?? Use meta data check on piwigo see if that is the case then change the PHP respectively :-) <!-- github-comment-id:433356109 -->
adam commented 2026-10-05 00:19:54 +02:00
Author
Owner
Copy link
Copy source

@m-rufflesmcghie : those pictures are not mine, I used it as a reference (googled for huawei sample photos) as I have the same issue on my photos. But if needed I can provide also some of my own photos.

When I was roughly checking piwigo source files I can see it use exif_read_data() php function. I tested it on both cases - an image with proper date/time in piwigo and the one which have null there. I noticed for the non working one the function returns field [DateTime] and for the working one it returns [DateTime] but also [DateTimeOriginal] as well as [DateTimeDigitized]. Maybe this is the issue? Piwigo maybe awaits one of those elements to be presen, otherwise setting NULL?

@m-rufflesmcghie : those pictures are not mine, I used it as a reference (googled for huawei sample photos) as I have the same issue on my photos. But if needed I can provide also some of my own photos. When I was roughly checking piwigo source files I can see it use exif_read_data() php function. I tested it on both cases - an image with proper date/time in piwigo and the one which have null there. I noticed for the non working one the function returns field [DateTime] and for the working one it returns [DateTime] but also [DateTimeOriginal] as well as [DateTimeDigitized]. Maybe this is the issue? Piwigo maybe awaits one of those elements to be presen, otherwise setting NULL? <!-- github-comment-id:433365257 -->
adam commented 2026-10-05 00:19:55 +02:00
Author
Owner
Copy link
Copy source

This seems to work for me as a workaround. Change in include/config_default.inc.php:

Change this:

// use_exif_mapping: same behaviour as use_iptc_mapping
$conf['use_exif_mapping'] = array(
  'date_creation' => 'DateTimeOriginal'
  );

To this:

// use_exif_mapping: same behaviour as use_iptc_mapping
$conf['use_exif_mapping'] = array(
  'date_creation' => 'DateTime'
  );

But this workaround is not the best idea as I read (https://forums.adobe.com/thread/427502) the difference between those 3 exif elements is:
Date/Time - the date and time a file was last updated
Date/Time Original - the date and time an image was taken
Date/Time Digitized - the date and time the image was stored as digital information

So if somebody update (what update means is not clear to me - but perhaps editing in a photo editor?) the image, then the date might completely different and unusable for the purpose we need.
So the problem seems to be in a Huawei (or some other device) which does not write all 3 DateTime* elements into EXIF. But it does not seems to be true. It looks php function exif_read_data() will not discover these elements but when checking the "bad" jpg in linux command line using exiftool I get also
DateTimeOriginal element.

So now what? :)

I use PHP version 7.2.10.

This seems to work for me as a workaround. Change in include/config_default.inc.php: Change this: ``` // use_exif_mapping: same behaviour as use_iptc_mapping $conf['use_exif_mapping'] = array( 'date_creation' => 'DateTimeOriginal' ); ``` To this: ``` // use_exif_mapping: same behaviour as use_iptc_mapping $conf['use_exif_mapping'] = array( 'date_creation' => 'DateTime' ); ``` But this workaround is not the best idea as I read (https://forums.adobe.com/thread/427502) the difference between those 3 exif elements is: Date/Time - the date and time a file was last updated Date/Time Original - the date and time an image was taken Date/Time Digitized - the date and time the image was stored as digital information So if somebody update (what update means is not clear to me - but perhaps editing in a photo editor?) the image, then the date might completely different and unusable for the purpose we need. So the problem seems to be in a Huawei (or some other device) which does not write all 3 DateTime* elements into EXIF. But it does not seems to be true. It looks php function exif_read_data() will not discover these elements but when checking the "bad" jpg in linux command line using exiftool I get also DateTimeOriginal element. So now what? :) I use PHP version 7.2.10. <!-- github-comment-id:433373706 -->
adam commented 2026-10-05 00:19:56 +02:00
Author
Owner
Copy link
Copy source

I found those images which do not have date/time set in piwigo database produce following Warning in php error log:

PHP Warning: exif_read_data(IMG_20181027_153225.jpg): Process tag(x010D=DocumentNam): Illegal components(0)

I found a stackoverflow question where the same issue is discussed. There is a recommendation to use imagick class to get all the exif tags:

https://stackoverflow.com/questions/5184748/php-bad-exif-data-warnings-what-to-do

I found those images which do not have date/time set in piwigo database produce following Warning in php error log: PHP Warning: exif_read_data(IMG_20181027_153225.jpg): Process tag(x010D=DocumentNam): Illegal components(0) I found a stackoverflow question where the same issue is discussed. There is a recommendation to use imagick class to get all the exif tags: https://stackoverflow.com/questions/5184748/php-bad-exif-data-warnings-what-to-do <!-- github-comment-id:433643826 -->
adam commented 2026-10-05 00:19:56 +02:00
Author
Owner
Copy link
Copy source

Out of interest do you have a filedatetime in EPOCH ?? Thinking about trying to change sync to include as a normal date if DateTimeOrignal does not exist

Out of interest do you have a filedatetime in EPOCH ?? Thinking about trying to change sync to include as a normal date if DateTimeOrignal does not exist <!-- github-comment-id:433721052 -->
adam commented 2026-10-05 00:19:57 +02:00
Author
Owner
Copy link
Copy source

@m-rufflesmcghie exif_read_data returns FileDateTime array element in unix epoch time, but I assume this would also change if there was an edit of the image.

@m-rufflesmcghie exif_read_data returns FileDateTime array element in unix epoch time, but I assume this would also change if there was an edit of the image. <!-- github-comment-id:433738951 -->
adam commented 2026-10-05 00:19:58 +02:00
Author
Owner
Copy link
Copy source

Yeah, after investigating due to me moving from Picasa I now have 5000 photos with the same FileDateTime :-(
For the moment I'm storing them as a very old date 01/01/1920 then will have to go though individually & work out the date from picture :-(

Yeah, after investigating due to me moving from Picasa I now have 5000 photos with the same FileDateTime :-( For the moment I'm storing them as a very old date 01/01/1920 then will have to go though individually & work out the date from picture :-( <!-- github-comment-id:433739986 -->
adam commented 2026-10-05 00:19:59 +02:00
Author
Owner
Copy link
Copy source

I think the issue should be fixed in piwigo (that php function for exif tags is not reliable) as many people have huawei (maybe even some other brands are affected) phones and are unable to use their photos properly in piwigo.

I think the issue should be fixed in piwigo (that php function for exif tags is not reliable) as many people have huawei (maybe even some other brands are affected) phones and are unable to use their photos properly in piwigo. <!-- github-comment-id:433796106 -->
Sign in to join this conversation.
No Branch/Tag Specified
Labels
No items
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: adam/Piwigo#836