IMatch 2018 Sneak Peak: Map Panel Enhancements

[Mario]

In addition to the enhancements regarding importing GPX track logs I've started looking into the  Map Panel to Show Camera Heading from GPS feature request, which has got a substantial number of +1. This of course gives this FR some priority.

Unfortunately, this is quite a substantial enhancement. Which requires a lot of plumbing in the background. For example, to correctly represent the field of view ("fov") on the map (the triangle indicating the area visible on the (uncropped) photo) IMatch needs the 35mm equiv focal lens, which is not always available. To calculate it from the focal length recorded in the image, IMatch needs the crop factor for the given camera. And this requires IMatch to build a database for each camera model, and for me to search the Internet for technical documentation for all camera models. To figure out their crop factors or sensor sizes.

I've just asked users to help with that in another post. Only a few users responded so far. If your camera model is not included, you won't be able to use this feature properly. So please post your camera models and sensor sizes.

There are many other things I have to figure out, starting with the math to the two separate implementations I have to make for everything in order to keep up support for OpenStreetMaps, Bing Maps and Google Maps. Which I definitely want. I don't want to force users to use Google Maps, for obvious reasons.

The Map Panel should also provide a feature to set the destination ("Looked at") coordinates. And this not only affects the map panel but also filters, reverse geo-coding and more. I'm still figuring out how existing features will be affected. There are also recommendations of the Metadata Working Group to take into account, plus compatibility issues related to other applications which manage GPS coordinates. complicated.

I've made at least the tiniest bit of progress. This is what my test map panel can do already:



I'm not promising anything, but I'm definitely looking into this.

[jch2103]

Excellent. Hope this works out.

[Carlo Didier]

If you don't have an angle of view for the triangle, maybe you could then just show an arrow for the direction?

[Mario]

The direction (GPS destination point, "Location shown" in IPTC terms) is required for the FOV ("Triangle") display.
To display the FOV, IMatch needs to create a destination point first (It assumes North direction and a certain distance from the camera). You can then move this destination point around as needed. The FOV overlay display is optional but needs the direction created by the line between the GPS point (camera) and destination point.

Furthermore, if there is no GPS data for a file and the user adds a point on the map, IMatch can either treat this as the "destination / looked at" point or the camera standpoint (like it is now). To display the FOV, both points are needed, even if they are basically on the same spot, with a few meters distance.

I have to look into this, maybe automatically deriving the destination point from focus information ("subject distance") or something, to give the user something to work with. As I said above, there are many things to consider. I'm still in the eval phase.

IMatch can render the FOV even if the sensor size / crop factor of the camera is not known. It can always assume a FX (full-frame) sensor with a crop factor of 1.
This will not be "correct" so I want to maintain the camera database an I will also add a feature that prompts the user for missing crop factor and then records this in the user settings. The user will be able to send me the make/model/crop via email so I can add it to the database for the next release.

Another thing I'm pondering is how to deal with crops. If the camera records a sensor size of 5000xsomething but the image is 800xsomething, the FOV of the image also has changed. Should this be considered for the FOV triangle? Always? Optional? Would that not confuse normal users?....

[pmbvw]

Hi Mario, great news.

I hope it works with my most used CANON 5D MK3.
My picture-examples as attachements in 
https://www.photools.com/community/index.php?topic=6926.0
are now looking crucial. Last year or before changing the provider they are looking nice.

If you want, I can send new examples.

[Mario]

are now looking crucial. Last year or before changing the provider they are looking nice.

I don't understand...

[pmbvw]

are now looking crucial. Last year or before changing the provider they are looking nice.

I don't understand...

If I open my attachements of the original post, reply Nr. #15 with Irfanview, I get washed out and greenish photos.
https://www.photools.com/community/index.php?topic=6926.0

In the attachement of this post you find the same pics I have sent 10 months ago. See the difference.
So something has going wrong with the attachements in your photools blog in the last 10 months

[Mario]

I downloaded the originals and I see mo washed out colors.
When I recall correctly, IrfanView does not do color management. Maybe that's the issue?

[pmbvw]

I downloaded the originals and I see mo washed out colors.
When I recall correctly, IrfanView does not do color management. Maybe that's the issue?

Maybe,
but if I open the original attachments from my original post from   July 23, 2017 NR # 15 with XNVIEW, DXO or Irfanview,
everytime I get this result (see attachement here, opened with DXO)

