View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000678 | GeoSetter | Image Data | public | 2010-11-07 09:45 | 2011-01-09 16:23 |
Reporter | arkb | Assigned To | Friedemann | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 3.3.60 Release | ||||
Target Version | Fixed in Version | 3.4.0 Release | |||
Summary | 0000678: Sometimes GeoSetter creates IPTC metadata without specifying character set | ||||
Description | Hello, I noticed that sometimes GeoSetter creates IPTC metadata without specifying character set. This issue leads to corruption of location information in other programs like Adobe Lightroom. That's why I think this issue is of major severity. I investigated the issue a little and this is what I found. First of all, I am using the latest version of GeoSetter (3.3.60) and ExifTool (8.37). GeoSetter is configured to use UTF-8 for IPTC character encoding and settings for .DNG files are: The following settings are ON, all others are OFF: - Don't create internal XMP if it doesn't exist already... - Save IPTC Data as Unicode... - Overwrite original file... - Set file date from taken time... Here is the what happens. I have a .dng file in Adobe Lightroom which already has some geotagging metadata. I want to do non-ITPC-related change like to change the point of view. Note that this file has already location fields set and some of these fields use non-English characters. Specifically, in my file State/Province is "Île-de-France" (note that the first character is a French character). I ran "exiftool -a -u -g1 <file>" and noticed that apparently Lightroom removes the IPTC section when it writes metadata to the file. So when this file gets opened by GeoSetter, it does not have IPTC info. Instead, I found that info in the "XMP-photoshop" section as reported by exiftool. Now I change the point of view in GeoSetter, save the changes, and ask Lightroom to re-read metadata from the file. Lightroom shows corrupted "State/Province" field. I ran "exiftool" again on the file modified by GeoSetter and found (among other things) that GeoSetter inserted the following info into the file: ---- IPTC ---- By-line : Photographer: My name City : Paris Province-State : ÃŽle-de-France Country-Primary Location Code : FRA Country-Primary Location Name : France Copyright Notice : Copyright: My name Application Record Version : 4 Date Created : 2010:08:24 Time Created : 18:59:55+02:00 I played a little and found that if I also change some location information in GeoSetter (like setting sub-location to some arbitrary value, "_" in this case), Lightroom shows the correct value for the "State/Province" field. I re-ran exiftool and found that in the latter case GeoSetter again inserted ITPC info into the file (see below). However this time this info includes the "coded character set" field with "UTF8" value. So I believe this is the reason why Lightroom interprets location info correctly now. I think GeoSetter should not write IPTC info at all if it was not changed. Alternatively, if it writes the info, it should always specify the character set this info is encoded in. ---- IPTC ---- Coded Character Set : UTF8 Envelope Record Version : 4 Application Record Version : 4 Date Created : 2010:08:24 Time Created : 18:59:55+02:00 By-line : Photographer: My Name City : Paris Sub-location : _ Province-State : ÃŽle-de-France Country-Primary Location Code : FRA Country-Primary Location Name : France Copyright Notice : Copyright: My Name | ||||
Tags | No tags attached. | ||||
|
A little correction: Apparently GeoSetter adds this "Coded Character Set : UTF8" info (which solves the problem) when the file gets saved second time. I.e, on first save GeoSetter inserts a new ITPC block without specifying character set. On second save it adds the character set info. |
|
UNfortunately I can not reproduce the problem: 1. I imported a CR2 image file into LR converting it to DNG 2. I changed state/province to "Île-de-France" in LR 3. After opening it in GeoSetter, assigning a coordinate and saving I get the following save report: Saved (0,98s): R:\Test\DNG-Test\2010-12-26-222250.dng Params: C:\Users\fri\AppData\Roaming\GeoSetter\tools\exiftool.exe -@ "C:\Users\fri\AppData\Local\Temp\et00454154.arg" "R:\Test\DNG-Test\2010-12-26-222250.dng" Arguments: -overwrite_original -EXIF:GPSLatitude=54.86892706 -EXIF:GPSLongitude=9.40554142 -EXIF:GPSLatitudeRef=N -EXIF:GPSLongitudeRef=E -EXIF:GPSMapDatum=WGS-84 -EXIF:GPSVersionID=2.2.0.0 -EXIF:GPSAltitude=40.000000 -EXIF:GPSAltitudeRef=Above Sea Level -EXIF:GPSDateStamp=2010:12:26 -EXIF:GPSTimeStamp=21:22:50 -XMP:GPSLatitude=54.86892706 -XMP:GPSLongitude=9.40554142 -XMP:GPSVersionID=2.2.0.0 -XMP:GPSMapDatum=WGS-84 -XMP:GPSAltitude=40.000000 -XMP:GPSAltitudeRef=Above Sea Level -XMP:GPSDateTime=2010-12-26T21:22:50Z -XMP:Creator=Friedemann Schmidt -IPTC:CodedCharacterSet=UTF8 -IPTC:By-Line=Friedemann Schmidt -XMP:AuthorsPosition= -XMP:CountryCode= -XMP:Country= -XMP:State=ÃŽle-de-France -IPTC:Province-State=ÃŽle-de-France -XMP:City= -XMP:Location= -XMP:Artist= -XMP:Description= -XMP:Instructions= -XMP:Title= -XMP:Headline= -XMP:Credit= -XMP:Rights=Friedemann Schmidt -IPTC:CopyrightNotice=Friedemann Schmidt -XMP:CaptionWriter= -XMP:Source= -XMP:Category= -xmp:rating= -xmp:ratingpercent= -XMP:Label= -XMP:CreatorAddress= -XMP:CreatorPostalCode= -XMP:CreatorCity= -XMP:CreatorRegion= -XMP:CreatorCountry= -XMP:CreatorWorkTelephone= -XMP:CreatorWorkEmail= -XMP:CreatorWorkURL= It contains IPTC:CodedCharacterSet=UTF8 and after saving the DNG also contains this flag. Is this problem still reproducable for you? Can you perhaps try it out with the beta version http://www.geosetter.de/geosetter_beta.exe ? This version is nearly finished and will be released soon... |
|
I actually still can repro this problem. However it seems to me that GeoSetter's behavior (even of the latest beta) is not predictable in respect to this IPTC:CodedCharacterSet flag. Sometimes GeoSetter indeed sets this flag, sometimes it does not and I was not able to figure out what affects its behavior. Please try the following: Initial steps: 1. Import a cr2 photo to Lightroom converting it to dng. 2. Select a photo and save metadata by using menu "Metadata"->"Save Metadata to File". 3. Start GeoSetter and assign some geo info to the photo. I would suggest to use lattitude 43.69702167 and longtitude 7.27042258. This should resolve to the province "Provence-Alpes-Côte d'Azur". 4. Save changes in GeoSetter and terminate it. 5. In Lightroom re-read metadata by "Metadata"->"Read Metadata from File". Most likely the State/Province field there will look fine. Repeat the following steps: 6. In Lightroom select a photo and save metadata by using menu "Metadata"->"Save Metadata to File". 7. Please confirm that there is no IPTC character set is set on this photo, this is critical! On Windows platform I do this by running "exiftool -a -u -g1 photo.dng |findstr /i Character". It should not report anything. If it does, then probably your settings in Lightroom do not match mine and I will need to investigate more. 8. Now start GeoSetter, locate the photo and slightly move photo's position marker. Select "Move Image" in the "Changed Position" dialog box. 9. Save changes and terminate GeoSetter. 10. Again check that there is no IPTC character set is in metadata by running "exiftool -a -u -g1 photo.dng |findstr /i Character". At this moment sometimes exiftool shows UTF-8 character set, sometimes does not. If you see UTF-8 here, go to step 6 and try again. It took maximum 2-3 retries for me to repro the problem. 11. If you do not see IPTC character set, switch to Lightroom and re-read photo's metadata by selecting the photo and doing "Metadata"->"Read Metadata from File". Now you should see that the State/Province field in Lightroom gets corrupted (the funny French "O with hat" will be changed to something else. Again, if you do not see the repro, please re-try starting from the step 6 few times. Hope this will help. |
2011-01-09 15:11
|
|
|
I really hope I fixed this now. Please take a look at the attached screen shot "set_iptc_creation_date_from_taken_date.jpg". Do you perhaps have this option activated? In my situation the IPTC creation date forces the UTF8 flag to be removed when the IPTC creation date will be saved among others... There's a new beta 3.3.103 with which you shouldn't get the problem anymore - I hope. It's available at http://www.geosetter.de/geosetter_beta.exe |
|
Sorry for re-opening this issue, I could not figure out how to leave a comment without doing so. I confirm that I indeed have this flag (set IPTC date from taken date) checkbox enabled. I also confirm that the most recent beta 3.3.103 build 2083 fixes the problem. Thanks a lot for fixing this issue, it was a real pain for me. |
|
> I also confirm that the most recent beta 3.3.103 build 2083 > fixes the problem. > Thanks a lot for fixing this issue, it was a real pain for me. Fine :-) Thanks a lot too to you for your help and patience! |
Date Modified | Username | Field | Change |
---|---|---|---|
2010-11-07 09:45 | arkb | New Issue | |
2010-11-07 09:55 | arkb | Note Added: 0001318 | |
2010-11-07 14:28 | Friedemann | Status | new => assigned |
2010-11-07 14:28 | Friedemann | Assigned To | => Friedemann |
2011-01-05 14:18 | Friedemann | Note Added: 0001380 | |
2011-01-05 14:18 | Friedemann | Status | assigned => feedback |
2011-01-09 13:16 | arkb | Note Added: 0001402 | |
2011-01-09 15:11 | Friedemann | File Added: set_iptc_creation_date_from_taken_date.jpg | |
2011-01-09 15:15 | Friedemann | Note Added: 0001403 | |
2011-01-09 15:15 | Friedemann | Status | feedback => resolved |
2011-01-09 15:15 | Friedemann | Fixed in Version | => 3.4.51 beta |
2011-01-09 15:15 | Friedemann | Resolution | open => fixed |
2011-01-09 16:20 | arkb | Note Added: 0001404 | |
2011-01-09 16:20 | arkb | Status | resolved => feedback |
2011-01-09 16:20 | arkb | Resolution | fixed => reopened |
2011-01-09 16:23 | Friedemann | Note Added: 0001405 | |
2011-01-09 16:23 | Friedemann | Status | feedback => resolved |
2011-01-09 16:23 | Friedemann | Resolution | reopened => fixed |