Closed smit1678 closed 6 years ago
My main concern here is losing details. Here's the stairs that looks like a flat road due to compression artifacts: We were taking photos of this bridge because it's planned as a cycling bridge, and the stairs on it is a planning issue - and making it invisible doesn't help much :)
Thanks pointing out the specific features you're looking at @Komzpa.
on this image the edges of building are lost: https://map.openaerialmap.org/#/27.65861213207245,53.871152187265395,18/1203003112123/5995a63a46e19904aab0a93a?_k=xsa2vc
This may be fixable on the OAM browser side by making loading retina tiles where appropriate. This is what it looks like when viewing the raw preview:
Here's the bridge @ 2x: https://tiles.openaerialmap.org/598c1938a260c700113db249/0/03610f03-adb4-4fa7-bd21-bf68f46694f7/preview#21/53.86058/27.58144
The underlying compression artifacts come from using JPEG compression to reduce the size of the images. Perhaps we want to increase the quality for newly-uploaded sources.
@Komzpa can you put the original GeoTIFF for either of these sources online?
@mojodna here's the one with the bridge: https://www.dropbox.com/s/ztp7xbpexx8zl6p/Loshitsa-Bridge-noskew-3_transparent_mosaic_group1.tif?dl=0
here it is in Pix4D web ui for reference: https://cloud.pix4d.com/pro/project/156049?shareToken=8b37ed3f74c9430589523b40ae9ed03e
Thanks!
Now (ish):
Soon (with the same imagery; forget what I said about JPEG compression):
Looks good! What was the issue with?
Here's the change that fixed it:
https://github.com/mojodna/marblecutter/commit/714557bf8d8a577621fd401130d77b4ed9a61ded
The tiler reads tile-sized windows out of a warped VRT (so the source can remain in its original projection). The current tiler (this repo, which forms the basis for marblecutter) simplified the math by creating a warped VRT with dimensions matching world pixels at a zoom that approximately matched the resolution of the source image. This meant that the windows would be pixel offsets at a target zoom. This only works to zoom 22 (the approximate resolution of the source image, not the tile being rendered), as after that point the width/height of the VRT exceeds INT_MAX
.
This change disabled the web mercator-specific size calculation (now that rasterio supports floating point windows), so it now reads the image at full-resolution, rather than scaling the overviews, resulting in the artifacts.
Because marblecutter is also used to render DEMs, stairstepping needs to be prevented (to avoid ugly/wrong hillshades; the image below should be smooth). Matching the window size to the tile size (when outputting in web mercator) seemed to be the best way to deal with this, but I'm still investigating alternatives.
tl;dr: the source resolution was higher (> z22) than the windowing approach was equipped to handle.
Hi! Any ideas on when it is going to get deployed? New uploads are still better in preview than in tiles.
This week. There were a few things remaining to reach parity with some features from the previous tiler.
Here's the potential production endpoint (pending DNS, etc.):
Hello, The issue persists.
We haven't deployed the new tiler yet, as I want to get https://github.com/mojodna/marblecutter/issues/78 fixed beforehand (working on them now).
@Komzpa Quick update. @mojodna Deployed the new tiler and we have it hooked up. 👌
Going to close this out for now.
Flagged by a user: the clarity of the tiles from the TMS differ greatly from the geotiff.
Imager on OAM: https://map.openaerialmap.org/#/27.580876350402832,53.92062983258095,15/1203003112013/5975f18046e19904aab0a911?resolution=high&_k=rvo4fo.
This isn't the perfect comparison as I couldn't get the zoom levels to match plus its hard to see on this small version. Larger version here.
Looking at the geotiff closer and it looks like there are some stitching/processing artifacts. So not sure if this has an effect.