I’m using a WebODM docker instance to process drone images on our farm. This is mostly working well, I’m using
fast-orthophoto because I’m not really interested in anything 3d at this point.
I tried using Agisoft Metashape before and was able to create an Gogoel Maps tile-package with that. Comparing these, I see that Metashape seems to scale the tiles much smoother than (Web-)ODM is doing. For comparison, here are two screenshots from the same dataset, the first processed using WebODM and being viewed in the embedded map viewer, and the other processed using Metashape and exported to a Google Maps pack:
It looks to me that (Web-)ODM is using nearest-neighbor resizing while Metashape is using some smoothing technique like bilinear resampling. I can see that both may have their uses, but the hard colors and jerky lines in the left image kind of obstruct seeing any subtle patterns like the circles you can clearly see around the sprinklers on the right.
I’m seeing this on all the datasets I’ve processed (I’m showing this one because this is the only one I’ve also done in Metashape). The options I’ve used are the following:
dsm: true, dtm: true
Is there any setting I can use to control the way in which the tiles are scaled to get a smoother result?
Did you try to increase the orthophoto resolution? Try to set a lower
orthophoto-resolution value and optionally use
I actually tried lowering the orthophoto-resolution to 2.0 before (as that actually pretty closely matches the full resolution of the dataset), but that made the process crash saying it ran out of memory (which sounds weird to me, the dataset is only 183 pictures and the server has 20GB of memory). But I’ll try that again now.
Also, I might add that the picture above is not fully zoomed in. I think my issue is mostly related to the scaling of the orthophoto for the zoomed-out tiles
I tried to process the same dataset with the following options:
orthophoto-resolution: 2, ignore-gsd: true, fast-orthophoto: true, rerun-from: dataset
As before, this crashed. Here’s the log, although I think it’s a separate issue…
You’re running out of memory.
OK, I added some more RAM to my VM and also added a 50GiB swap disk. My run is now completing successfully with these options:
orthophoto-resolution: 3, ignore-gsd: true, fast-orthophoto: true
However, as I said this is not my problem. I can zoom in further now (which is nice) but that was not my issue. The issue is with the quality of the zoomed-out tiles.
Here’s another example of what I mean:
The one on the left is from the WebODM viewer (not a screenshot but one of the tiles). The one on the right is the same tile, but as processed by Metashape. You can see Moiré patterns, especially on the top-left roof, that don’t occur on the tiles generated by Metashape.
This is at zoom level 18, which has an approximate resolution of 37 cm/px at my latitude, while the pictures were taken at around 2,5 cm/px, so there should be more than 200 samples available for each pixel.
It’s looking like WebODM/NodeODM is just picking one of those pixels when scaling (nearest-neighbor), while Metashape resamples the image, creating a much smoother result.
My original question was if there is any way to control this behaviour in WebODM.
You could change the code https://github.com/OpenDroneMap/WebODM/blob/master/app/api/tiler.py#L347 to include “orthophoto” in the tile type.
But imo, bilinear interpolation does not look good on orthophotos; it makes them blurrier. (That’s why we don’t apply it).
Do we have the option to use Bicubic or Lanczos (either non-separable or separable)? They might give us better scaled tiles, though obviously processing time will increase.
I see your point, but as I mentioned above I think that both have their use cases. I’ll try to have a look at the code and see if I can add it as an option.
I am always a Lanczos fan, myself. GDAL’s Lanczos has issues, but it might be worth a try. It should be an easy pull request for someone too… .
Suppose we could expose an option in the interface to choose the interpolation method.
Would definitely merge a PR that implements this.
I’ll do my best to put one together somewhere in the coming days. Any pointers on where I need to add stuff? I’m pretty proficient in Python but I’ve never done anything on this codebase.
Thanks a lot, doesn’t sound too difficult. I’ll look into it!