*Problem with characters Æ Ø Å in mapped IPTC-IIM on MacOSX

[mballe]

Hi,

I am trying to create cities and locations below a country in Places.

Under Denmark, I create a city named "Vallensbæk", mapping to photoshop:State, with GEO location assigned. Below that I create a location named "Vejlegårdsparken", mapping to iptc4xmpCore:Location, also with GEO location.

When I assign the label "Vejlegårdsparken" to an image, the GEO location is correctly assigned, and the location, State and country tags are correctly showing in Details. When I save the metadata changes, suddenly the tags change to show location as "Vejleg??rdsparken" and State to "Vallensb??k.

Is this a bug in Photo Supreme, or am I doing something wrong, forgetting a setting somewhere?

Thanks
Michael

[Hert]

Michael,

First of all a warm welcome to the forum. I've tried to reproduce this, but I get the correct results.

Could it be that your images already have pre-existing location details that aren't correctly encoded?
You can use a tool like ExifTool to verify that. You can also send me a sample file if you'd like me to verify the pre-existing metadata.

Hert

[Maczero]

I get this problem with the umlaut sometimes or even the copyright symbol. It mostly seems to affect jpeg images (something to do with the way that the information is written to file?).

Andrew

[Hert]

Andrew, try it in a virgin image (a new image that is not touched by any other software). With legacy images, chances are higher that umlauts aren't written correctly.

Update; just read your other post from today and I see that you mention Aperture. Aperture writes special characters in a encoding scheme that is not standard and I have still no idea what encoding they use. I never understood why Apple decided on this non-standard encoding as there are standard encoding schemes that are even prescribed by the standards (UTF8)...

[DirkS]

Update; just read your other post from today and I see that you mention Aperture. Aperture writes special characters in a encoding scheme that is not standard and I have still no idea what encoding they use. I never understood why Apple decided on this non-standard encoding as there are standard encoding schemes that are even prescribed by the standards (UTF8)...

Had a quick google and see that it's something that has been complained about for years. The suggestion is that they're using Mac Roman (see e.g. https://discussions.apple.com/thread/27 ... 0&tstart=0)
(probably Mac OS Roman: http://en.wikipedia.org/wiki/Mac_OS_Roman).
No idea if that's the case, though. I have apples, but no Apple

Gr
Dirk

[mballe]

Hert,

I have managed to come up with two files that reproduces on my machine.

I have attached two sample files.

The first is called "Without_XMP.jpg" and is a JPG file without the XMP and photoshop segments, a plain JPG, with GPS coordinates though.
The second file, "With_XMP.jpg" is the result of importing the first file into Photo Supreme, and doing a reverse geo lookup.

Right after having done the reverse geo, location, city and state is showing correctly, but after the change is applied, they suddenly change, and show with ?? instead of å and ø.

Hope this additional information is useful.

Michael

[lippe]

Also notice when 'special characters' keywords getting translated Catalog labels, the applied labels will write back the keywords even the user corrected the spelling in the xmp. I'm experienced this with metadata applied in the former IDimager: i started a battle to correct the errors and on sync, they reappeared. In V3 this seems fine and i finally won the battle!

[Ruhell]

I think there is a lot of different software around that doesn't handle "special" characters in the metadata correct (like Danish/Norwegian ÆØÅ).
I feel V3 is doing a decent job. That said, I had problems with ÆØÅ a month ago. I'm not completely sure, but I was trialing Capture1 and I think it was Capture1 that messed up something in the metadata. I could be wrong...again


Rune

[Hert]

I've looked at your attached image file.

The image is marked as metadata being last written with ExifTool. That could be ExifTool directly or an application that uses ExifTool to write metadata. Either way: this metadata was not written with Photo Supreme.

After this analysis I did this:
1. Select the image
2. Open the GEO Panel
3. Click Reverse Lookup

That will use your coordinates in the image and fetch the corresponding location details again from the internet. I then save and sync the image. The resulting metadata is correctly encoded.

[mballe]

I did use exiftool to make sure that the file was cleared from XMP and photoshop segment.

I just tried again, removing XMP and doing a reverse lookup, and I still see the problem.

I am using Mac OS X Yosemite. Could it be a platform specific issue?

[mballe]

I just did another simple test. I created a small image in Pixelmator and saved it as JPG. The created JPEG contained an empty XMP block written by Pixelmator.

I then imported the image in Photo Supreme, assigned it a location in København, and saved it, checking that the file still had a XMP block, with new info added by.

I then did a reverse lookup, and saved again. As soon as it was saved, city in Image Info changed from København to K??benhavn.

[Hondor]

I am on a Windows machine, but I'm Scandinavian, too, so I tried to reproduce your steps on my localised system with ÆØÅ's.

When I reverse-lookup Rådhuspladsen, København, I don't get any ??'s at all neither in IPTC/Location Created nor in XMP Advanced/photoshop/photoshop:City.

I think it's a localised-Mac issue

[Hert]

I can reproduce it now. It happens only on Mac and only for embedded XMP in a JPEG file.
This can be logged in Mantis.

[mballe]

I believe I have also seen it for DNG files that were converted from JPG. It could however be that the problem was already present in the jpg before it was converted.

[Hert]

Please report this in Mantis: http://mantis.idimager.com

This topic will now be closed.
I'll update the title of the topic to be more precise