Bug 149497 - Geolocation tool does not work with non-jpeg file types
Summary: Geolocation tool does not work with non-jpeg file types
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Plugin-Generic-GeolocationEdit (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-09-02 23:03 UTC by Thorsten Schnebeck
Modified: 2018-03-23 11:44 UTC (History)
2 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thorsten Schnebeck 2007-09-02 23:03:29 UTC
Version:           KDE-3-SVN (using KDE KDE 3.5.7)
Installed from:    Compiled From Sources
OS:                Linux

exiv2 is able to write geodata metadata into e.g png files. 
Its easy to tests this: Take a jpeg, add geo-data with the kipi-plugin, open in digikams image editor and save as png. You will see, the geo-data are part of the png metadata. 
 
But you can not add these geo-tag direct into a png, as you can find code like this in this plugin: 
[...] 
// We only add all JPEG files as R/W because Exiv2 can't yet 
// update metadata on others file formats. 
   QFileInfo fi(url.path()); 
   QString ext = fi.extension(false).upper(); 
   bool ret = false; 
   if (ext == QString("JPG") || ext == QString("JPEG") || ext == QString("JPE")) 
   { 
[...] 
 
So, the comment in the source code is definitely wrong and to test the file format a simple extention is used. What about kde standard test to check a filetype based on MIME data? 
 
KMimeType::Ptr type = KMimeType::findByURL("/home/bernd/foobar.jpg"); 
vs 
KMimeMagicResult *result = KMimeMagic::self()->findFileType("/home/bernd/foobar.jpg"); 
 
(from: http://developer.kde.org/documentation/library/kdeqt/kde3arch/mime.html ) 
 
Bye 

  Thorsten 

P.S.
This is a copy of BR148912 that was not forwarded to the developers from the list admin since 14 days. So I had to assign this BR to the wrong package and the digikam devels have additional needless work. Sorry for this.
Comment 1 caulier.gilles 2007-09-03 06:14:25 UTC
Thorsten,

Well no. PNG writting mode is not yet supported by Exiv2  yet (and TIFF also). If GPS info have been included in PNG after to have saved this file by image editor, this is duing than complete file have been create from scrarch using libpng. This way take a while...

Exiv2 do not create PNG file from scatch. It modif an exiting file. It's completly different.

Exiv2 write PNG support code is in alpha stage on my computer.

Gilles
Comment 2 Stephen Thompson 2007-12-25 23:16:08 UTC
I would love to be able to store GEO data in 16bit tiff files as all my photographs are stored in this format.
Comment 3 caulier.gilles 2007-12-31 10:11:46 UTC
Andreas,

This is another wish to have TIFF writting mode support with Exiv2...

Happy new year

Gilles
Comment 4 Gerhard Kulzer 2008-02-09 20:35:13 UTC
This becomes really urgent now, since we all want to use 16 bit images
Comment 5 caulier.gilles 2008-02-11 22:35:58 UTC
SVN commit 773841 by cgilles:

kipi-plugins from trunk (KDE4) : 

- Handle non jpeg files to save GPS position. If you use digiKam for KDE4, GPS position is now saved in database for all files, including read-only file formats.
This is want mean than you can geo-tagging your RAW files for example !
- Do not refresh thumbs from digiKam Album GUI interface when something is change in metadata. KDE4 version is more robust and detect automaticly wicth view must be updated in this case...

BUG: 149497
BUG: 145746

CCMAIL: digikam-devel@kde.org



 M  +60 -76    plugin_gpssync.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=773841