So, I tested moving the file in a folder in English, BUT, it did not work! >Either the file name or the path contains accented characters:Īha! I used Kanji (one of UTF-8 character set) for the path. Test the following line with and without '-charset filename=latin'Įxiftool -a -G1 -s -charset filename=latin 'FullPathFile' Either the file name or the path contains accented characters: the problem does not come from GeoSetter but from Exiftool which is used be GeoSetter to retrieve the metadata I have already asked to be able to add instructions when reading exiftool tags (see 2509)īut, I think '-charset filename=latin' will not resolve the situation, because the target filename is already in Latin, and, CR2 files (in Latin) does not have the problem. The problem 'Filename encoding not specified' is due to the fact that an instruction like '-charset filename=latin' is missing. So, GS fails to match with GPX data set.Īssociate to the date/time fetch error, GS fails to get Aperture and Shatter speed data. GS 4.0.49 forgets to fetch date/time from EXIFTool for CR3 imageĬR3 files out of Canon R6 do not have date/time in GeoSetter 4.0.49.

There are no notes attached to this issue. ('convert wrong knots to km/h' ore something like that). This would be great to correct the speed manually!Įven better would be a button to correct the most common errors in GPS-Loggers I have no idea ot the code point to insert this Longitude wrapper: Var osm = new L.TileLayer(osmUrl, ).addTo(map) īut this is only a helper for not click outside -180 - 180.īetter was a Longitude wrapper, that the Longitude range is always -180 - 180. That is a problem by reading and working with this Longitude data.Īctivate a noWrap in the linked map_google.html: The geosetter don't check the values and passed the false values to exiftool. That results possible in false Longitudes (less than -180 or greater than 180). NoWrap missing results in false used the modified map_google.html from Motalf posted here:

ExifTool 12.68 download the new version