-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Uneven raster cell size outputs #1488
Comments
I think the odm_orthophoto renders the orthophoto in the exact raster size provided. It calculates the orthophoto height and width by
But this still won't fix the problem, because gdal_translate has to calculate the scale from bounds again, and floating-point error is inevitable in such a way. I corrected one orthophoto with the above bounds, it generates the transform like below
If you can confirm that odm_orthophoto renders the exact raster size as provided, we can directly write the scale value using rasterio (I don't find options to do it with gdal_translate). |
Thanks for looking into this. Like you say, the core issue is that we manually set the bounds, and precision issues are inevitable.
A really good improvement would be to skip the entire |
My point is that odm_orthophoto has already created evenly sized cells, based on how it calculates the orthophoto width and height. So we don't need to adjust/warp the cells, the only problem is then how we properly write the transform data into the orthophoto. The current approach have two issues
Issue 1 can be solved by the formula in my last comment I can prepare a pr for fixing issue 1 firstly if my understanding of odm_orthophto is correct, need your confirmation. |
Yes I think this is the correct approach (fix 1, then 2). Careful where you adjust the bounds, I would try to calculate them (with the proposed correction) in |
Forgot to also mention, this issue also affects DSM/DTM outputs ( |
I made some changes to odm_orthophoto, it will calculate the correct bounds, and it can also use GDAL API to write GeoTransfrom and CRS to the geotiff. But then I noticed that The same thing applied for DSM, the PDAL pipeline generates all the tiff with precise cell sizes, but later GDAL related operations will cause slight precision loss. (It might have something to do with the ceiling and splitting approach, I need to check) But the precision level is pretty much the float type's level, so I think it should be fine. |
OpenDroneMap/odm_orthophoto#1 Before
Bounds fix
Directly set GeoTransform
|
Noticed a (possible?) issue with #1499: even though the cell size is now more uniform, the orthophotos seem to have shifted: I overlayed them to the DSM, and I think the shift worsens the georeferencing accuracy (the rooftop moves further away from the DSM edge): I would have expected the overall position of the orthophoto not to shift? |
Is it due to scale or shift (is the top left corner of the orthophoto shifted as well)? |
Yes, I can confirm it's caused by the raster size change. Shifting will increase when the pixel gets far away from the top left corner, no more than 1 pixel.
When investigating this, I learned that in GeoTIFF, [0,0] pixel's coordinate has a half pixel shift of the geotransform offsets. When georeferencing the GeoTIFF, we seem not to consider this, I'm not sure if this is relevant.
|
I think rasterio lets you specify how you want to interpret the xy coordinates (either corner or center, by default it's center), so I don't think it's GeoTIFF-specific thing:
|
The problem is then how PDAL defines the origin when it's creating a raster if we are comparing it with the DSM data. And depends on the different implementations, there could be an alignment issue between dem and orthophoto.
These could potentially cause problems and make the above comparison less valid? I'll try to replicate the way PDAL renders raster and see how the results look like |
Some updates. I haven't started working on replicating the pdal rendering approach in odm_orthophoto, but managed to render an "RGB" version of DSM. Lines 56 to 63 in 5dd0859
Changed them to
dimensions will be RED, GREEN, and BLUE. Generate "dsm" 3 times with each color. Then use gdal_merge.py to merge bands. And this is what I got, it looks kinda cute : ) I put the generated rgb_dsm in the below link. There are two versions, one is https://drive.google.com/drive/folders/1aVE5gxOvSktPxOeOizZcsDCJj52bmM34?usp=sharing |
I was wrong about this, odm_orthophoto uses
Therefore, odm_orthophoto also uses pixel center as xy. Same as rasterio defaults or pdal. There is no difference for the corner or center assumptions. I believe the use PDAL directly rendered RGB "DSM" to compare is more straightforward than DSM. |
Thanks for looking further into this! Yes PDAL will always need a radius parameter to render results using I suppose a better source for ground truth should be
When opened in QGIS, the two files are slightly different, but the pixel shift is much less apparent. |
I still believe the uneven problem is caused by the problem I mentioned in the first comment.
Odm_orthophoto firstly calculates the image size by
Then it renders pixel size exactly at 0.05m/pixel. Can be proved by that it transforms the points by the below affine matrix so that the points are directly located inside the image grid. 1/0.05 , 0 , -xMin The ceil operation will extend the bounds, but if we still use the old bounds to wrap the orthophoto, it will cause errors. And because x and y errors are different, which makes the cell size uneven. The errors are not big, they are limited by the resolution, but half of the resolution error means half a pixel offset at the bottom right corner of the image.
If the image is rendered with the extended bounds(larger) but wrapped with the original bounds(smaller). This will shrink the cell size a little bit. The difference for each cell is tiny, but it will accumulate from tl corner to br corner, this is the reason for the offsets. And I do think the approach I use PDAL to generate orthophoto provides valid proof that my fix is correct. Anyway, this is all I got from the recent investigation, I hope this can persuade you. |
I started looking at this problem a bit from the DEM generation. The cells become uneven during the crop stage (here: https://github.com/OpenDroneMap/ODM/blob/master/opendm/cropper.py#L53), I suspect because the crop polygon is not aligned to properly round boundaries. Interestingly one can pass Maybe the way to do this would be to simply add a new |
Sounds good! |
Currently outputs from ODM have slightly uneven cell raster sizes:
This could be improved.
The text was updated successfully, but these errors were encountered: