Upon reading the profile, I find an array of 3 doubles. I know that each value represents the degrees, minutes and seconds - which I can then convert into the familiar decimal coordinates.
However, all of the images I've tested on return an array containing 'infinite' values for one or more of the doubles (ie double.IsInfinity(gpsLatitude[0]) == true). Viewing the propertys sheet in windows explorer reveals the true values, which if I plot on a map, do give roughly accurate locations.
The test image attached has issues with the seconds value. The underlying EXIF value is of a Rational datatype. I know ExifReader.cpp will convert this type to a double in ToURational() but I can't see what might be wrong.
Using Magick.NET-Q16-x64 7.0.0.8 on a x64 system.
Any thoughts?
Comments: ** Comment from web user: simbolo **
Thanks for the comments. I get those same values, with the exception of where you have zeros I have 'Infinity'. That said, even if I just cast those Infinity values to zero, these decimals are still not valid degrees/minutes/seconds. For this sample image, the correct decimal values would be: 51, 31, 2.39. So very different to these tiny doubles being output currently.
I'm unable to get Magick.net to compile on my machine to step through the debugger myself. But I can see the code is similar to the code in ExifLib. ExifLib reverses the byte array for each value when calculating each double; where as Magick.Net reverses the entire data array at the before calculating the 3 values. As far as I can see this is the only difference, but since I can't compile I can't see the code in action. Since I can't spot the difference perhaps the reader is reading an incorrect part of the exif profile.
The correct byte array that is read from the exif latitude tag from the uploaded image should be as follows:
TagData:
[0] 0 byte
[1] 0 byte
[2] 0 byte
[3] 51 byte
[4] 0 byte
[5] 0 byte
[6] 0 byte
[7] 1 byte
[8] 0 byte
[9] 0 byte
[10] 12 byte
[11] 32 byte
[12] 0 byte
[13] 0 byte
[14] 0 byte
[15] 100 byte
[16] 0 byte
[17] 0 byte
[18] 0 byte
[19] 0 byte
[20] 0 byte
[21] 0 byte
[22] 0 byte
[23] 1 byte
If you are able to capture the values being read and they are different, then the incorrect bytes are being loaded for this tag. If they are the same, then they are not getting converted to doubles correctly. It'll be one of these two!