Fix Pixel shift in pleiades orthorectification
Closes #2293 (closed)
Merge request reports
Activity
changed milestone to %8.1.0
added bug label
assigned to @thibrom
Hi @thibrom
I've tested your version on HAL and still observe a gap along X axis (but in the opposite way, compared to previous version...). The image seems to be aligned along Y axis (OTB 7.4 being used as the reference here). FYI, my 'OTB 8.0' is here one of the patched version you've made for !914 (merged).
[tanguyy@visu06 tanguyy]$ gdalinfo ORTHO_OTB8.0.1_Toulouse/ortho_from_dimap_without_DEM/ortho.tif | grep Origin Origin = (363817.843750000000000,4839550.000000000000000) [tanguyy@visu06 tanguyy]$ gdalinfo ORTHO_OTB7.4_Toulouse/ortho_from_dimap_without_DEM/ortho.tif | grep Origin Origin = (363818.093750000000000,4839550.000000000000000) [tanguyy@visu06 tanguyy]$ gdalinfo ORTHO_OTB8.0_Toulouse/ortho_from_dimap_without_DEM/ortho.tif | grep Origin Origin = (363818.343750000000000,4839549.500000000000000)I also compared this OTB 8.0.1 version with 7.4 on Workshop Data PHR sample image. In that case, it seems the output is correctly georeferenced :
[tanguyy@visu06 tanguyy]$ gdalinfo Workshop_Results/Ortho_OTB_8.0.1_patch2293/ortho_phr_xs_osr_mipy.tif | grep Origin Origin = (349342.375000000000000,4821486.000000000000000) [tanguyy@visu06 tanguyy]$ gdalinfo Workshop_Results/Ortho_OTB_7.4/ortho_phr_xs_osr_mipy.tif | grep Origin Origin = (349342.375000000000000,4821486.000000000000000)Could you compare the origin and corner coordinates with OTB 7.4 on the different PHR images you use ? Thanks
Hi @ytanguy
After some tests, my results are the following : For Toulouse using the jp2
gdalinfo ~/Data/ortho_toulouse_7.tif| grep "Origin" Origin = (366849.406250000000000,4848996.000000000000000) gdalinfo ~/Data/ortho_toulouse_8_modif.tif| grep "Origin" Origin = (366847.375000000000000,4848996.500000000000000)For Ventoux using the jp2
gdalinfo ~/Data/ortho_ventoux_7_dem_grd.tif | grep "Origin" Origin = (672591.562500000000000,4900781.000000000000000) gdalinfo ~/Data/ortho_ventoux_8_modif.tif | grep "Origin" Origin = (672589.437500000000000,4900782.000000000000000)In both case I notice the offset in X, and on Y. Is the workshop data different from the image you provided? When comparing to OSM, the 8.0.1 with the patch 2293 fits better with the roads / remarquable features on the ground, but we have yet to determine which version is better with a reference grid.
-
Thanks for your analysis @thibrom. The workshop data contains some simplified PHR products : I don't know where it comes from, but their format is different from the official products from Dinamis or other suppliers.
added 1 commit
- b7e593a6 - BUG: The offset has been handled by GDAL >= 3.2 for pleiades products
added 1 commit
- 2c1de4ae - TEST: Update the baseline without shifted orthorectification
added 1 commit
- db748502 - DOC: Add explanation on the modifications of some baselines
Hi @thibrom, I'm not sure to understand where the problem really is.
I recently used the 8.0.1 release (built with gdal 3.4.3) to orthorectify several (2022) Pléiades products.
Are my result shifted ? Or was it the 7.x release / test images that were badly shifted ?Images are covering Uganda so I don't have solid baseline images to compare with...
Edited by Vincent DelbarThere was a shift of 1 pixel between OTB 7.4 and OTB 8, due to a bug in gdal < 3.2 that we fixed in OTB with an added shift. But this problem was handled by gdal > 3.2 and we did not do the modification in our code when we upgraded gdal. In recent tests, with this fix, we found out that the orthorectification was right with OTB 8.0.1 + this fix with solid baselines. If you did your ortho with OTB 8.0.1 you should have a 0.5 pixel shift which is better than with OTB 7.4 (1px). An OTB version 8.0.2 is on the way with this fix and others, we don't have a release date at the moment but it will be available soon
Edited by Thibaut ROMAINmentioned in commit c6073ba7