[sinus]

Yep, the original files are flawed.
So, not good, but not really a problem.

[Mario]

I checked the wrong file. Yes, the image looks washed out. But no error messages from Windows WIC or my image libraries or ExifTool.

I have downloaded the file again.
It only contains the GPS coordinates generated by the camera, but no destination GPS coordinates.
Looks like you did not let GeoSetter save the coordinates in the file. All GPS Dest values show as unknown or 0.

[GPS]           GPS Dest Latitude Ref           : Unknown ()
[GPS]           GPS Dest Latitude               : 0 deg 0' 0.00"
[GPS]           GPS Dest Longitude Ref          : Unknown ()
[GPS]           GPS Dest Longitude              : 0 deg 0' 0.00"
[GPS]           GPS Dest Bearing Ref            : Unknown ()
[GPS]           GPS Dest Bearing                : 0
[GPS]           GPS Dest Distance Ref           : Unknown ()
[GPS]           GPS Dest Distance               : 0
[GPS]           GPS Processing Method           :
[GPS]           GPS Area Information            :
[GPS]           GPS Date Stamp                  : 2012:06:11
[GPS]           GPS Differential                : No Correction


These values (straight from ExifTool) are quite odd. Because they are invalid and should not have been written at all.

[pmbvw]

Hello Mario
you are right. I never let GeoSetter changing my files. I only use GeoSetter to see the imageDirection in the map.

To your statement: "These values (straight from ExifTool) are quite odd. Because they are invalid and should not have been written at all."

All my pictures from my Canon 5d MK3 with my CANON-GP-E2-GPS-Tagger onboard have these GPS Dest. Infos as Unknown like you are showing in your last post.
Also my Original .CR2 or .JPG  have these Dest  values out of the cam in the exif, written from Canon. (see the attachement with output from EXIF Tool GUI)

To build the Image direction as a triangle in the map,  GeoSetter does not seem to need these informations.
If you need an original file for testing, I can send you an original .CR2 or original .jpg-File

[Mario]

Per EXIF standard, if there are no destination coordinates, the camera should not write them at all. Not just fill in some invalid data.
Looks like another "issue" with Canon metadata. They just don't care.
The file also has a hard-coded "Rating: 0" value, which will interfere with XMP metadata in the sidecar file. Another Canon bug.
See: https://www.photools.com/community/index.php?topic=4102.msg27503#msg27503

When I look at your file in GeoSetter it shows a dest  marker located somewhere in the South Atlantic, near the African coast.
This is to be expected because your file has a destination coordinate pair, but it is invalid.

To build the Image direction as a triangle in the map,  GeoSetter does not seem to need these informations.

The image has an "image Direction" value of 26°. Most likely this was written by your camera.
This is used to "aim" the field of view triangle, 26° into the NE direction.

Usually the destination coordinate and the image direction field are linked, because the both come from the same source.
By setting a destination point you also define the image direction. From the direction alone no dest coordinate can be calculated.

Your camera writes incomplete and invalid metadata. I would ask Canon about this. But they won't care.

[pmbvw]

Damned.
Now I can see, how hard your job is, when one of the biggest camera maker writes false data in his EXIF-tags.
And now I can understand, what the red line in the Geosetter Output means. The red line shows the direction to the false destination point in the south atlantic.  --> Terrible.

Nonetheless, for a basic and easiest implementation and writing the triangle I mean, you only need:
The position (Latitude and Longitude)   
The "GPS Img direction"  in the example  26
and "Field of view"   in the example  31,8 deg

Good luck for implementation !!!

[Mario]

Image Direction is optional and only written by some cameras with embedded GPS receivers and/or compasses.
Field of View is a value calculated by ExifTool. It is also optional and not available for a large section of my test files.
IMatch cannot rely on this info.

Of course if image direction is specified, IMatch will use it to set the initial FOV direction and also as a guide for creating the destination. Else IMatch will assume 0°.
Field of View is more reliably calculated by using the IMatch camera database and the crop factor available there.
I'm not sure but I think ExifTool takes image crops into account, if the image dimensions differ from the sensor pixel resolution. I'm not sure if this makes sense in all cases. And I'm quite sure that IMatch users might want control over that (show the "real" FOV or the FOV that stems from whatever their last crop has left of the image...).

