[gwenview] [Bug 383520] Gwenview Importer doesn't use date/time from EXIF

[Albert Astals Cid]

https://bugs.kde.org/show_bug.cgi?id=383520

Albert Astals Cid  changed:

   What|Removed |Added

  Latest Commit||https://commits.kde.org/gwe
   ||nview/0d5915a10d5ce8e649248
   ||3bf209e654d52d8b846
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Albert Astals Cid  ---
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-0lib/exiv2imageloader.h
M  +1-10   lib/timeutils.cpp

https://commits.kde.org/gwenview/0d5915a10d5ce8e6492483bf209e654d52d8b846

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 383520] Gwenview Importer doesn't use date/time from EXIF

[Vangelis]

https://bugs.kde.org/show_bug.cgi?id=383520

--- Comment #3 from Vangelis  ---
Here it is then: https://phabricator.kde.org/D7317

Thanks.

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 383520] Gwenview Importer doesn't use date/time from EXIF

[Nate Graham]

https://bugs.kde.org/show_bug.cgi?id=383520

Nate Graham  changed:

   What|Removed |Added

 CC||pointedst...@zoho.com

--- Comment #2 from Nate Graham  ---
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/

-- 
You are receiving this mail because:
You are watching all bug changes.

[gwenview] [Bug 383520] Gwenview Importer doesn't use date/time from EXIF

[Vangelis]

https://bugs.kde.org/show_bug.cgi?id=383520

--- Comment #1 from Vangelis  ---
Created attachment 107279
  --> https://bugs.kde.org/attachment.cgi?id=107279=edit
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.

-- 
You are receiving this mail because:
You are watching all bug changes.