difference in time and gps between still and video files in pm6+

[mike999]

With .cr2 files from canon 5d ii it seems the time code for still and video files is an hour different, presumably due to difference between Greenwich mean time and British summer time. This is a bit strange as I always had the camera set to GMT, I don't change it for any timezone or time of year, so not sure where the difference could have arisen.

Second issue which arises with .cr2 files from canon 5d iv is that the still files display the gps coordinates correctly whereas the video files have nonsense coordinates (they might be correct but do not display in lat long). It is interesting that the still and video files both seem to be using the same time coding with this camera so there is not an hour difference.

It could be that neither of these issues have anything to do with PM6+ or on the other hand it could be that PM6+ is reading the data incorrectly.

[Kirk Baker]

Mike,

With .cr2 files from canon 5d ii it seems the time code for still and video files is an hour different, presumably due to difference between Greenwich mean time and British summer time. This is a bit strange as I always had the camera set to GMT, I don't change it for any timezone or time of year, so not sure where the difference could have arisen.

Second issue which arises with .cr2 files from canon 5d iv is that the still files display the gps coordinates correctly whereas the video files have nonsense coordinates (they might be correct but do not display in lat long). It is interesting that the still and video files both seem to be using the same time coding with this camera so there is not an hour difference.

It could be that neither of these issues have anything to do with PM6+ or on the other hand it could be that PM6+ is reading the data incorrectly.

Share the files and we'll investigate.

-Kirk

[mike999]

Seems the reply with the video and still files failed, is there a size limit?  Video file 176mb and still file also very large.

On the time difference, I have checked from different parts of the world as well and it does seem to be related to time changes as those in winter have same timecodes and the ones in summer have the one hour difference. As I mentioned I don't change the time on the camera other than rare slight corrections if the clock is a bit fast or slow to match to gps time.

[Kirk Baker]

Mike,

Seems the reply with the video and still files failed, is there a size limit?  Video file 176mb and still file also very large.

You'll either have to shoot a shorter video, or use a sharing service to get us a link to the file.

-Kirk

[mike999]

Did you get the private message I sent you with the link to the full size files?

[Kirk Baker]

Dennis has the files but has not had time to investigate them.

-Kirk

[mike999]

How are you getting on with this?
The enclosed image may help, it shows a series of shots taken at the same place within a short time of each other with their gps coordinates. As you can see the stills have correct coordinates and the .mov files do not even though the coordinates were all recorded by the same inbuilt gps in the camera.

[dennis]

I will need to look into this in detail before I can give a definitive answer.  Every manufacturer has a different way to store metadata in their movie files.  Canon typically adds TIFF tables as you would see in a still image (JPEG/CR2) for IFD0, Exif, GPS, and maker note.  The maker note is typically where one would find any "world time zone".  This will take some time to unravel.

--dennis

[mike999]

Has there been any progress on these two issues?

[Kirk Baker]

Mike,

Has there been any progress on these two issues?

No, nothing yet.

-Kirk

[dennis]

I have looked into these issues and have some good news.  As far as the times being wrong, without the XMP that is added for xmp:CreateDate, we were only able to rely on the movie header time signature which is GMT (Zulu). So now that I am getting XMP (which looks to be written by Premiere) we are showing the right time zone.  I suspect however that without this Premiere XMP being written, PM is going to initially adopt whatever the local time zone is when first editing these photos (I don't know if the camera is writing out this XMP).  I would need an unmodified MOV file from the camera (5D Mk II).  BTW the 5D Mk IV MOV files include a JPEG thumbnail and this thumbnail includes Exif.  Again the XMP looks to be written by Premiere.  But I think PM gets the timezone correct from the maker note that is in the thumbnail Exif.  If there is no time zone info in the image then if you send me a movie taken at noon in England (according to the camera time), then it will also show that it is taken at noon in Portland, Oregon when I edit in PM (which is a bit impossible).  Ideally PM can find time zone info and adjust accordingly (e.g. 4AM -8:00).

The issue with bad GPS coordinates being much larger was due to misinterpretation of ISO 6709 spec were the values are multiplied by 100 or 10,000 to indicate formatting (e.g. DDMMSS.S).

Both these fixes/improvements will be in the next build.

--dennis

[mike999]

Thanks very much for that.

Do you need any files out of the camera (I have 5d ii and 5d iv) or for any bug fix to be tested?

What happens when I have manually put the correct location into the video file using PM6+ (I have only done this for a small handful out of a large number of .mov files), would this be uncorrected with the bugfix or would it be automatically recognised as correct?

[mike999]

I am sssuming the gps locations will be automatically sorted out for the 5d iv just with the adjustment of where to put the decimal point.

So I then went ahead and added about 100 locations for the .mov files from the 5d ii, these showed up correctly in PM6+ and all looked fine. BUT when I closed the program down and started it up again all except one of the gps locations I had added using PM6+ had vanished. Also a couple of 5d iv that I had manually added had vanished.

It is strange that they showed up in PM6+ correctly and would take me to those locations so the data were clearly stored correctly at some stage but then removed when the program was closed down. Perhaps it stored the data in a cache and when it tried to write it into the .mov file it failed but those same files somehow store other metadata correctly that I have added via PM6+ e.g. the name of the location.  Possibly note that after dealing with gps data I went on to do various other edits to the metadata in these .mov files including modifying some of the information in location and city fields, these edits were saved, then closed the program.

I have now checked again and there are a small handful, about 5, of 5d ii files that do have gps data in them, one of them from today and the others from a few weeks ago when I first tried to put the gps data in.

Clearly there is something very strange going on here.

[dennis]

So the GPS that was written by the camera was written using QuickTime tags not XMP.  This format we were not interpreting correctly and could be off by a factor of 10,000.  This has been fixed.

Any new GPS that is added to a MOV file (or MP4 etc) is done by adding XMP to an XMP sidecar file (we don't update XMP that may exist in a movie file).

Unfortunately the code that handled this particular case was broken and therefore the GPS in XMP didn't "stick" (the coordinates were only held in memory).

I have fixed this bug as well.

NOTE: regular types of updates to XMP (such as IPTC, rating etc) for movie XMP sidecar files were not affected by this GPS-XMP bug and should work fine.

--dennis

[mike999]

Thanks, any idea when the bugfixed version will be released?