otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2023-05-02T08:08:16Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2325SPOT5 orthorectification fails in 8.0.12023-05-02T08:08:16Zadescamps-aslSPOT5 orthorectification fails in 8.0.1### Description
Applying the orthorectification process in monteverdi fails when the input image is loaded with the following error: "(FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0000024E4F8AD130): No informa...### Description
Applying the orthorectification process in monteverdi fails when the input image is loaded with the following error: "(FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0000024E4F8AD130): No information in the metadata, please set an image with non empty metadata"
I get the same error with the otbcli_Orthorectification program.
It worked in 7.4.1, but fails in 8.0.1 and 8.1.1
### Steps to reproduce
In Monteverdi, open OrthoRectification application and select the SPOT5 image as input. The error should appear in the log tab.
### Configuration information
Tested on :
- 8.1.1 (Windows Monteverdi binary) : fails
- 8.1.1 (Docker cli) : fails
- 8.0.1 (Docker cli) : fails
- 7.4.4 (Windows Monteverdi binary) : ok
SPOT5 image is a Level1A from SPOT World Heritage (002-003_S5_042-247-0_2013-06-07-10-55-23_HRG-1_J_DT_TT)9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2317GridBasedResampling y origin weird behaviour2023-11-28T09:00:59ZJonathan GuinetGridBasedResampling y origin weird behaviourWhen using GridBasedResampling an half pixel shift occurs between user specified value in command and output image, for example :
- user UL : [311000.0, 58818000.000] with spacing [0.5,-0.5] gives an output with origin at [310999.75, 58...When using GridBasedResampling an half pixel shift occurs between user specified value in command and output image, for example :
- user UL : [311000.0, 58818000.000] with spacing [0.5,-0.5] gives an output with origin at [310999.75, 58818000.25]
if we try to compensate that by shifting by an half spacing the input
- user UL : [311000.25, 58817999.75] with spacing [0.5,-0.5] gives an output with origin at [311000.00, 58818000.25]
- user UL : [311000.25, 58817999.74] with spacing [0.5,-0.5] gives an output with origin at [311000.00, 58817999.75]
only N*spacing + spacing/2 ULY seems to be reachable with a spacing set to 0.5
This problem doesn't occur with 5.0 spacing
OTB version : 8.1.0 (same problem with OTB 7.4)
[test_GridBased.tar.gz](/uploads/381e1c6c1487be81ee9d2afb94a225ac/test_GridBased.tar.gz)9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2311Refactoring task for the modularization of OTB2023-11-28T09:00:57ZThibaut ROMAINRefactoring task for the modularization of OTB**New modular architecture**
![otb_9_archi](/uploads/219354ce907b36807efaf3a0e0dfac18/otb_9_archi.png)
**1. Simplify CMake options**
In OTB there is almost 40 cmake options when you call ccmake which is a bit confusing for the average...**New modular architecture**
![otb_9_archi](/uploads/219354ce907b36807efaf3a0e0dfac18/otb_9_archi.png)
**1. Simplify CMake options**
In OTB there is almost 40 cmake options when you call ccmake which is a bit confusing for the average user wanting to compile OTB for his project. A lot of option are about the dependencies of OTB, where you can mix system and superbuild dependencies, which can lead to eratic behaviors which the OTB team can't give a lot of time to debug.
- [x] Propose a simplified approach for the dependencies:
The user who wants to compile OTB will be given two options:
- Use all dependencies from the Superbuild which will be built before OTB
- Use all system dependencies, which will be listed in the cookbook for a one line simple installation
This approach permits to hide all USE_SYSTEM_DEPNAME flags which complicates the cmake process. The user will have to enable or disable the only flag `USE_SUPERBUILD_DEPS` which will activate/deactivate the flags USE_SYSTEM_XXX in the background
- [x] Review of all other cmake variables to determine which ones are mandatory, and which ones can be hidden/removed
- [x] Create OTB_BUILD_CORE, OTB_BUILD_LEARNING ... cmake targets to compile thematic modules
Instead of the current OTBGroup_XXX which is not thematic and can lead to misunderstandings for beginners, we propose to add options which will correspond to the future modules of OTB, which will be packaged with the same name.
**2. New source organisation**
The main idea is to reorganize the modules of OTB in coherent groups, which implies a reorganization of the source code.
Here is an example of a module (Core for example):
- Applications
- Functional_Tests : which will call one or a bunch of applications related to real treatments in production chains
- SubModule1... (For example IO)
- src
- include
- unit_tests
- SubModule2... (For example Common)
- src
- include
- unit_tests
- ...
With this organization, we have the applications related to this module, the tests calling those applications, and a list of submodules which contains filters/C++ classes grouped by theme. These filters are unit tested in each sub module.
To do this reorganization, the following guideline has been done:
- [x] Create a folder for each module (Learning, Stereo, SAR...)
- [x] Move src, include, tests and the related CMakeLists of each submodule to its related module
- [x] Connect CMAKE variables (OTB_BUILD_CORE etc) to the right module folder
- [x] Adapt the declared dependencies of each module in the CMakeLists
- [x] Reactivate the unit tests on the CI for each module
- [x] Reactivate the app tests ont the CI for each module
- [x] Package OTB Core and OTB Full with the current packaging method
- [x] Test the compilation of remote modules with otb core
- [x] move "to be deprecated" apps to a miscellaneous folder
**3. Test refactoring**
All the tests (TU + app) for each modules have been reactivated on the CI. Now it is important to see if all those tests are relevant.
- **Unit test + app tests**
A Lot of baselines and input has been added since the beginning of the project, but some tests have been deprecated. In order to make this refactoring relevant, we will follow this guideline :
- [x] Make a listing of currently used baselines/input files, to see what file is not needed anymore, and if some files are not too old to be relevant.
- [ ] See if there are any non relevant tests
- [ ] Determine which largeInput tests can be transformed into functional tests
- **Use cases for validation (fonctional tests)**
The current LargeInput tests are kind of outdated and not really relevant of real production chains.
The idea is to replace thoses tests with functional tests, containint one or a sequence of applications, which is the case in production chains.
We have to determine real use cases with production teams, to create those functional tests. They will be present in each thematic module.
While the unit test + app tests will be run on the CI, the new functional tests will be run on the HAL cluster
**4. New packaging**
The current packaging of OTB contains everything, all dependencies, all apps... Makeself is currently used to deliver a .run.
At the moment, there is an OTB Core package, and a full OTB package produced by the CI.
The idea is to use CPack which is integrated with cmake, to deliver packages of each OTB modules, that can install along the otb-core package.
For example, a user needs to do some machine learning with OTB, he should then install otb-core package which contains the core modules / apps of OTB and its dependencies, and then he will install otb-ML module, which will be installed in the same install tree.
This modularity permits each user to customize its installation, instead of having a big package while using 50% of it.9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2306BundleToPerfectSensor needs default mode for some PHR images2023-11-28T09:00:59ZYannick TANGUYBundleToPerfectSensor needs default mode for some PHR images### Description
The application BundleToPerfectSensor needs to be in _default mode_ when running on orthorectified PHR images.
If we don't set this mode, there are two messages :
- a warning : OTB does not recognize sensor -> use defa...### Description
The application BundleToPerfectSensor needs to be in _default mode_ when running on orthorectified PHR images.
If we don't set this mode, there are two messages :
- a warning : OTB does not recognize sensor -> use default mode
- the extents of PAN and XS images do not match
When we add the default mode, it works fine.
It had been reproduced with PHR extracts from OTB Workshop dataset, and also from official PHR products (using either the DIMAP or the orthorectified PAN and XS images from the DIMAP).
### Steps to reproduce
These commands were run to obtain a pansharpened orthorectified image : the second way to obtain it needs the default mode to be set.
```
#!/bin/sh
VER=$1
mkdir -p Workshop_Results/Tests_OTB_${VER}/step5_BDS_sensor
mkdir -p Workshop_Results/Tests_OTB_${VER}/step6_ortho
mkdir -p Workshop_Results/Tests_OTB_${VER}/step7_ortho
mkdir -p Workshop_Results/Tests_OTB_${VER}/step8_BDS_ortho
otbcli_BundleToPerfectSensor -inp WorkshopData/preprocessing/phr_pan_osr_mipy.tif -inxs WorkshopData/preprocessi
ng/phr_xs_osr_mipy.tif -out Workshop_Results/Tests_OTB_${VER}/step5_BDS_sensor/PXS_sensor.tif
otbcli_OrthoRectification -io.in Workshop_Results/Tests_OTB_${VER}/step5_BDS_sensor/PXS_sensor.tif -io.out Works
hop_Results/Tests_OTB_${VER}/step6_ortho/PXS_ortho_1.tif
otbcli_OrthoRectification -io.in WorkshopData/preprocessing/phr_pan_osr_mipy.tif -io.out Workshop_Results/Tests_
OTB_${VER}/step7_ortho/pan_ortho.tif
otbcli_OrthoRectification -io.in WorkshopData/preprocessing/phr_xs_osr_mipy.tif -io.out Workshop_Results/Tests_O
TB_${VER}/step7_ortho/xs_ortho.tif
otbcli_BundleToPerfectSensor -inp Workshop_Results/Tests_OTB_${VER}/step7_ortho/pan_ortho.tif -inxs Workshop_Res
ults/Tests_OTB_${VER}/step7_ortho/xs_ortho.tif -out Workshop_Results/Tests_OTB_${VER}/step8_BDS_ortho/PXS_ortho_
default_mode.tif -mode default
```
### Configuration information
OTB 8.1rc29.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2300Allow disconnected builds of remote modules2022-09-05T12:27:17ZStefanBruensAllow disconnected builds of remote modulesAllow/simplify builds of remote modules when no network is available
Currently, OTB requires remote modules to be fetched at cmake configure time. This is problematic for several reasons:
- Build hosts are often isolated for security r...Allow/simplify builds of remote modules when no network is available
Currently, OTB requires remote modules to be fetched at cmake configure time. This is problematic for several reasons:
- Build hosts are often isolated for security reasons
- Fetching git HEAD of a branch makes a build non-reproducible, as HEAD may change
Preferably, OTB would allow to supply remote modules as tarballs (or expanded in the appropriate directory).
Although it is possible to download e.g. https://gitlab.orfeo-toolbox.org/jinglada/temporalgapfilling/-/archive/master/temporalgapfilling-master.tar.bz2 and expand it to the correct directory, this is rejected by `otb_fetch_content` as the tarball does not contain the `.git` subdirectory.
CMake since 3.11 has the [FetchContent module](https://cmake.org/cmake/help/v3.11/module/FetchContent.html) which does everything OTBs homegrown fetch code does, but also allows to disable fetching content using the `FETCHCONTENT_FULLY_DISCONNECTED` cache variable. Using `FetchContent` would require a small bump of the minimum version, from 3.10.2 to 3.11.9.0.0Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2248Roadmap for OTB 9.02023-06-23T04:54:23ZJulien OsmanRoadmap for OTB 9.0### Introduction
During the [OTB User Days](https://www.orfeo-toolbox.org/otb-user-days-2021-plenary-talks-workshops-and-more/), we had the opportunity to talk about the future for OTB. This helped us make some plan regarding the coming...### Introduction
During the [OTB User Days](https://www.orfeo-toolbox.org/otb-user-days-2021-plenary-talks-workshops-and-more/), we had the opportunity to talk about the future for OTB. This helped us make some plan regarding the coming months. This issue is a story aiming at providing a single place to discuss everything that we (as a community) want to do in the scope of 9.0. Please, feel free to comment this issue to enhance the following propositions.
### Scope of OTB 9.0
The purpose of OTB 9.0 will be to improve packaging and maintainability.
#### Remove Qt, the GUI app and Monteverdi
The dependency to Qt makes the OTB package quite heavy, and requires much maintenance. The purpose of this dependency is to provide some nice GUI so user don't have to use the command line. QGIS with [the OTB plugin](https://www.orfeo-toolbox.org/CookBook/QGISInterface.html) allows one to run OTB applications without command line, and even more (display images, save result in memory, etc). So we wondered if the GUI provided with OTB were still relevant. The [survey](https://forum.orfeo-toolbox.org/t/please-participate-to-our-survey-how-do-you-use-otb/872) organized on November 2020 pointed out that very few people used it anyway.
Qt is also required to build Monteverdi. Monteverdi is a tool used for very specific applications, and does it's job very well. However, it hasn't evolved for years. So we decided to stop it's development. It will still be available for download with older version of OTB, but will be removed from OTB's main repository.
Of course, if anyone wants to take over the maintenance of the GUI or Monteverdi, they will be welcome to create a remote module.
#### Remove MacOS support
As MacOs is used by very few people, and Apple is moving to an ARM architecture, it is becoming more difficult to maintain OTB on this platform. Docker is fuly supported on MacOs, so we decided to concentrate on a Linux docker image that people can use on any MacOs.
#### Enhance the DEMHandler to manage huge directory
With OTB 8, when one provides a directory to the DEMHandler, it loads all the content of the directory into memory. If this directory contains a lot of DEM tiles, it can take a long time or even crash. We propose to improve the DEMHandler so it only loads the tiles needed by the process.
### Postponed to OTB 10
### Re-organize the packaging in modules
OTB should be modular, installable via light packages
#### Re-organize the tests
Many unit test relies on heavy data, and should be made a lot simpler.
#### Upgrade to ITK 5.x
ITK is one of OTB's the main dependencies. It's last major version, 5.0, was release on May 2019, and the latest version is 5.2.1 released on August 2021. But OTB still relies on ITK 4.x. The time has come for OTB to catch up. It requires [some adjustments](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/ITK5MigrationGuide.md), but some preliminary work was already done (!194, !528).
~story9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2109Improvement of OTB CI2022-01-10T09:54:18ZCédric TraizetImprovement of OTB CIThe goal of this is issue is to list possible features that would benefit OTB continuous integration. Feel free to comment and add new ideas !
* [ ] #1876: There is no debug build with tests in OTB. In particular this means assertion a...The goal of this is issue is to list possible features that would benefit OTB continuous integration. Feel free to comment and add new ideas !
* [ ] #1876: There is no debug build with tests in OTB. In particular this means assertion are not tested.
* [ ] #2105: Discussion on performance monitoring
* [x] #2094: Job to automatically build and deploy superbuild archives.
* [ ] #2091: Upgrade Linux distributions on CI.9.0.0