-
-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User mosaic stitching problem #129
Comments
Can you provide the TMS for some of the constituent scenes? I was fairly certain that I'd finally addressed the black edges, so I'd like to take a closer look at the images that are causing problems. The sort order + geometry intersections are limitations imposed by the combination of MongoDB (which doesn't have the depth of spatial capabilities that PostGIS does; we're prototyping an updated version of that API that's PostGIS-backed) and w8r/martinez#85, which leads to fairly regular crashes, enough so that we should avoid using it too heavily (it's the module used by Short response: I should be able to fix the black edges relatively soon, but the mechanism for selecting source images will need to wait a bit longer until we have PostGIS capabilities and/or the ability to allow users to define their own groups of sources. |
All of my imagery is uploaded here, take any: |
When no alpha channel is available and NODATA values are present (as mask_flags), use gdalwarp to create an artificial one in order to prevent NODATA values from being subject to [JPEG] compression artifacts. Refs hotosm/OpenAerialMap#129
Thanks for helping me get to the bottom of this. I've been focusing on mask behavior a lot, but missed how to approach a certain class of images: RGB images with no alpha channel or mask containing NODATA values (these are pretty common, especially from tools that don't create alpha channels; internal masks are uncommon). The NODATA values flow through and are treated as transparent, but the process of JPEG compressing the source imagery introduces artifacts where neighboring pixels may no longer match the NODATA value (which can be partially eliminated using There's nothing simple we can do to imagery that's already been uploaded, as the JPEG compression artifacts will have already been introduced, but new imagery uploaded from now on will have compression-friendly masks included. (DigitalGlobe images were affected by this, so this will be a nice change for large areas that those scenes cover.) Do you mind re-uploading a couple of your source images to make sure that the problem goes away? |
Overview is now with black background instead of transparent: On tiles, there are still compression artifacts, but hurray no black edges: A way to fight these artifacts is to fill black under mask with average color of not-NODATA pixels/ :) |
I have a pretty good idea of how to re-introduce proper transparency with the thumbnails...
I'm inclined to accept the remaining compression artifacts as the cost of ~10x savings on storage.
I'd love a hand if you're able to prototype an approach to this. A simpler (for consumers), more fundamental fix is for whatever toolchain you're using to produce actual [alpha] masks instead of just tagging NODATA values. That'll prevent black pixels in the middle of the image from being treated as transparent.
scratches head This doesn't make any sense yet (esp. with the black edges gone elsewhere), but I'll be taking a closer look. |
The black edges should be fixed now (for newer data). Transparent pixels in the middle of images should also no longer occur after mojodna/marblecutter@7520375. Thumbnail transparency has also been reintroduced. |
Trying to look at mosaic of all my imagery,
tms:http://tiles.openaerialmap.org/user/5a02e4c331eff4000c380594/{z}/{x}/{y}@2x
The text was updated successfully, but these errors were encountered: