otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2024-03-21T12:03:28Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2370Undefined references to boost2024-03-21T12:03:28ZLoris LizziUndefined references to boostHi, i tried to compile OTB from 8.1.2 tag and from develop branch on Ubuntu 22.04, but i've always this cmake error:
``/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbTerraSarXSarImageMetadataInterface.cxx.o: in function otb::ExtractXMLFiles...Hi, i tried to compile OTB from 8.1.2 tag and from develop branch on Ubuntu 22.04, but i've always this cmake error:
``/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbTerraSarXSarImageMetadataInterface.cxx.o: in function otb::ExtractXMLFiles::GetXMLFilesInDirectory(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, bool) [clone .localalias]': otbTerraSarXSarImageMetadataInterface.cxx:(.text+0x29ec): undefined reference to boost::filesystem::detail::directory_iterator_construct(boost::filesystem::directory_iterator&, boost::filesystem::path const&, unsigned int, boost::filesystem::detail::directory_iterator_params*, boost::system::error_code*)'
/usr/bin/ld: otbTerraSarXSarImageMetadataInterface.cxx:(.text+0x2ade): undefined reference to `boost::filesystem::detail::path_algorithms::extension_v3(boost::filesystem::path const&)'
/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbTerraSarXSarImageMetadataInterface.cxx.o: in function `otb::ExtractXMLFiles::GetResourceFile(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool)':
otbTerraSarXSarImageMetadataInterface.cxx:(.text+0x308e): undefined reference to `boost::filesystem::detail::path_algorithms::filename_v3(boost::filesystem::path const&)'
/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbTerraSarXSarImageMetadataInterface.cxx.o: in function `boost::iterator_range_detail::iterator_range_base<boost::filesystem::directory_iterator, boost::iterators::incrementable_traversal_tag>::~iterator_range_base()':
otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED2Ev[_ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED5Ev]+0x30): undefined reference to `boost::filesystem::detail::dir_itr_imp::~dir_itr_imp()'
/usr/bin/ld: otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED2Ev[_ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED5Ev]+0x54): undefined reference to `boost::filesystem::detail::dir_itr_imp::~dir_itr_imp()'
/usr/bin/ld: otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED2Ev[_ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED5Ev]+0x5c): undefined reference to `boost::filesystem::detail::dir_itr_imp::operator delete(void*)'
/usr/bin/ld: otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED2Ev[_ZN5boost21iterator_range_detail19iterator_range_baseINS_10filesystem18directory_iteratorENS_9iterators27incrementable_traversal_tagEED5Ev]+0x3e): undefined reference to `boost::filesystem::detail::dir_itr_imp::operator delete(void*)'
/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbTerraSarXSarImageMetadataInterface.cxx.o: in function `void boost::sp_adl_block::intrusive_ptr_release<boost::filesystem::detail::dir_itr_imp, boost::sp_adl_block::thread_safe_counter>(boost::sp_adl_block::intrusive_ref_counter<boost::filesystem::detail::dir_itr_imp, boost::sp_adl_block::thread_safe_counter> const*)':
otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost12sp_adl_block21intrusive_ptr_releaseINS_10filesystem6detail11dir_itr_impENS0_19thread_safe_counterEEEvPKNS0_21intrusive_ref_counterIT_T0_EE[_ZN5boost12sp_adl_block21intrusive_ptr_releaseINS_10filesystem6detail11dir_itr_impENS0_19thread_safe_counterEEEvPKNS0_21intrusive_ref_counterIT_T0_EE]+0x25): undefined reference to `boost::filesystem::detail::dir_itr_imp::~dir_itr_imp()'
/usr/bin/ld: otbTerraSarXSarImageMetadataInterface.cxx:(.text._ZN5boost12sp_adl_block21intrusive_ptr_releaseINS_10filesystem6detail11dir_itr_impENS0_19thread_safe_counterEEEvPKNS0_21intrusive_ref_counterIT_T0_EE[_ZN5boost12sp_adl_block21intrusive_ptr_releaseINS_10filesystem6detail11dir_itr_impENS0_19thread_safe_counterEEEvPKNS0_21intrusive_ref_counterIT_T0_EE]+0x2e): undefined reference to `boost::filesystem::detail::dir_itr_imp::operator delete(void*)'
/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbRadarsat2ImageMetadataInterface.cxx.o: in function `otb::Radarsat2ImageMetadataInterface::CreateCalibrationLookupData(otb::SARCalib&, otb::ImageMetadata const&, otb::MetadataSupplierInterface const&, bool) const':
otbRadarsat2ImageMetadataInterface.cxx:(.text+0x29e6): undefined reference to `boost::filesystem::detail::path_algorithms::remove_filename_v3(boost::filesystem::path&)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x29f9): undefined reference to `boost::filesystem::detail::path_algorithms::append_v3(boost::filesystem::path&, char const*, char const*)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x2b21): undefined reference to `boost::filesystem::detail::path_algorithms::remove_filename_v3(boost::filesystem::path&)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x2b34): undefined reference to `boost::filesystem::detail::path_algorithms::append_v3(boost::filesystem::path&, char const*, char const*)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x2cd5): undefined reference to `boost::filesystem::detail::path_algorithms::remove_filename_v3(boost::filesystem::path&)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x2ce8): undefined reference to `boost::filesystem::detail::path_algorithms::append_v3(boost::filesystem::path&, char const*, char const*)'
/usr/bin/ld: CMakeFiles/OTBMetadata.dir/otbRadarsat2ImageMetadataInterface.cxx.o: in function `otb::Radarsat2ImageMetadataInterface::ParseGeom(otb::ImageMetadata&)':
otbRadarsat2ImageMetadataInterface.cxx:(.text+0x51c0): undefined reference to `boost::filesystem::detail::path_algorithms::remove_filename_v3(boost::filesystem::path&)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x51d6): undefined reference to `boost::filesystem::detail::path_algorithms::append_v3(boost::filesystem::path&, char const*, char const*)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x5201): undefined reference to `boost::filesystem::detail::path_algorithms::remove_filename_v3(boost::filesystem::path&)'
/usr/bin/ld: otbRadarsat2ImageMetadataInterface.cxx:(.text+0x5210): undefined reference to `boost::filesystem::detail::path_algorithms::append_v3(boost::filesystem::path&, char const*, char const*)'
collect2: error: ld returned 1 exit status
make[2]: *** [Modules/Core/Metadata/src/CMakeFiles/OTBMetadata.dir/build.make:837: lib/libOTBMetadata-8.1.so.1] Errore 1
make[1]: *** [CMakeFiles/Makefile2:4991: Modules/Core/Metadata/src/CMakeFiles/OTBMetadata.dir/all] Errore 2
make: *** [Makefile:136: all] Errore 2``
What could it be?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2384SuperBuild LibKML URL is out of date2024-03-21T11:29:08ZLaurențiu NicolaSuperBuild LibKML URL is out of dateIt's https://deb.debian.org/debian/pool/main/libk/libkml/libkml_1.3.0~r864+dfsg.orig.tar.gz, but should be http://deb.debian.org/debian/pool/main/libk/libkml/libkml_1.3.0.orig.tar.gz or something like that.It's https://deb.debian.org/debian/pool/main/libk/libkml/libkml_1.3.0~r864+dfsg.orig.tar.gz, but should be http://deb.debian.org/debian/pool/main/libk/libkml/libkml_1.3.0.orig.tar.gz or something like that.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2380Separate Miscellaneous in separate repository2024-03-20T15:59:44ZTristan LaurentSeparate Miscellaneous in separate repositoryTo compilate project, we can use OTB modules https://www.orfeo-toolbox.org/CookBook-9.0/RemoteModules.html
- [x] Create external git repo, link it as a submodule
- [x] OTB core must download corresponding submodule if the cmake -DOTBGrou...To compilate project, we can use OTB modules https://www.orfeo-toolbox.org/CookBook-9.0/RemoteModules.html
- [x] Create external git repo, link it as a submodule
- [x] OTB core must download corresponding submodule if the cmake -DOTBGroup_Miscellaneous is turned on
- [x] Compile it separately, you may use OTB core artifact
- [x] Verify that package is correctly built during cpack
- [ ] Adapt CI to run corresponding build job and tests
- [ ] Adapt otb CI to start module job when there is a new dependency (i.e. OTB core)
- [ ] Adapt bug tracking for each project ?
- [ ] Add a Readme with compilation help, otb integration, and some exemples10.0.0Tristan LaurentTristan Laurenthttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2372can not run pipeline.exe properly2024-03-20T14:29:26Zjiayuew1can not run pipeline.exe properlyI attempted to replicate the Pipeline.exe application based on the tutorial available at https://www.orfeo-toolbox.org/CookBook/C%2B%2B/Examples/Tutorials/Pipeline.html#pipeline-cxx. The application is designed to read an input image fil...I attempted to replicate the Pipeline.exe application based on the tutorial available at https://www.orfeo-toolbox.org/CookBook/C%2B%2B/Examples/Tutorials/Pipeline.html#pipeline-cxx. The application is designed to read an input image file, perform a simple processing pipeline, and write the result to an output image file. However, I encountered issues with setting the input and output filenames in the code.
I followed the tutorial's instructions and used the provided CMake configuration to build the application. Unfortunately, I received error messages indicating that the reader and writer filenames were not set correctly after calling SetFileName.
I performed various debugging steps, including checking file paths, verifying file existence, and updating output information. Despite these efforts, the issue persisted, and the filenames were not being set as expected.
I'm seeking assistance in refining the code to correctly set the input and output filenames, ensuring the successful execution of the OTB pipeline as demonstrated in the tutorial.
here is my pipeline.cxx
`#include "otbImage.h"
#include "otbImageFileReader.h"
#include "otbImageFileWriter.h"
#include <iostream>
#include <fstream>
#include <string>
#include "itkIndent.h"
int main(int argc, char* argv[])
{
// First, check the number of arguments
if (argc != 3)
{
std::cerr << "Usage: " << argv[0] << " <input_filename> <output_filename>" << std::endl;
return EXIT_FAILURE;
}
try
{
// Declare the image types and reader/writer types
using ImageType = otb::Image<unsigned char, 2>;
using ReaderType = otb::ImageFileReader<ImageType>;
using WriterType = otb::ImageFileWriter<ImageType>;
// Create the reader and writer objects
ReaderType::Pointer reader = ReaderType::New();
WriterType::Pointer writer = WriterType::New();
// Check if the input file exists
std::ifstream infile(argv[1]);
if (!infile.good())
{
std::cerr << "Error: Input file does not exist or is inaccessible: " << argv[1] << std::endl;
return EXIT_FAILURE;
}
infile.close();
// Output the file names for debugging
std::cout << "Input file: " << argv[1] << std::endl;
std::cout << "Output file: " << argv[2] << std::endl;
reader->SetFileName(argv[1]);
writer->SetFileName(argv[2]);
// Debugging: Check if filenames are set correctly
if (reader->GetFileName() == nullptr || std::string(reader->GetFileName()).empty())
{
std::cerr << "Error: Reader filename not set correctly after setting: " << argv[1] << std::endl;
return EXIT_FAILURE;
}
if (writer->GetFileName() == nullptr || std::string(writer->GetFileName()).empty())
{
std::cerr << "Error: Writer filename not set correctly after setting: " << argv[2] << std::endl;
return EXIT_FAILURE;
}
// Connect the reader to the writer
writer->SetInput(reader->GetOutput());
// Trigger the pipeline execution
writer->Update();
}
catch (const std::exception& e)
{
std::cerr << "An error occurred: " << e.what() << std::endl;
return EXIT_FAILURE;
}
return EXIT_SUCCESS;
}
`
and here are my outputs
`PS C:\Users\zoech\Desktop\example\build\Debug> ./Pipeline.exe "C:\Users\zoech\Downloads\OTB-Data-Examples\Examples\QB_Suburb.png" C:\Users\zoech\Downloads\OTB-Data-ExTB-Data-Examples\Examples\Outpu\output_image.png
Input file: C:\Users\zoech\Downloads\OTB-Data-Examples\Examples\QB_Suburb.png
Output file: C:\Users\zoech\Downloads\OTB-Data-ExTB-Data-Examples\Examples\Outpu\output_image.png
Error: Reader filename not set correctly after setting: C:\Users\zoech\Downloads\OTB-Data-Examples\Examples\QB_Suburb.png`
here is my CMakeLists.text
cmake_minimum_required(VERSION 3.5)
set(CMAKE_BUILD_TYPE Debug) # You can change 'Debug' to 'Release' or other build types
project(Tutorials)
find_package(OTB REQUIRED)
if(OTB_FOUND)
include(${OTB_USE_FILE})
message(STATUS "OTB_USE_FILE: ${OTB_USE_FILE}")
else(OTB_FOUND)
message(FATAL_ERROR "Cannot build OTB project without OTB. Please set OTB_DIR.")
endif(OTB_FOUND)
add_executable(HelloWorldOTB HelloWorldOTB.cxx )
target_link_libraries(HelloWorldOTB ${OTB_LIBRARIES})
add_executable(Pipeline Pipeline.cxx )
target_link_libraries(Pipeline ${OTB_LIBRARIES}).
I wonder whether is there a problem related to my OTB setuphttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2369Difficulty setting up OTB version 8.12 on QGIS 3.342024-03-20T14:26:35ZSeno337Difficulty setting up OTB version 8.12 on QGIS 3.34### Description
An error message “an error has occurred while executing Python code” keeps coming up when I try to set up
### Steps to reproduce
It happens after setting the directories (OTB folder and applications folder)
### Confi...### Description
An error message “an error has occurred while executing Python code” keeps coming up when I try to set up
### Steps to reproduce
It happens after setting the directories (OTB folder and applications folder)
### Configuration information
Windows 11, OTB version 8.1.2-win64, information related to build (binaries, superbuild, system libs ...)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2381PLEIADES Orthorectification failed since version 82024-03-20T14:24:20ZdemagistPLEIADES Orthorectification failed since version 8### Description
Since release 8 of OTB I am not able anymore to apply Orthorectification on a Pleiades image I use during a lesson.
The same command line works fine with version 7.4.2 and fails since versions 8.
### Steps to reproduce
...### Description
Since release 8 of OTB I am not able anymore to apply Orthorectification on a Pleiades image I use during a lesson.
The same command line works fine with version 7.4.2 and fails since versions 8.
### Steps to reproduce
The following command produce a good result with release 7.4.2 (linux or windows) :
otbcli_OrthoRectification -io.in "./IMG_PHR1B_MS_004/IMG_PHR1B_MS_201807291333495_SEN_3210573101-004_R1C1.TIF?&skipcarto=true" -map utm -map.utm.zone 23 -interpolator nn -opt.ram 1024 -opt.gridspacing 4 -elev.dem ./SRTM1 -io.out ./test_ORTHO+DEM.tif
Since release 8, it does not work anymore.
I tested the latest 9.0.0 release using a docker image :
docker run -it -v .:/Data orfeotoolbox/otb:9.0.0 otbcli_OrthoRectification -io.in "/Data/IMG_PHR1B_MS_004/DIM_PHR1B_MS_201807291333495_SEN_3210573101-004.XML?&skipcarto=true" -map utm -map.utm.zone 23 -interpolator nn -opt.ram 1024 -opt.gridspacing 4 -elev.dem /Data/SRTM1 -io.out /Data/test_ORTHO+DEM.tif
and got the following error :
(FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0x788a50): No information in the metadata, please set an image with non empty metadata
Same problem using the DIMAP xml file as input file :
docker run -it -v .:/Data orfeotoolbox/otb:9.0.0 otbcli_OrthoRectification -io.in "/Data/IMG_PHR1B_MS_004/DIM_PHR1B_MS_201807291333495_SEN_3210573101-004.XML?&skipcarto=true" -map utm -map.utm.zone 23 -interpolator nn -opt.ram 1024 -opt.gridspacing 4 -elev.dem /Data/SRTM1 -io.out /Data/test_ORTHO+DEM.tif
2024-03-06 16:27:10 (INFO) OrthoRectification: Elevation management: setting default height above ellipsoid to 0 meters
2024-03-06 16:27:10 (INFO): Loading metadata from official product
2024-03-06 16:27:10 (FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0x788a50): No information in the metadata, please set an image with non empty metadata
### Configuration information
see above in descriptionhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1726stop superbuild if a patch fails2024-03-20T14:15:25ZRashad Kanavathstop superbuild if a patch fails### Description
superbuild must stop if any of patch is failing. right now we keep going and fail at end of otb configure/build phase.
see below log from superbuild for opencv
```
Input patch file: C:/dashboard/otb/src/SuperBuild/patche...### Description
superbuild must stop if any of patch is failing. right now we keep going and fail at end of otb configure/build phase.
see below log from superbuild for opencv
```
Input patch file: C:/dashboard/otb/src/SuperBuild/patches/OPENCV/opencv-1-install-prefix-win.diff
CMake Error at C:/dashboard/otb/src/SuperBuild/CMake/patch.cmake:57 (message):
C:/Tools/patch-2.5.9-7/bin/patch.exe --binary -p1 -i
C:/dashboard/otb/src/SuperBuild/patches/OPENCV/opencv-1-install-prefix-win.diff
failed
error: (Stripping trailing CRs from patch.)
patching file CMakeLists.txt
Hunk #1 FAILED at 290.
1 out of 1 hunk FAILED -- saving rejects to file CMakeLists.txt.rejhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1721disable use of libraries/dependencies from system in SuperBuild2024-03-20T14:14:57ZRashad Kanavathdisable use of libraries/dependencies from system in SuperBuildRemove all `USE_SYSTEM_*` variables from superbuild. There are around 35 libraries used in superbuild now. Allowing them to use an existing install of this library can create more problems. I don't remember the exact motive behind this d...Remove all `USE_SYSTEM_*` variables from superbuild. There are around 35 libraries used in superbuild now. Allowing them to use an existing install of this library can create more problems. I don't remember the exact motive behind this design decision. My guess, is for debugging purposes. It is so easy to screw things up. It "must" work on all platforms and have same number of tests passing.
Anyway there is no way to test all combination of system v. superbuild of all libraries in OTB. Even if it can "argued" to doable that falls right on sane/insane check. Testing all combination will explode any of existing build matrix ever available for a single project in history. Btw, remember we have 2 platforms and at-least 5-10 linux distribution to test each combination.
With this feature done, superbuild can be tested on maximum number of platforms and can fix serious bugs come out of it. I believe this would be a nice deal for project.
Regarding big libraries, its not taking too much time. After all, you opted to use superbuild for a cause which sure has its price/https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1720Add and document a Dockerfile or some easy way to get started with OTB develo...2024-03-20T14:14:03ZLaurențiu NicolaAdd and document a Dockerfile or some easy way to get started with OTB development### What changes will be made and why they would make a better Orfeo ToolBox?
#### High level description
SuperBuild is neat, however it doesn't always work because of issues in some of the dependencies (!239) or other reasons (#1718, ...### What changes will be made and why they would make a better Orfeo ToolBox?
#### High level description
SuperBuild is neat, however it doesn't always work because of issues in some of the dependencies (!239) or other reasons (#1718, #1719). And not using it is awkward, as some dependencies (OSSIM, ITK, OpenThreads, libsvm) aren't available on all distributions. ITK tends to be problematic on rolling distros because VNL hard-codes a list of compiler versions, which isn't kept up to date. GCC 8.1 was released in May 2018, while ITK 4.13.1 with support for it came out in August.
This is a proposal to add a _sanctioned_ configuration (OS and dependencies) suitable for OTB development, together with some description of how to get started. Docker can be used to set up a reproducible environment; the source code and build directory can be mounted as volumes, so the user can edit the source in whatever editor or IDE they prefer, while building in the container. Of course, fancy IDE features like "go to definition" will not work, because the dependencies are not available on the host.
The advantages of using Docker instead of a VM are that:
* one doesn't have to spend time setting it up
* on Linux, it has better performance than a VM
As a minimal straw-man proposal, we could start from an Ubuntu Bionic image with the following additions:
```
apt install libgeotiff-dev cmake cmake-curses-gui libinsighttoolkit4-dev libgdal-dev libboost-dev libopenthreads-dev libossim-dev libtinyxml-dev libsvm-dev
```
#### Risks and benefits
* benefit: it makes it possible to work on OTB on rolling distros
* benefit: getting familiar with Docker could help some developers investigate issues on distros they don't normally have access to
* benefit: it gives users a separate development environment, so they don't have to clutter their systems with the OTB dependencies. For example, when uninstalled, one of the Arch OSSIM packages (IIRC) removes the `/usr/lib64` symlink to `/lib`, rendering the system unbootable after the next kernel update.
* risk: some people might be unhappy with what's in the Docker image (e.g. should it include `ccmake`?)
* risk: if we only include a `Dockerfile` (a short description of how to build the container image), people might expect the image to be available on Dockerhub (so they can just download instead of building it) or a run-time image, and that might increase the maintenance effort
* risk: the `Dockerfile` might need to be updated from time to time (on distro or OTB releases with dependency changes, e.g. if OSSIM is dropped, it _should_ be removed from the `Dockerfile`); this is an additional maintenance effort, albeit small
* risk: developing Monteverdi might not work or need additional setup
* risk: doing this is a silent acknowledgement that OTB isn't as portable as we might like it to be
#### Alternatives for implementations
* do nothing: there aren't a lot of OTB developers, and most of them are probably using one of the Dashboard platforms, so they don't run into issues
* add a line in the documentation/Wiki: "To get started on Ubuntu 18.04, install these packages: ..."; this might be the easiest solution
* test on rolling releases and patch the dependencies: e.g. we could have patched SuperBuild ITK to add support for GCC 8 long before ITK 4.13.1 came out; this would some churn and maintenance effort as well, at the benefit of supporting more systems
* reuse: refer users to an existing Docker image (UbuntuGIS?) that might have the dependencies already available.
### Who will be developing the proposed changes?
@lnicola, or up for grabs.Laurențiu NicolaLaurențiu Nicolahttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1701include FindGDAL.cmake in OTB/CMake2024-03-20T14:13:04ZRashad Kanavathinclude FindGDAL.cmake in OTB/CMake"find_package(GDAL REQUIRED)" will fail on linux distributions (not all) if configuring projects using OTB with binary packages. This is due to fact that gdal headers are installed in some distro such as ubuntu in "<prefix>/include/gdal"..."find_package(GDAL REQUIRED)" will fail on linux distributions (not all) if configuring projects using OTB with binary packages. This is due to fact that gdal headers are installed in some distro such as ubuntu in "<prefix>/include/gdal" while package is installing it in "<prefix>/include".
Either we have to patch superbuild to install gdal into "include/gdal" (not recommended) or keep a copy of "FindGDAL.cmake" in src tree.
Patching superbuild to change include directory can work for ubuntu in this case but may break on other systems. Adding FindGDAL.cmake into src tree we can instruct cmake to look into "include" and also look into "include/gdal". So including this file seems practical solution for now. Even if we try to patch cmake findgdal.cmake we still have "N" number of cmake versions (OTB supports cmake version since 3.0) out there that's gonna mess up a user installation. Also GDAL is important dependency in projects using OTB. Many of them use gdal apps and api directly without going through GDALImageIO
upstream version of cmake: https://github.com/Kitware/CMake/blob/master/Modules/FindGDAL.cmakehttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1693Integrate S2P SIFT version into OTB2024-03-20T14:12:06ZMickael SavinaudIntegrate S2P SIFT version into OTB### What changes will be made and why they would make a better Orfeo ToolBox?
This proposal is about the integration of the SIFT implementation from S2P into
OTB. It would bring a faster implementation of this classic algorithm, using
A...### What changes will be made and why they would make a better Orfeo ToolBox?
This proposal is about the integration of the SIFT implementation from S2P into
OTB. It would bring a faster implementation of this classic algorithm, using
AVX and SSE instructions.
See (here)[https://github.com/MISS3D/s2p/tree/master/c/sift]
#### High level description
The integration plan would consist in the following steps:
* the SIFT implementation (in C) from S2P should be compiled as a shared library,
containing the extraction of SIFT keypoints, the computation of the descriptors,
and the matching algorithm.
* this library can be declared in OTB as a 3rd party module.
* development of a new OTB filter to use this library
#### Risks and benefits
There are several points to analyze:
* the streaming should be handled carefully, sufficient margins should be taken
* any extra copy of the image buffer should be avoided if possible, but it may not
be possible if the OTB filter is dealing with pixel type other than float.
* the implementation of multi-threading is delicate, since OTB uses its own
framework. Provided the SIFT library used is thread safe, the OTB filter could
use the ITK multi-threading pattern, but the usage of image strips too small
could lead to missing keypoints.
* the usage of AVX or SSE extension depends on the processor used. It may be
difficult to produce portable binaries if S2P SIFTs use specific extensions.
On the bright side, the OTB would gain a state-of-the-art implementation of SIFT.
#### Alternatives for implementations
The presented implementation strategy seems the best one. An other way could be
to integrate the corresponding S2P SIFT sources in the OTB (what was done in the
past), but this is not the chosen policy for 3rd parties anymore.
### Who will be developing the proposed changes?
TBD but anyone with some knowledge of the OTB and the SIFT algorithm.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1683keep cmake gui usable for all2024-03-20T14:07:51ZRashad Kanavathkeep cmake gui usable for allccmake or cmake-gui provides a nice interface for users. currently it is polluted with a lot unwanted variables.
keep only required variables and mark others unwanted.
current version
```
BUILD_EXAMPLES ON
BUILD_SHA...ccmake or cmake-gui provides a nice interface for users. currently it is polluted with a lot unwanted variables.
keep only required variables and mark others unwanted.
current version
```
BUILD_EXAMPLES ON
BUILD_SHARED_LIBS ON
BUILD_TESTING ON
Boost_USE_MULTITHREADED ON
Boost_USE_STATIC_LIBS OFF
CBLAS_LIBRARY /usr/lib/libcblas.so
CMAKE_BUILD_TYPE Release
CMAKE_INSTALL_PREFIX /usr/local
Monteverdi_FLOATING_TYPE float
OPENCV_core_LIBRARY /usr/lib/x86_64-linux-gnu/libopencv_core.so
OPENCV_ml_LIBRARY /usr/lib/x86_64-linux-gnu/libopencv_ml.so
OTB_BUILD_DEFAULT_MODULES ON
OTB_DATA_ROOT /data/otb/OTB-Data
OTB_I18N_MERGE_TS OFF
OTB_USE_6S ON
OTB_USE_CURL ON
OTB_USE_GLEW ON
OTB_USE_GLFW ON
OTB_USE_GLUT ON
OTB_USE_GSL OFF
OTB_USE_LIBKML ON
OTB_USE_LIBSVM ON
OTB_USE_MAPNIK OFF
OTB_USE_MPI ON
OTB_USE_MUPARSER ON
OTB_USE_MUPARSERX ON
OTB_USE_OPENCV ON
OTB_USE_OPENGL ON
OTB_USE_OPENMP ON
OTB_USE_QT ON
OTB_USE_QWT ON
OTB_USE_SHARK ON
OTB_USE_SIFTFAST ON
OTB_USE_SPTW ON
OTB_USE_SSE_FLAGS ON
OTB_WRAP_JAVA ON
OTB_WRAP_PYTHON ON
OTB_WRAP_PYTHON3 OFF
Qt5Core_DIR /usr/lib/x86_64-linux-gnu/cmake/Qt5core
...
```
requested version
```
BUILD_EXAMPLES ON
BUILD_TESTING ON
CMAKE_BUILD_TYPE Release
CMAKE_INSTALL_PREFIX /usr/local
OTB_BUILD_DEFAULT_MODULES ON
OTB_DATA_ROOT /data/otb/OTB-Data
OTB_USE_CURL ON
OTB_USE_GLEW ON
OTB_USE_GLFW ON
OTB_USE_GLUT ON
OTB_USE_GSL OFF
OTB_USE_LIBKML ON
OTB_USE_LIBSVM ON
OTB_USE_MAPNIK OFF
OTB_USE_MPI ON
OTB_USE_MUPARSER ON
OTB_USE_MUPARSERX ON
OTB_USE_OPENCV ON
OTB_USE_OPENGL ON
OTB_USE_OPENMP ON
OTB_USE_QT ON
OTB_USE_QWT ON
OTB_USE_SHARK ON
OTB_USE_SPTW ON
OTB_WRAP_JAVA ON
OTB_WRAP_PYTHON ON
OTB_WRAP_PYTHON3 OFF
```https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1675Status of Modules/ThirdParty/ITK/include/*.h files2024-03-20T14:06:55ZJulien MichelStatus of Modules/ThirdParty/ITK/include/*.h files### What changes will be made and why they would make a better Orfeo ToolBox?
We still have a bunch of headers in `Modules/thirdParty/ITK/include/`
```
$ ls -1 Modules/ThirdParty/ITK/include/
itkImageRegionMultidimensionalSplitter.h
it...### What changes will be made and why they would make a better Orfeo ToolBox?
We still have a bunch of headers in `Modules/thirdParty/ITK/include/`
```
$ ls -1 Modules/ThirdParty/ITK/include/
itkImageRegionMultidimensionalSplitter.h
itkImageRegionMultidimensionalSplitter.hxx
itkImageRegionSplitter.h
itkImageRegionSplitter.hxx
itkTransformToDisplacementFieldSource.h
itkTransformToDisplacementFieldSource.hxx
itkUnaryFunctorImageFilter.h
itkUnaryFunctorImageFilter.hxx
```
What is the status of those files ? Are they used ? still needed if we move to 5.0 ?9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1671Remove hard-coded muParser expression library-wise2024-03-20T14:05:37ZJulien MichelRemove hard-coded muParser expression library-wise### What changes will be made and why they would make a better Orfeo ToolBox?
#### High level description
Some filters and classes use the `muParser` based filters with hard-coded expressions. This is bad for at least 2 reasons:
* `muP...### What changes will be made and why they would make a better Orfeo ToolBox?
#### High level description
Some filters and classes use the `muParser` based filters with hard-coded expressions. This is bad for at least 2 reasons:
* `muParser` based filters are not as fast as their functor based counter-parts
* `muParser` is an optional dependency. Using it heavily results in many applications and filters disabled if `muParser` is disabled (see #1670 for instance)
#### Risks and benefits
Only risk might be small changing with floating point baselines.
Benefit is a faster OTB less dependent on muParser.
#### Alternatives for implementations
We need to spot places where `muParser` is mis-used:
```
$ grep -R -l BandMath Modules/ | grep -v BandMath | grep -v Parser
Modules/Applications/AppProjection/app/otbGridBasedImageResampling.cxx
Modules/Applications/AppImageUtils/app/otbCompareImages.cxx
Modules/Applications/AppStereo/app/otbStereoFramework.cxx
Modules/Applications/AppStereo/app/otbBlockMatching.cxx
```
### Who will be developing the proposed changes?
TDB.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1665Add support for WorldView-3 and WV4 to perform radiometric calibration2024-03-20T14:02:11ZManuel GrizonnetAdd support for WorldView-3 and WV4 to perform radiometric calibrationOTB is not able to calibrate WV3 or WV4 images. I suspect that for now OTB will silently instanciate a WorldView-2 image metadata structure which leads to incorrect results.
See discussion on otb-users mailing list:
https://groups.goo...OTB is not able to calibrate WV3 or WV4 images. I suspect that for now OTB will silently instanciate a WorldView-2 image metadata structure which leads to incorrect results.
See discussion on otb-users mailing list:
https://groups.google.com/forum/#!searchin/otb-users/optical$20calibration$20WV3%7Csort:date/otb-users/7G4gbrFZflc/aOGFYV-NAwAJ
I suspect that TOA radiance can be computed but not TOC.
Things that should be done:
- Make otbWorldView2ImageMetadataInterface(https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/blob/develop/Modules/Core/Metadata/include/otbWorldView2ImageMetadataInterface.h) more generic (rename to otbWorldViewImageMetadataInterface) to allow to support WorldView 3 images. The format is almost the same so it makes sense to integrate imagemetadata interface for otb sensors in the same class.
- Check that acquisition parameters (time, sun angles, relative gains and bias per bands) are correctly retrieved from the IMD metadata files for WV3 and 4.
- Tabulate relative spectral response for WV3. Reference data are available here :
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-data/tree/master/Input/Radiometry/DigitalGlobe
Dataset should be resampled with a step of 0.25 nm to be compatible with 6S.
These modifications should allow to compute optical calibration in OTB on WV3 and WV4 images "out of the box" without any parameter settings.
WV3 and WV4 samples should be also added to the OTB Data repository.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1649OTB build performance story2024-03-20T13:59:18ZVictor PoughonOTB build performance storyI have been looking at various refactors to OTB with the goal to improve build time. I am currently working on a branch about this, but I report my work-in-progress here because it might be useful to get some community feedback.
**inclu...I have been looking at various refactors to OTB with the goal to improve build time. I am currently working on a branch about this, but I report my work-in-progress here because it might be useful to get some community feedback.
**include-what-you-use**. I investigated using `include-what-you-use` to remove unnecessary includes. I documented this in issue #1635. I do not plan on working on this further (see issue for details).
**Code in headers**. I think this significantly decreases build times, for example there is a lot of code in `otbWrapperApplication.h` which should go in a cxx. This file is included 99 times in OTB. This is also related to the heavy usage of ITK macros like `itkSetStringMacro`, which each add ~15 lines of code in headers. Used 20 times per class, this can lead to 99*15*20=29700 useless lines of code that the compiler has to process during a full OTB build. It might not seem like much but this is only for one file. I'm not sure the exact
impact but I think it's worth it to try to remove the biggest offenders and see what happens.
A useful command helps to know where to start looking. There are the most included headers:
```
$ ag --nofilename "#include" | sort | uniq -c | sort -n
[...]
191 #include "itkUnaryFunctorImageFilter.h"
230 #include <fstream>
264 #include "otbMacro.h"
323 /*#include "f2c.h"*/
345 #include "otbVectorImage.h"
440 #include <iostream>
626 #include "itkMacro.h"
626 #include "otbImageFileWriter.h"
735 #include "otbImageFileReader.h"
770 #include "otbImage.h"
```
**extern templates**. Extern templates are a C++11 feature which prevent implicit template instantiation. If we provide explicit instantiation in cxx files (that client code then needs to link to), we can reduce the work the compiler needs to do by a huge amount. For example on my develop build, `otb::Image<double, 2u>::GetUpperRightCorner()` is instantiated by the compiler 319 times. One would be enough but each translation unit includes the `txx` code independently. I did a quick prototype for only otbImage, readers and writers and already the build time is significantly reduced (about 15% less on my tests).
A useful command to diagnose this is:
```
$ nm -g --demangle (find . -name "*.o") | sort | uniq -c | sort -n | grep " W otb::"
[...]
957 0000000000000000 W otb::Image<double, 2u>::~Image()
1380 0000000000000000 W otb::ImageFileReaderException::ImageFileReaderException(char const*, unsigned int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
1923 0000000000000000 W otb::ImageRegionAdaptativeSplitter<2u>::~ImageRegionAdaptativeSplitter()
1926 0000000000000000 W otb::ImageRegionSquareTileSplitter<2u>::~ImageRegionSquareTileSplitter()
2070 0000000000000000 W otb::ImageFileReaderException::~ImageFileReaderException()
```
I am working on fixing points 2 and 3 in a branch. If you would like to help let me know.
Any other ideas to improve build time ?
(related to !143)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1533NEW extended file name option: projbox?2024-03-12T17:20:20ZRashad KanavathNEW extended file name option: projbox?I would like to discuss a possibility to have an extended file name option called projbox. I know we already have a bbox variable. a projbox will allow to pass georeferenced coordinates. This is useful in cases when you are dealing with ...I would like to discuss a possibility to have an extended file name option called projbox. I know we already have a bbox variable. a projbox will allow to pass georeferenced coordinates. This is useful in cases when you are dealing with lot of python code or even shell scripts. one can use/plug otb easily into workflow with tools from GDAL / GRASS GIS etc...https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1648Unclear band order with GDAL S2 driver2024-03-12T16:15:17ZVictor PoughonUnclear band order with GDAL S2 driver### Description
The band order when using the GDAL S2 driver without specifiying a subdataset explicitely is completely unclear, leading to user errors. For example:
```
otbcli_BandMath -il S2A_MSIL1C_20180620T040541_N0206_R047_T52XDK_...### Description
The band order when using the GDAL S2 driver without specifiying a subdataset explicitely is completely unclear, leading to user errors. For example:
```
otbcli_BandMath -il S2A_MSIL1C_20180620T040541_N0206_R047_T52XDK_20180620T083057.SAFE/MTD_MSIL1C.xml -exp "im1b1" -out im1b1.tif
```
outputs band B04 (i.e. the third band of the first subdataset).
`gdal_translate` for example, is more explicit and gives an error:
```
$ gdal_translate S2A_MSIL1C_20180620T040541_N0206_R047_T52XDK_20180620T083057.SAFE/MTD_MSIL1C.xml xml.tif
Input file contains subdatasets. Please, select one of them for reading.
```
### Steps to reproduce
See above.
### Configuration information
All.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2066Large Scale GRM status?2024-03-11T09:04:27ZRémi CressonLarge Scale GRM status?Dear all,
I would like to know what is status of Large Scale Generic Region Merging project?
Some users [request this feature](https://forum.orfeo-toolbox.org/t/otb-genericregionmerging/585) in OTB.
I think that it could be a great featu...Dear all,
I would like to know what is status of Large Scale Generic Region Merging project?
Some users [request this feature](https://forum.orfeo-toolbox.org/t/otb-genericregionmerging/585) in OTB.
I think that it could be a great feature indeed. In addition, a great work has been done in implementing it in modern C++, using threads, distributed computation, etc.
A few years ago a bunch of us have worked on [LSOBIA](ttps://github.com/RTOBIA/LSOBIA). Anybody knows the status of this project?
I think it should be doable to propose at least an upgrade of GRM to allow the segmentation of large images, at small cost.
Even if the application is not fully stable, I think that we should at least propose it as beta in next releases.
I believe that the implemented GRM used MPI. But it should be possible to put some MPI stubs or something to allow the compilation without MPI (it could be great that MPI is optional: one could use the GRM on big HPC machines of course, however that's not the case for all OTB users). This way we could ship LS GRM/relevant LSOBIA apps in OTB without adding extra dependencies.
What do you think?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1654Generate CMake config and export targets from remote module build as standalo...2024-03-06T14:43:29ZManuel GrizonnetGenerate CMake config and export targets from remote module build as standalone cmake projectOTB includes a useful extension to ITK remote module mechanisme which allows to build module as a standalone cmake project using the option OTB_BUILD_MODULE_AS_STANDALONE.
The limitation of this mode is that dependency between remote m...OTB includes a useful extension to ITK remote module mechanisme which allows to build module as a standalone cmake project using the option OTB_BUILD_MODULE_AS_STANDALONE.
The limitation of this mode is that dependency between remote modules will NOT be tracked.
Nevertheless, it will be useful if in case of external build, targets and config cmake files can be automaticcally generated by cmake during the module compilatio nto allow to include external remote module in a third part project using a find_package.
For in source build, remote modules cmake targets and config files are correctly generated and added to the OTB build/install tree where modules are deployed. It should not be so difficult to also generate
For instance the config file can be generated with the configure_package_config_file package. The list of targets (libs and applications from the remote module) can perhaps be
This generation can be added to the OTBModuleExternal.cmake file in OTB source tree or added in the OTB module template used generally by otb user to start a new remote module.