Sequence lines connect wrong images showing strange pattern

Imagery, data, and integrations
1

Checked other forum postings with sequence order issues, but none of them seems similar. As editing a sequence is currently not possible after uploading, the errors cannot be resolved by the user.

Describe the problem you’re having:

Sequence lines connect wrong images and show a strange pattern

If possible include steps to reproduce the problem:

  • open affected sequence in Mapillary web app
  • press play button at the top
  • view each image being shown

Expected behaviour:

  • each successor should be very next to its predecessor as latitude and longitude should differ only minimal
  • morphing effect should show smooth transition along the path used during capturing
  • see image focus indicator go from one image to the next image on background map being connected by short lines

Observed behaviour:

  • starting at a random point, the connection to a successor does not point to its near neighbour but to a single image which is 59 positions forward.
  • therefore the play function jumps forward by 59 positions and then immediately back to the next image in the original order.
  • at the position 59 images forward the expected connection between neighbours in order itself is missing as the image connection itself has been shifted again 59 positions forward. This connection shift by 59 positions it present multiple times in the affected sequence.
  • image focues indicator on the map jumps back and forth around affected image order error

Used hardware and software:

  • GoPro Hero 8 Black with time lapse setting of 1 image per second
  • mapillary_tools 0.7.0 running on Ubuntu server 18.04
  • used command: mapillary_tools process_and_upload --import_path "PATH_TO_IMAGES" --user_name macsico --number_threads 10 --advanced --duplicate_distance 0.5 --duplicate_angle 1 --interpolate_directions --overwrite_EXIF_direction_tag

Please provide any additional information below:

  • affected sequence starts here: Mapillary (Image key: 238189834426307)
  • affected sequence is part of a longer walk in a park with other sequences not being affected. But it has been uploaded later as the rest due to some circumstances at my side

Thanks for your time and your support in advance.

2

More and more of my sequences are affected, which have been uploaded after my posting here. So, it’s still broken and no solution has been offered so far.

As I only use Mapillary software (CLI: Mapillary_tools) and upload my images to a Mapillary server, it’s very likely that it is a Mapillary error.

What else did I find out since this posting has been created?

  • unprofessional email support: As no reaction at all to this posting happened within 10 calendar days (5 business days), I decided to sent the whole posting as an email to the official support email address.
    To my surprise, the Zendesk system (identifiable in the email address) did not send an autoresponder message that my email has arrived and will be dealt within a suitable timeframe. And no answer has arrived so far. I didn’t expect a quick response - but no automatic response at all is far below industry standard when running a support email system with Zendesk.

  • image upload in forum denied: today I wanted to allow a better understanding of the error pattern and tried to upload a map screenshot into this posting.
    I already read in other postings that this was denied by the system. When I tried it by myself, the upload dialog appeared, let me select a file and allowed me to click OK to upload. And only NOW the “Access denied” error message appeared.
    Guys and girls, this is crap. Offering a function and then block it at the very end of the process is bad software design. I have no problem with both: deny it at all and let us know from the very beginning - or allow it for all registered users.
    But do not let the system give us a half baked answer.

Conclusion: no software fix, no answer, no notification, at least for this issue. My other issue with GoPro videos got very fast answers during the first few days.

What does this tell us about the current state of Mapillary as a company and a user content driven enterprise? I have no idea.

1 Like
3

Have seen similar with the GoPro Hero9, using the then latest firmware. See Mapillary for a couple of time-line spikes; curious : the spikes didn’t occur earlier in the sequence, nor did they show in the next sequence at @@ , but do show at Mapillary, which was taken ten days earlier. Don’t have the originals anymore, but same occurs on 4 June at Mapillary (note to self : my pic G0023697.jpg taken @14u30) Now follows a bunch of times which would best fit in a table - no visible way to add one?.

For this geographically correctly placed pic which is however in the wrong spot time-wise, using the exiftool plug-in in XnViewMP :
From the FILE section : File Modification Date/Time 2021:06:04 14:30:00+02:00
From the EXIF section : Modify Date 2021:06:04 14:30:00
From the EXIF section : Create Date 2021:06:04 14:30:00
From the EXIF section : Sub Sec Time / Sub Sec Original / Sub Sec Digitized 2340
From the EXIF section : GPS Time Stamp 12:30:24
From the Composite section : Create Date / Date/Time Original / Modify Date : 2021:06:04 14:30:00.2340

For the previous pic on the green line - which is also at the correct spot - but was taken 61 secs earlier : Mapillary , my ref : File Name G0023636.jpg
File Modification Date/Time 2021:06:04 14:29:59+02:00
Modify Date 2021:06:04 14:29:59
Create Date 2021:06:04 14:29:59
Sub Sec Time 2340
GPS Time Stamp 12:29:23
Create Date 2021:06:04 14:29:59.2340

For the previous pic on the cycleway - which is also in the correct spot geographically - and was taken 1 sec earlier :
Mapillary , my ref : File Name G0023696.jpg
File Modification Date/Time 2021:06:04 14:30:59+02:00 NOTE : that’s interesting …
Modify Date 2021:06:04 14:30:59
Create Date 2021:06:04 14:30:59
Sub Sec Time 2340
GPS Time Stamp 12:30:23
Create Date 2021:06:04 14:30:59.2340

Short story long : three pics in the correct spot geographically, but a ‘spike’ in the time-line occurs occasionally, may ‘cure’ itself inside a sequence (i.e. w/o switching off) The spike pic is at the jump in the minute-counter.

