You can see all kinds of blockiness, and most importantly, signs and objects are way less visible than in the original photo.
It’s not even like the original photos are heavy, they’re around 3.2MB each, which is not that much (my phone takes 2MB photos). Maybe this is due to the Mapillary app, maybe Mapillary servers freak out with GoPro pictures, maybe they downscale the image. The fact is, the pictures are sometimes bad quality in Mapillary than in the original, which is a shame because the main point of Mapillary, among others, is to read signs, and they are way less readable when Mapillary compresses it than what is originally given to it
I believe it would be great, at least for 360 photos, to either use a better compression format (like WebP, MozJPEG or even at best, AVIF) because by the looks of it, it seems like JPEG is used currently, which is an outdated format, or either make the files bigger in Mapillary servers (which is owned by Meta, meaning that they should have great servers)
Edit : The blockiness/bad quality is better appreciated here
Hi there @TheWonderfulTartifle - would you mind posting a link to the original image on something like Google Drive (where its not compressed) to compare that with a Mapillary link? That will make it easier to compare side by side.
Thank you @TheWonderfulTartifle - I took a look at the original and compared it to how its displayed on Mapillary. The compression is evident in some areas like the handicapped markings on the parking spots, but overall it looked fairly good to me. I couldn’t find any text that was readable in in the original but not in the Mapillary version.
We may look at switching formats to something like AVIF (great idea!), but I’m not currently seeing a major difference in this example.
Good question. Mapillary imagery is widely used by all sorts of clients across many operating systems (web, iOS, Android, Linux) and many software platforms (OSM editors, end-user apps like OSMAnd, mapping tools like ESRI, JOSM, etc) and other use cases through the API. I think its unlikely that we would fully switch to AVIF until/if it becomes a widely supported standard across all of these.
Rather than JPEG2000 Mapillary should store as JPEG XL, which can be lossessly converted to and from JPEG but can be stored with much better lossless compression. It’s also open-licensed while HEIF is not. AVIF isn’t really optimized for still images, and the existing JPEG images on the servers would have to be lossy-converted to that format. Converting all existing images to JPEG XL would save space on the server.
