Hi everyone,
I’m attempting to replicate the otbcli_OrthoRectification execution on an image with RPC parameters with the C++ dlls.
Starting from the same image, I obtain a very similar output image, but not an identical one. Some pixels are shifted in position by 1 pixel, but not all of them, and this shift occurs in a regular manner.
I’ve noticed a peculiar behavior when examining the image metadata. There is only a slight difference in the UL origin and the spacing values. If I take my values obtained using the C++ dlls and cast them to float values, I obtain the same values as those reported by the image generated with the command line.
For example, with my code I obtain:
spacing: [(1.9842828128442165,), (1.9842828128442165,), (0.0,)]
And with the command line:
spacing: [(1.9842828512191772,), (1.9842828512191772,), (0.0,)]
I’m using the same binary package, OTB 8.1.1 on Windows. Compiler is v142.
Has anyone encountered a similar issue?
Thank you in advance!
Hi @IlDordollano
Do you call the orthorectification with the dem and geoid in parameters ? We observed a shift in mountaineous areas most notably when not using the dem / geoid. You can find them in the repository in the Data/Input/DEM folder
Let me know,
Best regards
Nevertheless,
What compile option did you use for your code ? it could change the results by minor differences, depending on visual studio version (we use version 14.29 on the CI to generate the windows package)
Thank you for the reply @thibaut.romain .
I’m calling the orthorectification without any dem or geoid parameters.
The compile options that I’m using are:
/JMC /permissive- /ifcOutput “Debug" /GS /analyze- /W3 /Zc:wchar_t /ZI /Gm- /Od /sdl /Fd"Debug\vc142.pdb” /Zc:inline /fp:strict /D “WIN32” /D “_DEBUG” /D “_CONSOLE” /D “_UNICODE” /D “UNICODE” /errorReport:prompt /WX- /Zc:forScope /RTC1 /Gd /Oy- /MDd /FC /Fa"Debug" /EHsc /nologo /Fo"Debug" /Fp"Debug\orthorectification.pch" /diagnostics:column
I tried two different versions of MSVC and the output is the same. MSVC 14.16.27023 and MSVC 14.35.32215.
I think the debug mode can make a little precision difference, could you try in Release mode? The MSVC version seems right, I am pretty sure it is a compile option that cause this difference
Yes, I’m sorry. I’ve copy-pasted the wrong string from settings. As a matter of fact, debug mode is not even possible with the pre-compiled binary package, since the dlls are only in release mode.
The compile options are:
/JMC /permissive- /MP /ifcOutput “x64\Release" /GS /W3 /Gy /Zc:wchar_t /I"C:\ORFEO_SDK\OTB-8.1.1-Win64\include” /I"C:\ORFEO_SDK\OTB-8.1.1-Win64\include\ITK-4.13" /I"C:\ORFEO_SDK\OTB-8.1.1-Win64\include\OTB-8.1" /I"C:\ORFEO_SDK\OTB-8.1.1-Win64\include\boost-1_72" /ZI /Gm- /O2 /sdl /Fd"x64\Release\vc142.pdb" /Zc:inline /fp:precise /D “NDEBUG” /D “_CONSOLE” /D “_UNICODE” /D “UNICODE” /errorReport:prompt /WX- /Zc:forScope /Gd /MD /FC /Fa"x64\Release" /EHsc /nologo /Fo"x64\Release" /Fp"x64\Release\orthorectification.pch" /diagnostics:column
This is ours to generate the package:
/DTHROW_QCRITICAL=0 /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MP /D_ENABLE_EXTENDED_ALIGNED_STORAGE /wd4005 /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE
I’ve made another tentative moving the code to the docker image of Orfeo Toolbox and I’ve tried to compile the code with cmake inside the docker image, so using a Linux environment.
The output is the same.
So I suppose it is platform independent… maybe is something else?
Can you give us the output of gdalinfo on the two images you obtain? or otbcli_ReadImageInfo
Yes, of course.
Attached to this reply you can find the outputs of gdalinfo.
gdalinfo_cpp_out.txt (2.9 KB)
gdalinfo_orfeo_out.txt (2.9 KB)
Hello,
To better understand the problem, I’ve tried recompiling only otbcli_OrthoRectification.
What I found is that otbOrthoRectification.cxx uses float values, using functions like SetParameterFloat and GetParameterFloat.
I did a find/replace of every “Float” to “Double” in that file and recompiled it. Now the result is identical to my simple c++ code.
Therefore, the issue lies in the type of casting being used, which results in a loss of precision, approximately 5 meters of discrepancy in my case.
I wonder why otbOrthoRectification code uses float values instead of double values.