otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2023-01-19T16:29:59Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2039SensorModel factory for external models2023-01-19T16:29:59ZGuillaume PaseroSensorModel factory for external modelsPart of #1506
This item has a low priority for now, but it will be a real asset in the future.
The idea is to improve the SensorModel factory mechanism to load external sensor models. They should be used in association with the metada...Part of #1506
This item has a low priority for now, but it will be a real asset in the future.
The idea is to improve the SensorModel factory mechanism to load external sensor models. They should be used in association with the metadata entry `MDGeom::SensorModel`. The model is stored as a `boost::any`, the SensorModel will be in charge of its usage and serialization (so that GDAL can read/write the model to its metadata).
The SensorModel should derive from `otb::GenericRSTransform` (after its refactoring).
I don't think we need to include the optimization functions in the SensorModel (`AddTiePoint`, `Optimize`), they can be handled separately. The optimization functions are not top priority in this refactoring.
On the packaging side, we can:
* use a plugin mechanism to detect external sensor models in `lib/otb/plugins`
* use the variable `ITK_AUTOLOAD_PATH` to load the plugins
The tests related to Spot-5 were deactivated while implementing RPC models, because it is not based on RPC but in sensor physical characteristics. When the new SensorModel factory is implemented, those tests need to be reactivated:
- prTvSensorModel_spot5-18.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2261Cannot get the output statistics of ComputeImagesStatistics2022-04-12T05:45:56ZNicolas NarçonCannot get the output statistics of ComputeImagesStatisticsCurrently, the application ComputeImagesStatistics only prints the mean and standard deviation and can optionally save the result inside an XML.
I would like to be able to get the result in Python, as it is possible in ReadImageInfo, so...Currently, the application ComputeImagesStatistics only prints the mean and standard deviation and can optionally save the result inside an XML.
I would like to be able to get the result in Python, as it is possible in ReadImageInfo, something such as:
```python
stats = otbApplication.Registry.CreateApplication('ComputeImagesStatistics')
stats.SetParameterStringList('il', ['image.tif'])
stats.Execute()
mean = stats.GetParameterFloat('mean')
```8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2235Release 8.0.02022-04-12T05:45:56ZJulien OsmanRelease 8.0.0[[_TOC_]]
We are ready to release OTB version 8.0.0. The following steps need to be done:
## Blocking issues/MR
* [x] !865: Update the version of several OTB dependencies in the Superbuild
* [x] !868: Use std::chrono and the date libr...[[_TOC_]]
We are ready to release OTB version 8.0.0. The following steps need to be done:
## Blocking issues/MR
* [x] !865: Update the version of several OTB dependencies in the Superbuild
* [x] !868: Use std::chrono and the date library instead of boost date time as internal types
* [x] !870: Provide access to the metadata from the python API
* [x] !874: Fix segfault in Monteverdi
* [ ] !876
* [ ] !883
## Release Candidate 1
### 1. Branches
* [X] Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [X] Make sure the version number in `CMakeLists.txt` is 8.0.0
### 2. Housekeeping
* [x] In this story, make a list of blocking issues for the release (if any)
* [x] Update release notes (walk the GitLab MR merged history and log all improvements)
* [x] Update the date in RELEASE_NOTES.txt
* [x] Check [SonarQube](https://sonar.orfeo-toolbox.org/dashboard?id=orfeotoolbox-otb)
* [x] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [x] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [x] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [x] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [x] Windows
* [x] Linux
* [x] Mac
* [x] Test QGIS on qgis docker image
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [x] [Tag the release candidate](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [x] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [x] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [x] [Promote staging packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-staging-packages)
* [x] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [x] Cookbook
* [x] Doxygen
* [x] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive)
* [x] Release Candidate announcement on the forum
## Release Candidate 2
### 1. Branches
* [X] Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [X] Make sure the version number in `CMakeLists.txt` is 8.0.0
### 2. Housekeeping
* [x] In this story, make a list of blocking issues for the release (if any)
* [x] Update release notes (walk the GitLab MR merged history and log all improvements)
* [x] Update the date in RELEASE_NOTES.txt
* [ ] Check [SonarQube](https://sonar.orfeo-toolbox.org/dashboard?id=orfeotoolbox-otb)
* [x] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [x] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [x] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [x] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [x] Windows
* [x] Linux
* [x] Mac
* [x] Test QGIS on qgis docker image
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [x] [Tag the release candidate](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [x] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [x] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [x] [Promote staging packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-staging-packages)
* [x] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [x] Cookbook
* [x] Doxygen
* [x] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive)
* [x] Release Candidate announcement on the forum
## Release Candidate 3
### 1. Branches
* [x] Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [x] Make sure the version number in `CMakeLists.txt` is 8.0.0
### 2. Housekeeping
* [x] In this story, make a list of blocking issues for the release (if any)
* [x] Update release notes (walk the GitLab MR merged history and log all improvements)
* [x] Update the date in RELEASE_NOTES.txt
* [ ] Check [SonarQube](https://sonar.orfeo-toolbox.org/dashboard?id=orfeotoolbox-otb)
* [ ] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [ ] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [x] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [ ] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [x] Windows
* [x] Linux
* [x] Mac
* [x] Test QGIS on qgis docker image
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [x] [Tag the release candidate](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [x] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [x] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [x] [Promote staging packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-staging-packages)
* [x] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [x] Cookbook
* [x] Doxygen
* [x] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive)
* [x] Release Candidate announcement on the forum
## Release
### 1. Branches
* [x] Make sure the version number in `CMakeLists.txt` is 8.0.0
### 2. Housekeeping
* [x] In this story, make a list of blocking issues for the release (if any)
* [ ] Fix compilation warnings on CI
* [x] Update release notes (walk the GitLab MR merged history and log all improvements)
* [x] Update the date in RELEASE_NOTES.txt
* [ ] Check [SonarQube](https://sonar.orfeo-toolbox.org/dashboard?id=orfeotoolbox-otb)
* [x] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [ ] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [x] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [ ] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [ ] Windows
* [x] Linux
* [ ] Mac
* [ ] Test QGIS on qgis docker image
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [x] [Tag the release](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [x] Merge the release into develop
* [x] Merge the release into master
* [x] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [x] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [x] [Promote staging packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-staging-packages)
* [x] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [x] Cookbook
* [x] Doxygen
* [x] WordPress page "Home" and "Download" pages
* [x] Upload OTB source archive to [Zenodo](https://zenodo.org/) to create a unique Digital Object Identifier (DOI)
* [ ] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive)
* [x] Release announcement
* [x] On the [forum](https://forum.orfeo-toolbox.org/)
* [x] On the [blog](https://www.orfeo-toolbox.org/blog/)
* [x] On [Twitter](https://twitter.com/orfeotoolbox)
* [x] Forward announcement to news_item@osgeo.org ([OSGeo news](https://www.osgeo.org/foundation-news/))
* [x] Remove public branches related to MR or bugfix merged before the release8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2260Problem for TSX metadata in V8 (parseGeom)2022-04-12T05:45:55ZGaëlle USSEGLIOProblem for TSX metadata in V8 (parseGeom)### Description
DEM projection can raise a seg fault for TSX inputs. A Seg Fault is raised if metadata comes from a geom file (OTB = 7.4)
Hera a [patch](/uploads/eda60d4fa2481c7ef6d6866529428cb1/tsx_metadata.patch) to solve this issue ...### Description
DEM projection can raise a seg fault for TSX inputs. A Seg Fault is raised if metadata comes from a geom file (OTB = 7.4)
Hera a [patch](/uploads/eda60d4fa2481c7ef6d6866529428cb1/tsx_metadata.patch) to solve this issue in 7.4. FYI, I tried to remain compliant with OTB < 7.4 (different keys in geom) but I did not check it.
### Configuration information
OS centos 7.9 (HAL), OTB release-8.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2255Wrong projection in range for S1 IW products2022-03-15T07:09:24ZGaëlle USSEGLIOWrong projection in range for S1 IW products### Description
I have noticed huge differences between v7.4 and v8 projection using `WorldToLineSampleYZ` function from `SarSensorModel`.
A bug is present on [nearRangeTime value](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/bl...### Description
I have noticed huge differences between v7.4 and v8 projection using `WorldToLineSampleYZ` function from `SarSensorModel`.
A bug is present on [nearRangeTime value](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/release-8.0/Modules/Core/Metadata/src/otbSARMetadata.cxx#L194). If the input image has *AzimuthBandwidth*, *RangeBandwidth* or *AzimuthSteeringRate* as metadata, *nearRangeTime* value is wrong.
Here a [patch](/uploads/06c3493ae0e294b8a64277ef418ccfdd/nearRangeTime_correction.patch) to correct this bug. Projection on range dimension seems to be OK with this patch.
### Configuration information
OS centos 7.9 (HAL), OTB release-8.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2256Problem with right_looking_flag on S1 products2022-03-15T07:09:12ZGaëlle USSEGLIOProblem with right_looking_flag on S1 products### Description
Rigth looking flag is always true for S1 products. Old metadata (from v7.4/geom) do not contain a key to specify this flag (such as [support_data.look_side](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/releas...### Description
Rigth looking flag is always true for S1 products. Old metadata (from v7.4/geom) do not contain a key to specify this flag (such as [support_data.look_side](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/release-8.0/Modules/Core/Metadata/src/otbSarImageMetadataInterface.cxx#L300)). Without this key, the flag is set, by default to false.
IMO, we can set this flag to true in `Sentinel1ImageMetadataInterface` : [patch](/uploads/eeeef091657813fb0fc30610410f9434/rightlookingflag_s1_from_geom.patch)
### Configuration information
OS centos 7.9 (HAL), OTB release-8.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2257Problem nb lines/columns in SARBurstExtraction2022-03-15T07:08:59ZGaëlle USSEGLIOProblem nb lines/columns in SARBurstExtraction### Description
A little confusion between *NumberOfLines* and *NumberOfColumns* in `SARBurstExtraction` : [patch](/uploads/9090f64ea919491b5383625c66fe7d66/burst_extraction_correction.patch)
### Configuration information
OS centos 7....### Description
A little confusion between *NumberOfLines* and *NumberOfColumns* in `SARBurstExtraction` : [patch](/uploads/9090f64ea919491b5383625c66fe7d66/burst_extraction_correction.patch)
### Configuration information
OS centos 7.9 (HAL), OTB release-8.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2258Problem for CSK metadata in V82022-03-15T07:08:47ZGaëlle USSEGLIOProblem for CSK metadata in V8### Description
I have noticed a few problems using CSK metadata:
* CSK metadata interface always set HDF5:*filename*://SBI//S01 as image. It does not work if an extraction was made from a CSK product.
* Missing metadata in `parseGDAL` ...### Description
I have noticed a few problems using CSK metadata:
* CSK metadata interface always set HDF5:*filename*://SBI//S01 as image. It does not work if an extraction was made from a CSK product.
* Missing metadata in `parseGDAL` function such as NumberOfColums or GCPTimes
* Missing metadata in `parseGeom`
Here a [patch](/uploads/9a5ca82f7b5266d7734f2cc4252c98e5/csk_metadata.patch).
Let me know if there is a problem.
### Configuration information
OS centos 7.9 (HAL), OTB release-8.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2239Link otb 8.0 with boost2022-03-08T07:15:13ZCédric TraizetLink otb 8.0 with boostSome users are unable to compile eternal code and standalone remote modules against OTB 8.0 without calling find-package Boost first.
I failed to reproduce this bug using the binary package for now
The user was using a compiled versio...Some users are unable to compile eternal code and standalone remote modules against OTB 8.0 without calling find-package Boost first.
I failed to reproduce this bug using the binary package for now
The user was using a compiled version using system libraries in a docker8.0.0Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2233OTB plugin integration in QGIS >= 3.222022-02-07T08:32:43ZYannick TANGUYOTB plugin integration in QGIS >= 3.22### Target documentation resources
CookBook shall be updated to document recent QGIS changes in OTB plugin integration : https://www.orfeo-toolbox.org/CookBook/QGISInterface.html
### Change requested
QGIS 3.22 does not activate any mor...### Target documentation resources
CookBook shall be updated to document recent QGIS changes in OTB plugin integration : https://www.orfeo-toolbox.org/CookBook/QGISInterface.html
### Change requested
QGIS 3.22 does not activate any more OTB plugins (and some others) by default. As OTB plugin is an official plugin, it only needs to be activated (in the Plugins>Manage plugins menu) and then configured (as it used to be, in the Settings>Options menu).
This is a small change but users need to know how to reactivate OTB plugin.
Tests have been done on Ubuntu 20.04 / QGIS 3.22 RC / OTB 8.0a1 and it works fine.8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2240DOC: Improve documentation on how to recompile python bindings2022-02-07T08:32:43ZThibaut ROMAINDOC: Improve documentation on how to recompile python bindingsIn the cookbook, the users don't have the information about the system requirements to rebuild the python bindingsIn the cookbook, the users don't have the information about the system requirements to rebuild the python bindings8.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2221Clean of elevation management geoid parameter2022-02-07T08:32:42ZaurelieemilienClean of elevation management geoid parameter### Description
This issue is a follow up of #2198
In the context of the [cars software](https://github.com/CNES/CARS), we are having troubles to unset the geoid parameter used in the otb applications.
CARS implements two homemade app...### Description
This issue is a follow up of #2198
In the context of the [cars software](https://github.com/CNES/CARS), we are having troubles to unset the geoid parameter used in the otb applications.
CARS implements two homemade applications that use the elevation management:
* [otbDEMReader](https://github.com/CNES/cars/blob/master/otb_remote_module/app/otbDEMReader.cxx) used in a CARS API function called [read_lowres_dem](https://github.com/CNES/cars/blob/master/cars/externals/otb_pipelines.py#L338)
* [otbConvertSensorToGeoPointFast](https://github.com/CNES/cars/blob/master/otb_remote_module/app/otbConvertSensorToGeoPointFast.cxx) used for example in the CARS API function [get_time_ground_direction](https://github.com/CNES/cars/blob/master/cars/core/projection.py#L574)
If several calls of the CARS API function are done in the same run session, the geoid parameter setting is not cleared between each otb application creation and execution. It seems that once `m_GeoidFile` is defined it is not unset when using [`DEMHandler::ClearDEM`](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/release-7.3/Modules/Adapters/OSSIMAdapters/src/otbDEMHandler.cxx#L111).
It might concerned usual otb application too but I couldn't print the geoid file path used by them (CARS also uses the `StereoRectificationGridGenerator` application).
### Steps to reproduce
Two consecutive calls of the application using the elevation management (I only tried with the CARS API function described above), one with the geoid file set and one without. The `m_GeoidFile` should be both time set to the first geoid file.
### Configuration information
Ubuntu, Centos, OTB 7.x (7.2), installation from binary version.8.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2238Need to document how to build a remote module against binary packages2022-02-07T08:32:42ZYannick TANGUYNeed to document how to build a remote module against binary packages### Target documentation resources
CookBook should add a section (or paragraph here : https://www.orfeo-toolbox.org/CookBook-8.0/RemoteModules.html#installation-and-usage)
### Change requested
I've compiled my remote module againt an ...### Target documentation resources
CookBook should add a section (or paragraph here : https://www.orfeo-toolbox.org/CookBook-8.0/RemoteModules.html#installation-and-usage)
### Change requested
I've compiled my remote module againt an installed OTB, I've a "symbol not found" error when I launched the application.
This is due to a very tricky bug, discussed here : https://gitlab.orfeo-toolbox.org/s1-tiling/s1tilingsupportapplications/-/issues/4#note_93605
When I add this flag, it works fine :
`cmake ../../fast-lsd/ -DOTB_BUILD_MODULE_AS_STANDALONE=True -DCMAKE_CXX_FLAGS=-D_GLIBCXX_USE_CXX11_ABI=0`
This workaround should be documented.8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2188Update Superbuild dependencies (major version)2022-01-07T11:15:51ZMickael SavinaudUpdate Superbuild dependencies (major version)Several dependencies can be updated at major level:
- [ ] glew from 1.13.0 to 2.1.0
- [ ] freeglut from 2.8.1 to 3.2.1
- [ ] libjpeg-turbo from 1.4.1 to 2.0.6
- [x] proj from 6.2.1 to 8.0.0
- [ ] qt from 5.11.3 to 6
- [x] swig from 3.0.7...Several dependencies can be updated at major level:
- [ ] glew from 1.13.0 to 2.1.0
- [ ] freeglut from 2.8.1 to 3.2.1
- [ ] libjpeg-turbo from 1.4.1 to 2.0.6
- [x] proj from 6.2.1 to 8.0.0
- [ ] qt from 5.11.3 to 6
- [x] swig from 3.0.7 to 4.0.28.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2187Update Superbuild dependencies (minor version)2022-01-07T11:15:36ZMickael SavinaudUpdate Superbuild dependencies (minor version)Several dependencies can be updated at minor level :
- [ ] Boost from 1.69 to 1.76
- [ ] CURL from 7.54.1 to 7.76.1
- [x] EXPAT from 2.1.0 (or 2.1.1) to 2.3.0 done in release-7.3 and develop
- [x] GEOS from 3.6.1 (or 3.6.5) to 3.9.1
- [...Several dependencies can be updated at minor level :
- [ ] Boost from 1.69 to 1.76
- [ ] CURL from 7.54.1 to 7.76.1
- [x] EXPAT from 2.1.0 (or 2.1.1) to 2.3.0 done in release-7.3 and develop
- [x] GEOS from 3.6.1 (or 3.6.5) to 3.9.1
- [x] geotiff from 1.5.1 to 1.6.0
- [ ] gsl from 2.3.0 to 2.6.0
- [ ] hdf5 from 1.10.1 (1.10.7) to 1.12
- [ ] libjpeg-turbo from 1.4.1 (or 1.4.2) to 1.5.3
- [ ] netcdf-c from 4.7.3 (4.7.4) to 4.8.0
- [x] OPENCV from 4.1.1 (4.1.2) to 4.5.2
- [x] OPENSSL from 1.0.1 to 1.1.1 done in release-7.3 for security reasons
- [ ] OpenSceneGraph from 3.4.0 (3.4.1) to 3.6.5
- [ ] proj from 6.2.1 to 6.3.2.tar.gz
- [x] qt from 5.11.3 to 5.15.2
- [ ] tiff from 4.2.0 to 4.3.0
- [ ] OpenJPEG from 2.3.0 to 2.4.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1974RadiometricIndices description files for QGIS Processing2022-01-07T09:49:51ZPedro VenancioRadiometricIndices description files for QGIS ProcessingHi,
I was trying to use RadiometricIndices application inside QGIS Processing, but the indices are missing from the description file:
```
RadiometricIndices|out
Compute radiometric indices.
Feature Extraction
QgsProcessingParameterRas...Hi,
I was trying to use RadiometricIndices application inside QGIS Processing, but the indices are missing from the description file:
```
RadiometricIndices|out
Compute radiometric indices.
Feature Extraction
QgsProcessingParameterRasterLayer|in|Input Image|None|False
QgsProcessingParameterRasterDestination|out|Output Image
QgsProcessingParameterNumber|channels.blue|Blue Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.green|Green Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.red|Red Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.nir|NIR Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.mir|Mir Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterString|list|Available Radiometric Indices|None|True
*QgsProcessingParameterEnum|outputpixeltype|Output pixel type|uint8;int;float;double|False|2|True
```
Looking at this issue, I don't know if it is easy to implement the 'Available Radiometric Indices' parameter as a multiple selection window (maybe the best approach), but as a workaround before a better approach to be implemented, could be to use OTBParameterChoice for the 'list' parameter:
OTBParameterChoice|list|Available Radiometric Indices|Vegetation:NDVI;Vegetation:TNDVI;Vegetation:RVI;Vegetation:SAVI;Vegetation:TSAVI;Vegetation:MSAVI;Vegetation:MSAVI2;Vegetation:GEMI;Vegetation:IPVI;Vegetation:LAIFromNDVILog;Vegetation:LAIFromReflLinear;Vegetation:LAIFromNDVIFormo;Water:NDWI;Water:NDWI2;Water:MNDWI;Water:NDTI;Soil:RI;Soil:CI;Soil:BI;Soil:BI2;BuiltUp:ISU|0|True
```
RadiometricIndices|out
Compute radiometric indices.
Feature Extraction
QgsProcessingParameterRasterLayer|in|Input Image|None|False
QgsProcessingParameterRasterDestination|out|Output Image|None|False
QgsProcessingParameterNumber|channels.blue|Blue Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.green|Green Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.red|Red Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.nir|NIR Channel|QgsProcessingParameterNumber.Integer|1|True
QgsProcessingParameterNumber|channels.mir|Mir Channel|QgsProcessingParameterNumber.Integer|1|True
OTBParameterChoice|list|Available Radiometric Indices|Vegetation:NDVI;Vegetation:TNDVI;Vegetation:RVI;Vegetation:SAVI;Vegetation:TSAVI;Vegetation:MSAVI;Vegetation:MSAVI2;Vegetation:GEMI;Vegetation:IPVI;Vegetation:LAIFromNDVILog;Vegetation:LAIFromReflLinear;Vegetation:LAIFromNDVIFormo;Water:NDWI;Water:NDWI2;Water:MNDWI;Water:NDTI;Soil:RI;Soil:CI;Soil:BI;Soil:BI2;BuiltUp:ISU|0|True
*QgsProcessingParameterEnum|outputpixeltype|Output pixel type|uint8;int;float;double|False|2|True
```
This way, RadiometricIndices only output one index at a time, to a single band raster. However, QGIS Processing can run the algorithms in batch, and so, it can solve several/all the indices in just one step, but for individual single band rasters, which is not necessarily worst in my point of view.
What do you think?
Best regards,
Pedro Venâncio8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2127OTB 8.0 alpha 1 (Optical image processing) & alpha 2 (SAR image processing) a...2022-01-07T08:58:44ZCédric TraizetOTB 8.0 alpha 1 (Optical image processing) & alpha 2 (SAR image processing) and validation plan
The main goal of release 8.0 is to remove OSSIM from OTB dependencies. This implies the refactoring of a lot of classes and functions, many of which are in the core modules of the library. See [this issue](https://gitlab.orfeo-toolbox....
The main goal of release 8.0 is to remove OSSIM from OTB dependencies. This implies the refactoring of a lot of classes and functions, many of which are in the core modules of the library. See [this issue](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1506 ) for a detailed plan of the refactoring. Before the actual release and release candidates, it is planned to release two alpha versions:
* OTB 8.0.0 alpha-1 : Optical processing, OTB still depends on Ossim, but only use the library in SAR processing
* OTB 8.0.0 alpha-2 : SAR processing, OTB does not depend on Ossim.
As many users do not use the SAR functionnalities of OTB, the first alpha will give them the opportunity to test the refactored functionalities as soon as possible. This includes:
* The Metadata framework
* The DEM Handler
* The radiometry framework (optical calibration and filters)
* The RPC framework
Given the scale of the refactoring, particular attention should be given to the validation of these changes.
Validation plan
## CI validation:
The major part of the validation is done using the OTB CI.
### Metadata framework
See https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/wikis/Remove-OSSIM#the-new-imagemetadata-object
The metadata parsing framework is mainly validated by the tests of the `OTBMetadata` module, in particular :
* `otbImageMetadataTestXXX` tests are used to validate the API of the `ImageMetadata` class.
* `ioTvImageMetadataInterfaceTest` tests are used to validate the `OpticalImageMetadataInterface` classes. All the implemented sensors are tested (one test per sensor).
Broadly speaking, a lot of tests are impacted by the changes in metadata parsing, and non regression on these tests is also used for the validation.
### Radiometry Framework
See https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/wikis/Remove-OSSIM#metadata-parsing
The only API changes in classes related to optical calibration is the use of `ImageMetadata` objects instead of `KeywordLists`. The test have not been modified and the changes are validated by verifying that there are no regression.
### DEM Handler
See https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/wikis/Remove-OSSIM#dem-handler
The `DEMHandler` class API is validated using the `uaTvDEMHandlerXXX` tests, testing DEM request on different configuration (with or without geoids, with or without DEM).
* [ ] TODO: these tests are not at the right place at the moment, they should be moved from the OSSIMAdapters module to the `GDALIO` module.
### The RPC framework
See https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/wikis/Remove-OSSIM#the-new-sensor-model-mechanism
The RPC transforms are now based around the GDAL functions `GDALCreateRPCTransformer` and `RPCTransformPoint`. The `otb::GDALRPCTransformer` (`OTBIOGDAL` module) is a wrapper around these classes. It is tested by the `TuGDALRPCTransformerTest` tests.
The main entry points for these classes are `otb::ForwardRPCTransform` et `otb::InverseRPCTransform`. These classes are used by the `GenericRSTransform` class. See `prTvTestCreateInverseForwardSensorModel` and `prTvGenericRSTransform` tests.
`GenericRSTransform` is used in higher level classes dedicated to geometries class, including ImageWarp filters, stereo filters, orthorectification filters, and vector data projection filters. See the tests from the modules `OTBTransform`, `OTBProjection`, `OTBStereo`, `OTBDisparityMap`, `OTBAppProjection`, `AppVectorDataTranslation` and `OTBDEM`.
As of 2020-12-02, while most tests produce the same results, differences are still observed in some cases. See !744. The regressions could be caused by the different implementations of RPC models in Ossim and GDAL. If it appears to be the case we will need to update the test baselines. In this case it would interesting to validate the refactored RPC models using an external geometry library (which one ?)
RPC validation manual tests:
1) Verify that the transform `geo->sensor->geo` (forward model followed by inverse model), is close to the identity transform, and that the error is negligible compared to the sensor precision
2) Produce GCPs between an ortho-image and the corresponding sensor Image using the Sift algorithm (`HomologousPointsExtraction` application) and use the pair of points to validate the model. For each pair compute the distance in pixel between the Forward transform of the ortho point and the sensor point, and the distance in meters between the Inverse transform of the sensor point and the ortho point. The potential biases of this test are:
* the accuracy of SIFT points
* the accuracy of the model used to compute the orthoimage
* the DEM used to compute the orthoimage
[Some tests](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2040#sar-model) have been disabled. These tests are specific to SAR functionalities that cannot work while the SAR part of OTB has not been refactored.
## Code quality :
We should ensure some quality metrics before the release alpha:
* Fix compilation warnings on all platforms
* Fix Bugs and CodeSmells from SonarQube in new code
* Ensure a good code coverage on new code (which value should we aim at ?)
## Manual testing :
In addition to CI tests. It could be interesting to make additionnal validation tests manually. While OTB tests cover a large parts of use cases, these tests would have several benefits:
* Human based testing might highlight problems that CI have missed (It was the case or [this bug](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/752))
* CI tests are done on small images. Several test are done on full product (Large inputs tests). However these tests never produce full output images, because it would take too much testing time and a lot of disk space. This means that OTB scaling is not tested.
* We could measure performances differences, in particular in RPC based tasks.
The test could be done using the `OpticalCalibration` and `Orthorectifcation` applications. The products from the `OTB-LargeInput` repository could be used. Alternatively, we could use other products (some sample imagery is often available on providers websites).
Example of test procedure:
* Run `OpticalCalibration` on the product
* Visual inspection of the result in a GIS software
* check the metadata of the output product with `gdalinfo -mdd all` (projection, no data if relevant, metadata written in the OTB domain)
* Run the application with OTB 7.2.0 (before the refactoring) and verify that there is no regression using the `CompareImages` application.
The following sensors should be tested:
* Ikonos
* Spot 5
* Spot 6
* Spot 7
* Pleiades
* Worldview 2
* QuickBird 2
* Formosat8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/701OSSIM doesn't support GEOS projection (but GDAL does)2022-01-06T09:35:33ZSébastien DinotOSSIM doesn't support GEOS projection (but GDAL does)_[Mantis Issue 701](https://bugs.orfeo-toolbox.org//view.php?id=701), reported by gpasero, assigned to ghost, created: 2013-04-16_
The GEOS projection (a.k.a. geostationary projection) is not supported by OSSIM.
There is no epsg code at..._[Mantis Issue 701](https://bugs.orfeo-toolbox.org//view.php?id=701), reported by gpasero, assigned to ghost, created: 2013-04-16_
The GEOS projection (a.k.a. geostationary projection) is not supported by OSSIM.
There is no epsg code attached to this projection, but it is defined by a Proj4 string : "+proj=geos +h=35785831.0" . The OGRSpatialReference from GDAL is able to translate this string into a WKT. But the otb::GenericRSTransform is unable to instanciate a transform with this WKT.
When using projections without epsg, OSSIM has its own table to find the correct type (see Utilities/otbossimplugins/gdal/ossimOgcWktTranslator.cpp line 665).
The corresponding WKT is :
```
PROJCS["Geostationary_Satellite",
GEOGCS["GCS_WGS_1984",
DATUM["D_unknown",
SPHEROID["WGS84",6378137,298.257223563]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Geostationary_Satellite"],
PARAMETER["central_meridian",0],
PARAMETER["satellite_height",35785831],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["Meter",1]]
```8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2241Segfault when using several images with no projection In Monteverdi2022-01-04T19:38:51ZCédric TraizetSegfault when using several images with no projection In Monteverdi### Description
Monteverdi crash when trying to open two images with no projection
### Steps to reproduce
```
monteverdi '/mnt/datas/OTB2/otb/Data/Input/StereoMoving.png' '/mnt/datas/OTB2/otb/Data/Input/StereoFixed.png'
```
### Conf...### Description
Monteverdi crash when trying to open two images with no projection
### Steps to reproduce
```
monteverdi '/mnt/datas/OTB2/otb/Data/Input/StereoMoving.png' '/mnt/datas/OTB2/otb/Data/Input/StereoFixed.png'
```
### Configuration information
develop and release-8.0 branches.8.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2226Wrap image metadata in SWIG2022-01-04T19:38:50ZCédric TraizetWrap image metadata in SWIG`ImageMetadata` sgould be wrapped in SWIG so metadata dictionaries can be accessed from Python. This would allow metadata manipulations in Python pipelines.
The whole ImageMetadata API should be exported, along with the metadata key enu...`ImageMetadata` sgould be wrapped in SWIG so metadata dictionaries can be accessed from Python. This would allow metadata manipulations in Python pipelines.
The whole ImageMetadata API should be exported, along with the metadata key enums. In addition, some metadata classes should be wrapped so they can be manipulated from Python (e.g. RPCParam, TimePoint, Duration).
Maybe we could use SWIG typemaps to wrap some of the exported types directly to Python types.8.0.0Julien OsmanJulien Osman