Skip to content
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

Open
Komzpa opened this issue Sep 9, 2018 · 8 comments
Open

User mosaic stitching problem #129

Komzpa opened this issue Sep 9, 2018 · 8 comments
Labels
v1 wontfix v1 bugs that will not be prioritized for fix, in favor of v2

Comments

@Komzpa
Copy link

Komzpa commented Sep 9, 2018

Trying to look at mosaic of all my imagery,

  1. black edges everywhere;
  2. different tiles lack different parts of imagery;
  3. sort order is not stable.

tms:http://tiles.openaerialmap.org/user/5a02e4c331eff4000c380594/{z}/{x}/{y}@2x

image

@mojodna
Copy link
Collaborator

mojodna commented Sep 11, 2018

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 @turfjs/intersect). (Imprecise footprints (resulting from vectorization of pixellated masks) may also be responsible for the empty zones.)

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.

@Komzpa
Copy link
Author

Komzpa commented Sep 11, 2018

mojodna added a commit to mojodna/marblecutter-tools that referenced this issue Sep 12, 2018
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
@mojodna
Copy link
Collaborator

mojodna commented Sep 12, 2018

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 nearblack, although there are side-effects). I'd initially written off the artifacts as a different problem, assuming that they were ignored when compressing the image, but that assumption was apparently wrong.

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?

@Komzpa
Copy link
Author

Komzpa commented Sep 12, 2018

Overview is now with black background instead of transparent:
https://oin-hotosm.s3.amazonaws.com/5b98f44d3d79420007c32794/0/5b98f44d3d79420007c32795.png

On tiles, there are still compression artifacts, but hurray no black edges:
image

A way to fight these artifacts is to fill black under mask with average color of not-NODATA pixels/ :)

@Komzpa
Copy link
Author

Komzpa commented Sep 12, 2018

Per-user mosaic is now not even trying into NODATA:
image

@mojodna
Copy link
Collaborator

mojodna commented Sep 12, 2018

Overview is now with black background instead of transparent

I have a pretty good idea of how to re-introduce proper transparency with the thumbnails...

On tiles, there are still compression artifacts, but hurray no black edges:

I'm inclined to accept the remaining compression artifacts as the cost of ~10x savings on storage.

A way to fight these artifacts is to fill black under mask with average color of not-NODATA pixels/ :)

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.

Per-user mosaic is now not even trying into NODATA:

scratches head This doesn't make any sense yet (esp. with the black edges gone elsewhere), but I'll be taking a closer look.

@mojodna
Copy link
Collaborator

mojodna commented Oct 12, 2018

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.

@Komzpa
Copy link
Author

Komzpa commented Oct 12, 2018

Thank you!

Black edges now have a different style:
image
(compare this to first image in thread - they were overlaid there although with black artifact, now only one of them takes the whole tile and the rest of the tile is black)

@cgiovando cgiovando added the v1 wontfix v1 bugs that will not be prioritized for fix, in favor of v2 label Apr 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
v1 wontfix v1 bugs that will not be prioritized for fix, in favor of v2
Projects
None yet
Development

No branches or pull requests

3 participants