Honestly speaking, I’ve had zero issues with interpolate_directions in mapillary_tools
Was working fine since I’ve joined the community and started with contributions (0.5.0-0.6.0-0.7.0)
Maybe there is some specific scenario/use case causing issues (i.e. 360 pano processing), but in my my normal imagery - interpolation with tools is working like a sharm.
In my current understanding a GoPro Hero 8 Black does not include directions in its metadata. No 360 images possible. Therefore I always included interpolation in my CLI command:
mapillary_tools process_and_upload --import_path "LOCALPATH_HERE" --user_name macsico --number_threads 10 --advanced --duplicate_distance 0.5 --duplicate_angle 1 --interpolate_directions
But whenever I checked the results (after being processed) on the Mapillary map, images had wrong directions towards its successor and I ordered the system to correct this. I also found coverage of another (heavy) uploader here in Berlin which showed the same issues with his GoPro uploads. Did I miss something in my processing?
This is a correct logic of direction interpolation. Each inage in the normalized sequence should be pointing at the next one (successor)
If you are shooting to the sides (left, right, back) , you need to add appropriate offset angle option as well.
Ps
I am also adding
--overwrite_EXIF_direction_tag flag
I have ended up with reuploading these sequences again , processing took circa 1.5 days but now they are all visible in the new webapp.
Not sure if the ‘lost’ part from v3 will show up later as duplicate…
99,9% of my images share the same direction as my movement which is headed forward. Interpolation should have been no problem - but this war never true for mapillary_tools 0.5.0 in my very own experience.
Thanks to your mentioning I discovered one single track being shot to the right as a test. And I forgot to change the angle after uploading last year - now it’s impossible to correct.
Tried you hint regarding the overwrite flag - applied it today to ca. 7,000 new images uploaded with mapillary_tools 0.7.0. Thumbs up that it will work this time as expected.
And for all the people who might wonder what has changed that I was able to upload images despite my total Facebook blocking in my home router … I just changed important parts of my process.
Here is how it worked for me:
perform quality check like always: opened all images in GPSprune to check it OSM path ist more or less matched. Compared to planned route by importing prepared guiding GPX file. Deleted files if too far away from path as creating new images is easier, at least in my own area here.
transfer all images to my webspace (shared hoster): uploaded from a local folder of my desktop computer to a remote directory using SFTP. In fact RCLONE was used as I already use it as a single frontend towards a bunch of online storage providers. Took a few hours with my 50/10 broadband provider with full image size possible from a GoPro Hero 8.
run CLI upload via SSH remotely: as my plan allows me to install mapillary_tools by using the pip3 command provided at the Github page, I can use the CLI version remotely and process the upload from step 2. The server is running Ubuntu 18.04.
Nice side effect: the server has way more CPU power and bandwidth than my local machine, therefore pure processing time has dramatically decreased.
What are the advantages of this solution?
And by using the Opera browser, the built-in VPN allows me to tunnel my broadband router’s filtering to access the Mapillary map webpage. Slower than direct connections, but still usable. As Firefox, Brave and Vivaldi are my main browsers, Opera is only used for from time to time to access blocked domains and nothing else.
Results:
Hopefully this explanations helps others to find their way of dealing with the new situation.
After days, I’m still waiting for my reset email. Not found in spam folder.
Thanks @GITNE for your wonderful compilation of a lot of points being mentioned in this thread so far.
And I agree with you how to not deal with my feature request. Wherever possible you should design once in an intelligent manner and deploy it in as many use cases as possible.
But this does not necessary mean that two totally independent processes or products should be created if we want to stay with my example. Put everything together in a single software in a way being both powerful for experts and operable by simple users is the way to go. Allows also to maintain costs and customer satisfaction at the same time.
Let’s check examples of software (UI examples) which supports me to grow with my needs and my understanding of complex possibilities.
VideoLAN VLC: I can just double click any audio or video file and its content is played. And if I want to change aspects of its default behavior I open the settings and change it. And if I really want to tweak a lot of details in the settings I just click on “Show all”. Hello expert mode!
AVM Fritzbox 7490, my broadband DSL router (and phone system) and a multifunction monster: a million gazillion features is well hidden in each subsection until you click the toggle next to the menu entry “Advanced View”. The standard view is enough to get the box up and running and does not exclude new users. The expert user is able to create wonderful new
Mozilla Firefox: we all love the “about:config” entries whenever Mozilla foundation released a new version intentionally changing some very important aspect for a lot of people. The warning after entering it in the URL box is a good blocker im my eyes.
Conclusion:
build your software with all necessary core functions and do no create a stripped down version.
create a user interface showing base functionality a first start which allows to be successful.
include expert mode button at a not so obvious position to stop your customer service being flooded by “I saw this ‘Expert’ button and clicked it - now I am lost!” calls/contacts/emails.
I am aware that my examples covered only matured software. But being a startup should not always being used as an apology to deliver substandard software.
In the old app the pictures were stored in /storage/emulated/0/Android/data/app.mapillary. What is the storage location in the new app?
I thought the new updates would improve stuff …
Well it looks like I’ll come back in a few months time … I’ve just uploaded some 360° images that processed and displayed fine on the old mapillary platform as viewable 360°s but my new uploads are just coming out as flat images… Of course now I can’t delete the sequence … 
CORRECTION: I’ve just re-visited some uploaded sequences and while it first appeared to show ONLY the first shot as a flat image , it seems that the processor might be going back and re-reading the panoramic exifinfo - Note to self - wait longer 
Mapillary’s move to remove the Web Uploader really puzzles me. It worked really well, intuitively by drag and drop, with useful visualization of the process. This was a great platform independent way to quickly upload some pictures that where georeferenced and enhanced with direction data.
Though really looking forward to see the underlying pointcloud data, I really expected for Mapillary to improve, especially in UX. But now we’re stuck with less functionality. This is really a drawback.
And having to install binaries (not for Linux users as me anyway) provided by Facebook is not helping to earn trust by contributors who are already weary of this whole takeover this company.
What I’d love to see is the possibility to perform client-side blurring before upload.
I have a strong belief that there is some untold, behind the scenes battle going on, and that it’s not being easy for anyone in the team, so regardless of what you can achieve internally, thank you for your great work so far.
But now we’re stuck with less functionality.
Yea, its sad. No way to easily upload images in webbrowser. No way to normalize heading of my own and others (yes, I did edit a lot of sequences of others, not possible anymore). No way to change offset of heading for my 360 pictures. No way to correct gps positions after upload (when position was disturbed by high buildings). Less functionality than 4 years ago
As login data is saved on the webspace, a public webspace should not be used in my understanding to prevent third party misuse.
To get an effort free process I am still considering using a server side crontab entry (at shared hosting) to let mapillary_tools run every day short after midnight (00:05) to process all uploads from the last 24 hours. A second crontab entry around 06:00 then should delete all uploaded content from the upload folder to free space.
This would allow to just upload the images from my local machine to the remote folder - and then only wait for the results to appear on the Mapillary map. If no uploads were ready to process both cron jobs would just create an error message with no effect on future processing. It would free me from waiting for the upload to complete and have to start the remote job manually.
Any errors in my plan?
Also, it does not look like Mapillary actually following the image direction and/or altitude embedded in the 360 images now. I’ve spent a good few hours lately setting directions and altitude in a 15k-worth 360 sequences, made a test submit of a few of them and ended up with messed up headings and broken transitions. Have no clue how to fix that, guess will have to wait a few months before things will be sorted out.
We’ll need to debug this. Please email support@.mapillary.zendesk.com if you haven’t already.
I sent an email at the corresponding address but got an error:
Hi. This is the qmail-send program at xxx.xxx.fr.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.
<[support@zendesk.mapillary.com](mailto:support@zendesk.mapillary.com)>:
212.27.48.4 does not like recipient.
Remote host said: 550 5.1.2 <[support@zendesk.mapillary.com](mailto:support@zendesk.mapillary.com)>: Recipient address rejected: Domain not found
Giving up on 212.27.48.4.
STARTTLS proto=TLSv1.2; cipher=ECDHE-RSA-AES256-GCM-SHA384; subject=/CN=*.free.fr; issuer=/C=US/O=DigiCert Inc/OU=[www.digicert.com/CN=RapidSSL](http://www.digicert.com/CN=RapidSSL) RSA CA 2018;Damn. Lost 2 huge sequences as well with the iOS uploader. I guess they are lost
I still yet have to hear from support, but from my view they look gone.
Think I’m going to take a break again from uploading images. Not fun to loose 1/6 sequences 
My apologies. The correct email is support@mapillary.zendesk.com
As mentioned in another thread, the photos in new app are “hidden” in system folder requiring rooted device.
So I stopped capturing images…
@eneerhut , is this a final solution for storage? That people have no direct access to pictures before upload.
Any luck with the desktop uploader recently?