Small differences between command line and C++ library

OTB Usage
1

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!

2

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

3

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)

4

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.

5

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

6

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

7

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

8

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?

9

Can you give us the output of gdalinfo on the two images you obtain? or otbcli_ReadImageInfo

10

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)

11

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.

12

Hello,

Thanks for your tests, it is very interesting. I don’t have enough background to give you a clear answer about the choice of float instead of double, but it is worth creating an issue on the forge, it could solve hidden problems

Best regards

13

Problem solved with version 8.1.2

Thank you very much!

14

Glad to here that! thank you for your contribution to this bug fix!