Gwenview Importer only uses date/time from the filesystem to rename files. Not the EXIF information that holds the correct date/time that the picture has been taken.
Created attachment 107279 [details] Proposed patch After looking into the code, I found out that the datetime is determined by calling the function 'TimeUtils::dateTimeForFileItem'. Consequently, the function 'TimeUtils::dateTimeForFileItem' is calling the function 'updateFromExif()' which in turn calls the function 'Exiv2ImageLoader::load' that returns 'false'. Then it falls back at reading the datetime from the filesystem metadata. After printing out the error messages that cause the function 'Exiv2ImageLoader::load' to return 'false', I found that the Exiv2 error message is 'Failed to read image data' (doesn't help much). However, after I started playing with the size of the 'QByteArray header' (at the line where the file is read) that is passed as an argument to the 'Exiv2ImageLoader::load' function, I observed different errors until I managed to read the exif info from the file properly. Some example sizes and different reported errors by Exiv2: 65536: Failed to read image data 66000: JPEG format error, rc = 5 131072 It reads fine. No error. Didn't check numbers between 66000 and 131072 in order to find the exact threshold where I don't get a problem/error reading the exif information, but why should gwenview even bother about this number since exiv2 can do the job if we only provide the url (filepath) of the file to the Exiv2::ImageFactory::open() function? I guess exiv2 probably does the image reading in an even more efficient way according to the JPEG (or other) standard specifications (other than passing it a fixed number of bytes from an image as gwenview currently does). So attached you can find a proposed patch that does exactly that: Modifies the function "Exiv2ImageLoader::load(const QByteArray& data)" -> "Exiv2ImageLoader::load(const QString filePath)" and lets the Exiv2 library to handle the rest based on the given filePath.
Thanks for the patch! Would you be able to upload it to phabricator? More devs will see it there (and don't forget to reference this bug report)! https://phabricator.kde.org/
Here it is then: https://phabricator.kde.org/D7317 Thanks.
Git commit 0d5915a10d5ce8e6492483bf209e654d52d8b846 by Albert Astals Cid, on behalf of Vangelis Tasoulas. Committed on 10/09/2017 at 16:22. Pushed by aacid into branch 'Applications/17.08'. Fix Gwenview Importer doesn't use date/time from EXIF Summary: Gwenview Importer only uses date/time from the filesystem metadata when renaming imported photos. Not the EXIF information that holds the correct date/time that the picture has been taken. After looking into the code, I found out that the datetime is determined by calling the function 'TimeUtils::dateTimeForFileItem'. Consequently, the function 'TimeUtils::dateTimeForFileItem' is calling the function 'updateFromExif()' which in turn calls the function 'Exiv2ImageLoader::load' that returns 'false'. Then it falls back at reading the datetime from the filesystem metadata. After printing out the error messages that cause the function 'Exiv2ImageLoader::load' to return 'false', I found that the Exiv2 error message is 'Failed to read image data' (doesn't help much). However, after I started playing with the size of the 'QByteArray header' (at the line where the file is read) that is passed as an argument to the 'Exiv2ImageLoader::load' function, I observed different errors until I managed to read the exif info from the file properly. Some example sizes and different reported errors by Exiv2: 65536: Failed to read image data 66000: JPEG format error, rc = 5 131072 It reads fine. No error. Didn't check numbers between 66000 and 131072 in order to find the exact threshold where I don't get a problem/error reading the exif information, but why should gwenview even bother about this number since exiv2 can do the job if we only provide the url (filepath) of the file to the Exiv2::ImageFactory::open() function? I guess exiv2 probably does the image reading in an even more efficient way according to the JPEG (or other) standard specifications (other than passing it a fixed number of bytes from an image as gwenview currently does). So attached you can find a proposed patch that does exactly that: Adds a second instance of the function "Exiv2ImageLoader::load()" that acceps a "QString filePath" parameter and lets the Exiv2 library to handle the rest based on the given filePath. Reviewers: gateau, lukas, ngraham, #kde_applications, aacid, broulik Reviewed By: gateau, ngraham Subscribers: alexeymin, cfeck Differential Revision: https://phabricator.kde.org/D7317 M +15 -10 lib/exiv2imageloader.cpp M +1 -0 lib/exiv2imageloader.h M +1 -10 lib/timeutils.cpp https://commits.kde.org/gwenview/0d5915a10d5ce8e6492483bf209e654d52d8b846