1. 06 Apr, 2020 1 commit
  2. 01 Jan, 2019 1 commit
    • Stefan Brüns's avatar
      Use forward declaration for Exiv2::Image, port to std::unique_ptr · 61543b42
      Stefan Brüns authored
      Summary:
      Instead of the Exiv2::Image::AutoPtr typedef just use a forward declaration
      for Exiv2::Image, and use std::unique_ptr instead of std::auto_ptr.
      
      The forward declaration avoids pulling in Exiv2 declarations everywhere,
      e.g. via document.h.
      
      Although it would be possible to use std::auto_ptr, unique_ptr is
      preferable for two reasons:
      - ownership transfer is explicit (std::move, release()/reset())
      - Exiv2 0.28 will use std::unique_ptr as well, i.e. the code is forward
      compatible.
      
      Reviewers: #gwenview, cfeck, ngraham
      
      Reviewed By: #gwenview, ngraham
      
      Subscribers: lbeltrame, ngraham, asturmlechner, shubham
      
      Tags: #gwenview
      
      Differential Revision: https://phabricator.kde.org/D17872
      61543b42
  3. 26 Jul, 2018 1 commit
  4. 10 Sep, 2017 1 commit
    • Vangelis Tasoulas's avatar
      Fix Gwenview Importer doesn't use date/time from EXIF · 0d5915a1
      Vangelis Tasoulas authored
      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.
      
      BUGS: 383520
      
      Reviewers: gateau, lukas, ngraham, #kde_applications, aacid, broulik
      
      Reviewed By: gateau, ngraham
      
      Subscribers: alexeymin, cfeck
      
      Differential Revision: https://phabricator.kde.org/D7317
      0d5915a1
  5. 16 Dec, 2011 1 commit
  6. 20 Nov, 2011 1 commit
  7. 18 Nov, 2011 1 commit
  8. 09 May, 2009 1 commit
  9. 09 Jan, 2008 1 commit
  10. 17 Dec, 2007 1 commit
  11. 08 Nov, 2007 1 commit
  12. 03 Nov, 2007 1 commit