Impressive improvement! Tnx
Actually, there are two sprite sheets. One for the UI and one for the map layer.
The UI sprite sheet has proper max-age=604800. But, its size is 3.01 MB. Perhaps this one is too big either?
Plus, note that many mobile GPUs have a GL_MAX_TEXTURE_SIZE == 2048 limit, which can lead to out of bounds texture coordinates and display errors on this 3,264 px wide sprite sheet. Hence, going for a square shape may be a solution here.
Then there is the map layer sprite sheet (mapillary_sprites.json and mapillary_sprites.png)
The PNG has been nicely reduced to 1,647,652 bytes. However, these sheet files continue to have max-age=900.
Overall, perhaps you may want to settle for one sheet file, although I am aware that they serve different purposes. Additionally, perhaps making them more square shaped would help to decrease their size?
Sometimes, the sheet files do not download completely on slow connections and there is no way to reāinitiate this download again in the UI, e.g. clearing and selecting āAll traffic signsā again has no effect. Your only hope then becomes refreshing the page.
2 Likes
Weāve updated the cookie page in the web app to simply use a color background which reduces it total download size of the page by more than half. As the color matches the loading background of the web app the transition should hopefully seem much smoother now. 
Weāre also working on sprite sheet improvements. The sprite sheet is used in three places (map, UI dropdowns and the image viewer) so weāre thinking about how best to consolidate them.
1 Like
Trying to go via the browser address bar to any image directly (using the pKey URI query) or by clicking on a dot or an image in the feed continues not to work on a slow connection.
Thanks to all persons involved. Wow, how fast it is now.
2 Likes
Nice!
However, I would also like to see the satellite/aerial imagery hybrid map layer return to the Mapillary web app, although I am aware that such a layer may demand a quite expensive fee.
By the way, you may want to center align the text below the images in this menu. 
Once you realize that the text is oddly left aligned, you kind of cannot unsee 
that something is off. 
1 Like
This post is not about bandwidth/storage space directly but more about image quality on the Mapillary web app, though quality and storage space influence each other. So, I was wondering why the images on Mapillary look noticeably worse than on my local machine. One simple reason is that the web app serves 4:2:0 chroma subāsampled images everywhere. Quality wise, ideally you would want to serve 4:4:4 images with a 100% compression ratio after blur processing. But, this is not ideal for running a website.
Imho any chroma sub-sampling format other than 4:4:4 should not be used for still image photography, which is basically what Mapillary serves (independent of the mode the original imagery has been captured in). Hence, I would like to see Mapillary serve 4:4:4 chroma subāsampling format images only and balance bandwidth, throughput, and load modifying the compression ratio only (because Mapillary applies blurs, thus modifies images). Or, use the original imageryās chroma subāsampling format (often also 4:2:2) and do any kind of balancing using the compression ratio only.
Yes, chroma subāsampling formats do heavily impact storage space and can help reduce bandwidth requirements but they are really ill suited for still image photography. They sort of work okay for video because video displays many frames in short timely succession where any lacking color data in one frame can be delivered by subsequent frames. This is not the case with still image photography. You basically have to put all color data in one, and only one, frame. 
Hence, I strongly plead you to only serve 4:4:4 chroma format imagery, especially given the fact that you do blur processing.