[stonecherub]

As a geologist studying volcanoes, I take a lot of pictures - thousands. Consider two of my cameras; an eight year old Nikon D5000 and a Mavic Pro drone. The Mavic collects data 10 times a second including GPS latitude, longitude, and altitude, camera azimuth and gymbal pitch, video start and stop, and time of exposure for a dng. The Nikon collects nothing but pixels. I use Geosetter to find its location by synchronizing the internal clock with universal time and combining the image folder with the gpx track from my Garmin.

Which is to say, only my Mavic log files contain the specific things necessary to implement your Map Panel Enhancements. The Nikon? Not so much. Nothing records camera azimuth and measuring it would be a huge pain in the ass. Same for optical axis vertical angle.

Just some thoughts.

[Mario]

I'm not sure what you're heading at.

The typical workflow for people interested in GPS data is:

a) The camera does not record GPS data => They set it in the IMatch Map Panel.
b) The camera records GPS data. Since the camera only knows its position, but not necessarily the "point of interest", the user adds the "looked at" GPS coordinate in addition. This is the "New" IMatch 2018 part.

Your drone may record its position 10 times per second, but then, a video has not one GPS coordinate but may have hundreds. If you fly a KM while filming, you cover a lot of ground. I'm not aware of any standard schema to manage this massive amount of info, or visualize it on a map - except as a track log display. Or maybe you just filmed the same volcano from 600 different perspectives but you want to boil it all down to "images of Vesuvio taken on March 1. 2018"...

[jch2103]

As a geologist studying volcanoes, I take a lot of pictures - thousands. Consider two of my cameras; an eight year old Nikon D5000 and a Mavic Pro drone. The Mavic collects data 10 times a second including GPS latitude, longitude, and altitude, camera azimuth and gymbal pitch, video start and stop, and time of exposure for a dng. The Nikon collects nothing but pixels. I use Geosetter to find its location by synchronizing the internal clock with universal time and combining the image folder with the gpx track from my Garmin.

With that volume of photos, you might want to consider a GPS accessory for your Nikon, such as https://www.amazon.com/Solmeta-Geotagger-N3-c-Receiver-Shutter/dp/B00P3S5BKS/ref=sr_1_14?ie=UTF8&qid=1525042671&sr=8-14&keywords=nikon+gps+accessory (I have a similar unit but haven't tried this one; sounds like this one includes an electronic compass). Because units like this directly add EXIF location data to the camera image, they can greatly simplify workflow.

[pmbvw]

Of course if image direction is specified, IMatch will use it to set the initial FOV direction and also as a guide for creating the destination. Else IMatch will assume 0°.

I have around 80.000 pics made by my Canon 5D MK3 with GPS-data and the field image direction.

For me it would be a great addition to the map, if I only can see the image direction per line.
FOV would be wonderful, but more a nice to have.

[Mario]

The FOV can be displayed by only knowing the crop factor and the image direction (if available in the metadata).
The "looked at" point requires manual input from the user, in form of defining a destination GPS coordinate. This then also automatically defines the image direction.

[Aubrey]

FOV direction concerns me...
The GPS can only give direction based on the position of the last 2 points, unless it has a built in electronic compass.

If you reach a location and then turn around 180 degrees, I suspect that the image will consider the original direction. A lot will depend upon the sampling rate and accuracy of the GPS used. I have never found GPS orientation very good.
Note the Garmin Etrex  20 has no built in compass (I use this unit) I also use my mobile phone with app GPS logger, but this chews the battery.
The Etrex 30 also has a built in compass

Aubrey.

[Mario]

Nothing to be concerned about.
There is only so much a software can do. When the image direction in your file reads 90°, IMatch cannot know if you would consider this correct or not.

This is why you can define a destination coordinate ("looked at") and hence you have full manual control. IMatch will use the line between the location and dest coordinate pairs as the angle for the FOV and also update the image direction metadata tag from that.

Not many cameras write an image direction anyway. This means that the FOV assumes 0° (points towards N) unless you define a destination point. And displaying the FOV is optional. If you don't display the FOV and you don't set destination coordinates, everything in the Map Panel will look and work as before.

Things like destination coordinates or FOVs are relevant for a minority of users. Most users are perfectly fine with one pair of coordinates.