Mapillary Desktop Uploader 4.7.0

Mapillary Desktop Uploader 4.7.0

A new update for the Mapillary Desktop Uploader is out now. You can download it from https://www.mapillary.com/desktop-uploader and your installed apps should also automatically update to the new version.

This update includes:

  • New satellite basemap has been added to the options on the map.
  • Redesigned map view with new features like the options to toggle editing and redo edits
  • Includes the latest Mapillary tools which bring new improvements.(Releases · mapillary/mapillary_tools · GitHub) like increasing the maximum upload size to 110GB, upload speed improvements and synchronization between GPX and video timestamps.
5 Likes

Works great :). One thing I don’t understand, why my dashcam video’s are perfectly read and uploaded by the desktop Uploader, but when I try it in Mapillary tools it gives an error that the GPS data is not found. Anyone knows why?

1 Like

Hi @TheWizard - glad to hear the Desktop Uploader is working well for you! Most likely the reason the videos “just work” with the uploader and not mapillary_tools is that the uploader uses exiftool under the hood when native processing fails. You can also manually set mapillary_tools to do the same with the exiftool_runtime command. cc: @tao

2 Likes

Hi @boris,

Thanks for the info! I processed a couple of test videos:

That’s working fine, but I want the extra process options, but that’s not possible unfortunately… Is there an option to use process? It’s failing because of the empty GPS info, but that info is in the json file, but it’s not using that option.

cc: @tao for this question

1 Like

Do you mean to pass some extra options to exiftool? There is not possible now. Let me what options would you like to pass in, we may support that if it’s common case.

Dear @nikola , dear @boris ,

That’s be great news - at least if you mean to say that the .exe , on W10, will now actually activate the User Access Control pop-up, then show various other user interaction screens - just like when installing say LibreOffice, or XnViewMP, please?

Because on my 64-bit W10 computer those programs do things like ask for UAC and give at least some customisation options, Mapillary desktop Uploader v4.7 (like v4.6 before it) does nothing of the kind : the green install bar starts, halts somewhere, begins again at some random point, continues to almost the end of the box, starts again, and once again doesn’t complete.

Eventually the Desktop Uploader screen appears, but there is no entry in Windows’ list of programs, not even under ‘new software’; using the magnifying glass brings up an entry ‘mapillary uploader 4.7’, clicking that re-runs the installer.

Also sorely missed is an icon like the ones for ‘normal’ software - like the already mentioned LibreOffice or XnViewMP, which I can click to just start the program, rather than re-running the installer?

Hence looking forward to v4.8 where the installation process follows the well-known path of other installers on W10.

Met overigens als immer vriendelijke groet, (Dutch for ‘with otherwise -as ever- friendly greeting’)

The --video_sample_distance is an option I love the experiment with, also when processing the video (to images) it’s faster processed on the server.

@TheWizard we just released the latest alpha version v0.14.0a1 which also added this “just works” support: it runs native parsing first and then run exiftool by default. Would you mind trying it out and let us know if it works?

NOTE: you have to have exfitool installed in your PATH, or somewhere specified by envvar MAPILLARY_TOOLS_EXIFTOOL_PATH.

❯ uv tool run --pre mapillary_tools --version         
mapillary_tools version 0.14.0a1

❯ uv tool run --pre mapillary_tools process_and_upload --skip_process_errors ~/Downloads/MyGoProImages --dry_run

If not, sharing some sample videos would be great.

1 Like

Hi @tao, I tried the alpha version, but no luck with the GPS extraction, see screenshot.

I’ve uploaded a small test video with GPS data:

Thanks for the sample.

The local processing command (sample_video or video_process) only supports native parsing (i.e. CAMM or GoPro).

The process command, however, works for me (Make sure you have exiftool installed first. If not, you will see a warning):

❯ uv tool run --pre mapillary_tools --verbose process ~/Downloads/TheWizard

2025-04-02 18:03:22,806 - INFO    -        1 video(s) read in total
2025-04-02 18:03:22,806 - INFO    - 	        1 video(s) (84.0 MB) are ready to be uploaded
1 Like

Hi @tao, I think there is a little miscommunication :slight_smile: , I tried with the extra command --video_sample_distance but that’s not working in combination with the exiftool I think. Process and upload is working fine.

Unfortunately, in edit mode, moving images still takes ~3 seconds per image on a fast PC, so it’s not really practical for non-trivial uploads. The edit toggle is appreciated, however, to avoid accidents.

All edits also get lost if the upload fails and one attempts a retry. (Since the edits don’t get saved anywhere, I am not at all sure why it actually takes so long to “edit” them then?)

@nikola - do you have thoughts on this?

We could find a way to preserve the upload state including the edits in upload history to make it easy to retry so we’ll look into it.

We’re also making updates to reduce the number of failures that would hopefully make them very rare.

How many images are usually on the map when you experience that moving them is slow?

30-40K is when it’s unusably slow. At 5K it starts being annoying (given that you cannot grab the next image (it causes the map to pan) before previous one has been placed). But you can notice this with as few as 1K images.

This is with 8k images:
mplry edit

Spamming undo button quickly often results in buggy behaviour where some random images do not get their moves undone.

For example, here I moved a bunch of images and then quickly pressed undo a bunch. Yet one of the images remains.

mplry unundoed

Neither further undo nor redo affect the image.

Both undo and redo buttons can end up being both enabled and disabled after spamming them regardless that there are no actions on the stack.

I have also previously crashed the entire app last time (when edit was first added) I was messing with undo/redo but with way more images. I’ve also had all the loaded images disappear after undoing many steps.

Great feedback! We’ll update the undo and redo buttons to make sure the operations are performed in order and wait until the changes are applied before proceeding.

Performance with that many images might be difficult to improve, particularly as the main limitation will be rendering in maplibre which is not something we could change unless we come up a way to show less data on the map like by maybe toggling individual sequences to choose which one could be visible and edited. We’ll look into it.

Hey, did you change something on the video processing side? Because it doesn’t seem to be spaced out even anymore.

Im waiting for possibility to delete group of photos. Like when you doing timelapse and stop on a streetlight. Generally there should be option to select many photos (ctrl+click or with bounding box) and perform actions on them like move or delete. Very needed.

It would be great also to have automatic delete if photos are closer than X meters (im using it with mapillary command tools).