= = = =

Edit approx. half an hour later :

Mapillary (my ref : G0021417.jpg )is in the correct spot geographically, and it doesn’t form a ‘time-spike’, yet does have the ‘minute jump’ in its time-stamp.
File Modification Date/Time 2021:06:04 13:53:00+02:00
Modify Date 2021:06:04 13:53:00
Create Date 2021:06:04 13:53:00
Sub Sec Time 2220
GPS Time Stamp 11:52:24
Create Date 2021:06:04 13:53:00.2220

And the one immediately before it - both time-wise and geographically :
Mapillary my ref : G0021416.jpg
File Modification Date/Time 2021:06:04 13:52:59+02:00
Modify Date 2021:06:04 13:52:59
Create Date 2021:06:04 13:52:59
Sub Sec Time 2220
GPS Time Stamp 11:52:23
GPS Date/Time 2021:06:04 11:52:23Z
Create Date 2021:06:04 13:52:59.2220

Short story long : the spike doesn’t cure itself, it occurs spontaneously at some point in the sequence.

@chrisbeddow @Anders : hope one you know who’d be able to make something of this? Always happy to look at other pics, but this seems to sum up my experience.

Met vriendelijke groet (Dutch for ‘with friendly greeting’),

4

Hey, if possible, could you send the original video to “support at mapillary.zendesk.com” for us to investigate?

5

Also please try the lates tools here Release v0.7.3 · mapillary/mapillary_tools · GitHub

6

Dear Tao,

Sent nine pics plus small spreadsheet via wetransfer, will be there for 7 days.

As follows : 3 in the area where there wasn’t a ‘spike’ on the green line, and twice 3 where there was a spike.

‘my file name’ and ‘mapillary reference’ in the spreadsheet should take the guessing out of locating what goes where; in the right-most column you’ll find my note on file time and GPS time (differences).

Hope helps, if not please advise.

1 Like
7

@tao : haven’t seen the WeTransfer ‘files downloaded’ mail at 24hrs after sending : may I remind that files will now disappear in 9just under) 6 days’ time?
@Anders : just in case Tao is off : the link was addressed to support@mapillary.zendesk.com , received my confirmation mail at 12:34, couldn’t work out which reference to add -except ‘Dear Tao’- : would you need anything else, please?
Met vriendelijke groet,

8

Thanks! They have been received and shared with Tao. I didn’t see any WeTransfer of spreadsheet though. Was the subject line ‘Examples of images for Tao’?

9

Since my image sequences are only saved for a few days after uploading, I can’t check for erroneous timestamps in the EXIF GPS tags of the affected sequence mentioned in the first entry of this thread.

Additional information:

  • all my images are captured as timelapse images with 1 image/second, not as video. So, as it happens after 59 images, it seems that the error happens after one minute of captured images and then repeats.
  • according to EXIFTOOL my GoPro images carry the FirmwareVersion “HD8.01.02.50.00”
  • another sequence affected: sequence key jVaOSF3y5t8cBpT0qGXdlP (short sequence). The very next sequence (ODYKNcSQyoGhWr81epkg9q) does not show this behaviour but was shot after a few minutes of resting.
10

Dear @eneerhut , copy @tao
Thank you for the response. Haven’t seen the ‘files downloaded’ message yet on Saturday morning, hence they likely weren’t ?
My message started : "Dear Tao, Herewith seven pics, and a small spreadsheet comparing camera clock and GPS time … " ;
There were ten files in all: spreadsheet : mapillary 210604.ods , then nine (I clearly can’t count) pics : .jps G0021416 / 17 / 18 , G0023636 / 37 / 38 and G0023696 / 97 and 98.
Best,

11

v.2.50 is the latest firmware according to the GoPro website this morning.

Adding to my earlier replies :
The good news is that the exif GPS Date/Time entry is correct ; it is in incrementing the file time minute value where things go wrong, hence one could correct the file modify / create time by applying the recorded GPS time …

@tao : to summarise the spreadsheet : pic …636 pKey=4691033337592986 @ 14:29:59 / GPS 12:20:23Z , pic …637 pKey=320462182995885 @ 14:29:00 / 12:29:24Z , pic … 638 @ 14:30:01 / 12:29:25Z ; but the pic with the ‘correct’ file time (pic … 697 pKey=513967302986567 @ 14:30:00 has GPS time 12:30:24Z ;

knowing the area : the GPS time and filename order is correct, the file time order is incorrect - thus there seems to be an error in the GoPro’s file time incrementing order .
This didn’t occur earlier in the sequence, persisted till stopped time lapse, upon starting next short time lapse didn’t recur …

With best regards,

12

Dear @tao ,
Have installed python 3.9.6 from the python site, and it seems to work when one enters ‘help’;
Have downloaded release 0.7.3, and double clicked it : was stopped by Windows Defender.
Have seen various other ways to install on some github / mapillary read.me page which I can no longer get on screen, Those don’t work.
Have also had a look at Getting started — Introduction to Programming with Python , where once again different ways are given.

Request : please be excruciatingly specific when stating simple instructions , for example, should one run with the run which opens when you press and hold the windows key , then also press the R key? Or should I type "python3 -m pip install --upgrade git+https://github.com/mapillary/mapillary_tools
" in the python 3.9.6 window?

There are just too many possibilities to try all out, eventually - like the proverbial monkey writing one of Shakespeare’s work - stumbling on the correct one.

Looking forward,