otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2022-02-07T08:32:43Zhttps://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/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/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/2237Implement a GetSize() function for the ImageMetadata class2022-01-04T19:38:50ZJulien OsmanImplement a GetSize() function for the ImageMetadata class### Description
With OTB 7.4, I use `keywordlist.GetSize()`. It is not possible with OTB 8.0 and ImageMetadata since it doens't have such a function.### Description
With OTB 7.4, I use `keywordlist.GetSize()`. It is not possible with OTB 8.0 and ImageMetadata since it doens't have such a function.8.0.0Julien OsmanJulien Osmanhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2236Wrap the DEMHandler in Python2022-08-30T13:26:12ZCédric TraizetWrap the DEMHandler in PythonThe DEMHandler is managed by a singleton in OTB. In the Python wrapper the elevation parameters in one application affects the elevation management of the subsequent applications.
It could be interesting to wrap the DEMHandler in Swig s...The DEMHandler is managed by a singleton in OTB. In the Python wrapper the elevation parameters in one application affects the elevation management of the subsequent applications.
It could be interesting to wrap the DEMHandler in Swig so that we can setup the DEMHandler at the wrapper level. I'm thinking of something like:
``` python
import otbApplication as otb
otb.dem.OpenDEMDirectory("/path/to/srtm/dir")
print(otb.dem.GetHeightAboveEllipsoid(lon,lat))
app = otb.Registry.CreateApplication("OrthoRectification")
app.SetParameterString("io.in", "path/to/filename")
app.SetParameterString("io.out", "out.tif")
# we don't have to set the elevation parameters here
app.ExecuteAndWriteOutput()
otb.dem.ClearDEMs()
```8.2.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/2234`GetImageMetaData` of Python API isn't updated after the execution of an app2021-11-26T13:30:25ZNicolas Narçon`GetImageMetaData` of Python API isn't updated after the execution of an app## Short description
When using the Phython API, I noticed that the geographic information returned by GetImageMetaData didn't seem to be updated when using `ExtractROI`.
## Example
Let's consider the case where I want to extract a por...## Short description
When using the Phython API, I noticed that the geographic information returned by GetImageMetaData didn't seem to be updated when using `ExtractROI`.
## Example
Let's consider the case where I want to extract a portion (the red rectangle) of the image `Data/Input/QB_Toulouse_Ortho_XS.tif` :
![image](/uploads/e1fe98f63d2733ee88b8a7ec15b80a47/image.png)
In Python, the code would be :
```python
import otbApplication
image = 'QB_Toulouse_Ortho_XS.tif'
extracted = otbApplication.Registry.CreateApplication('ExtractROI')
extracted.SetParameterString('in', image)
extracted.SetParameterString('mode', 'extent')
extracted.SetParameterString('mode.extent.unit', 'phy')
extracted.SetParameterFloat('mode.extent.ulx', 374200)
extracted.SetParameterFloat('mode.extent.uly', 4829150)
extracted.SetParameterFloat('mode.extent.lrx', 374400)
extracted.SetParameterFloat('mode.extent.lry', 4829000)
```
If I use the python API (https://www.orfeo-toolbox.org/CookBook/PythonAPI.html#interactions-with-otb-pipeline) to get the ImageOrigin of `extracted` :
```python
extracted.Execute()
extracted.GetImageOrigin('out')
```
it returns [374200.0805558205,4829150.094438392], which is what I expected
However, if I use this python API to get the Upper Left coordinates of `extracted`, via `GetImageMetaData` method :
```python
extracted.Execute()
print(extracted.GetImageMetaData('out')['UpperLeftCorner'])
```
The result is (374149.9805558205, 4829183.994438391), whereas I was expecting (374200, 4829150).
Is it normal that the dictionary of `GetImageMetaData` is not updated ? Am I supposed to use it or should I stick to GetImageOrigin, GetImageSpacing etc... ?https://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/22328.0.0-alpha2 fails to build without Python2021-11-08T09:17:16ZBas Couwenberg8.0.0-alpha2 fails to build without PythonOTB 8.0.0-alpha2 fails to build without Python.
The issue is fixed by only looking for Python when `OTB_WRAP_PYTHON` is enabled:
[python.patch](/uploads/7639a2c054f6f182dd2ed6a957d572cd/python.patch)OTB 8.0.0-alpha2 fails to build without Python.
The issue is fixed by only looking for Python when `OTB_WRAP_PYTHON` is enabled:
[python.patch](/uploads/7639a2c054f6f182dd2ed6a957d572cd/python.patch)8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2231Exception when reading TerraSAR-X MGD products in OTB 7.42022-01-10T09:20:41ZCédric TraizetException when reading TerraSAR-X MGD products in OTB 7.4There is a regression in OTB-7.4 when trying to open a TerraSAR-X `MGD` products in OTB 7.4:
```
otbcli_ReadImageInfo -in UPSALA_GLACIER/TSX1_SAR__MGD/IMAGEDATA/IMAGE_HH_SRA_strip_012.tif
2021-10-27 10:16:01 (INFO) ReadImageInfo: Defaul...There is a regression in OTB-7.4 when trying to open a TerraSAR-X `MGD` products in OTB 7.4:
```
otbcli_ReadImageInfo -in UPSALA_GLACIER/TSX1_SAR__MGD/IMAGEDATA/IMAGE_HH_SRA_strip_012.tif
2021-10-27 10:16:01 (INFO) ReadImageInfo: Default RAM limit for OTB is 256 MB
2021-10-27 10:16:01 (INFO) ReadImageInfo: GDAL maximum cache size is 793 MB
2021-10-27 10:16:01 (INFO) ReadImageInfo: OTB will use at most 12 threads
2021-10-27 10:16:01 (FATAL) ReadImageInfo: Caught std::exception during application execution: No 'col' subnode found
```
Opening `SSC` products works fine.
Probably caused by the integration a the new TSX model in https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/828
Note that it is possible to open the product in the develop branch (OTB-8.0) and in OTB 7.37.4.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2230BurstExtraction and GCPs2021-10-25T16:01:05ZCédric TraizetBurstExtraction and GCPsThe `BurstExtraction` application extracts a single burst from a Sentinel 1 SLC product and update the metadata accordingly. In particular, only the GCPs inside the burst are kept in the extracted image. However it appears that in some c...The `BurstExtraction` application extracts a single burst from a Sentinel 1 SLC product and update the metadata accordingly. In particular, only the GCPs inside the burst are kept in the extracted image. However it appears that in some case the output burst contains no GCP. A SAR model needs at least one GCP as it serves as the initial guess in `LineSampleToWorld` and `LineSampleHeightToWorld` methods.
For example the product `S1A_IW_SLC__1SDH_20211024T122521_20211024T122540_040261_04C531_CFB3` (available on Copernicus hub) has 6 bursts but the last burst contains no GCP. The last burst lies between lines 7539 and 9005, and between samples 0 and 20175. Some GCPs are very close to the burst, e.g. [line 7358 sample 13143 ] and [line 9023 sample 14154].
The bug can be reproduced with the lines:
```
otbcli_SARBurstExtraction -in /datas/S1Data/S1A_IW_SLC__1SDH_20211024T122521_20211024T122540_040261_04C531_CFB3.SAFE/measurement/s1a-iw1-slc-hh-20211024t122521-20211024t122538-040261-04c531-001.tiff -burstindex 5 -out /tmp/outburstextract.tif
```
to extract the burst, then
```
bin/otbcli_OrthoRectification -io.in /tmp/outburstextract.tif -io.out /tmp/outortho.tif -opt.gridspacing 10
```
will produce a segfault.
This happens on both OTB-7.4 and develop (8.0).
I don't know how frequent the problem occurs in S1 product, and I'm also not sure how we should handle it. A solution would be to keep all gcps in the extracted image (but this is not ideal because most GCP will not be used, the number of GCP is linked to the processing time of `LineSampleToWorld`, as it is initialized by searching the closest GCP in the metadata). We could also only keep the GCPs within a margin around the burst of interesthttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2229Problems with Sentinel 1 product reading2021-10-29T19:20:49ZCédric TraizetProblems with Sentinel 1 product readingSeveral problems occurs when reading Sentinel 1 product (from different sources)
* Some optional SAR metadata are not present in geom files generated with ossimPlugins v2 (not that v1 is not supported in OTB 7.4). With the current devel...Several problems occurs when reading Sentinel 1 product (from different sources)
* Some optional SAR metadata are not present in geom files generated with ossimPlugins v2 (not that v1 is not supported in OTB 7.4). With the current develop version, application crashes when trying to open such files.
* Serializing SLC products does not work. the SAR model is not correctly instantiated when Re-reading the metadata from the output of another application:
```
SarSensorModel::projToSurface(): singular matrix can not be inverted. Returning best estimation so far([2.14272e+14, 7.62494e+14, -9.74559e+13]) for output point ([805613, 2.42829e+06])
```https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2228Write no data as output in applications2021-11-05T10:49:26ZCédric TraizetWrite no data as output in applicationsSome applications still uses the itk::MetadataDictionary to store nodata information. While this work during the application, the metadata is not written in the output image at then end of the pipeline. For example this is the case with ...Some applications still uses the itk::MetadataDictionary to store nodata information. While this work during the application, the metadata is not written in the output image at then end of the pipeline. For example this is the case with the `Orthorectification` application.
Instead, the metadata `MDNum::NoData` should be used consistently inside the library8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2227OTB develop version name2022-08-30T13:26:19ZCédric TraizetOTB develop version nameThe command line applications display the current OTB version. For example in OTB 7.4.0 the following message appears when calling an application:
```
This is the EdgeExtraction application, version 7.4.0
```
In between version the sam...The command line applications display the current OTB version. For example in OTB 7.4.0 the following message appears when calling an application:
```
This is the EdgeExtraction application, version 7.4.0
```
In between version the same message is displayed, for example the current develop branch also return version 7.4.0. It would be interesting to print the next minor or major version, as well as the current branch name and commit sha for these versions. For example the current develop version would return
```
This is the EdgeExtraction application, version 8.0.0-develop-de58687e
```8.2.0https://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 Osmanhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2225-Wdeprecated-copy does not exist in Clang 6.0.02021-10-05T14:33:40ZCédric Traizet-Wdeprecated-copy does not exist in Clang 6.0.0in MR !786, the line
``` cpp
#pragma GCC diagnostic ignored "-Wdeprecated-copy"
```
has been added to several files to filter warnings, in particular coming from Shark and Ossim includes.
However this option has only been added in [g...in MR !786, the line
``` cpp
#pragma GCC diagnostic ignored "-Wdeprecated-copy"
```
has been added to several files to filter warnings, in particular coming from Shark and Ossim includes.
However this option has only been added in [gcc 9](https://gcc.gnu.org/gcc-9/changes.html) and [clang 10.0](https://releases.llvm.org/10.0.0/tools/clang/docs/ReleaseNotes.html#improvements-to-clang-s-diagnostics). This produces a warning when compiling OTB with an older version of clang:
```
../Modules/Core/Transform/src/otbSarSensorModelAdapter.cxx:31:32: warning: unknown warning group '-Wdeprecated-copy', ignored [-Wunknown-warning-option]
```
In particular in CI we still use an old version of clang (6.0) to compile OTB, resulting in this warning.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2224Crash on otbcli_SARCartesianMeanEstimation on SLC IW images2022-01-07T10:15:45Zfabien contivalCrash on otbcli_SARCartesianMeanEstimation on SLC IW imagesA crash occured in automatic multithread (streaming activated) mode during process :
(FATAL) SARCartesianMeanEstimation: itk::ERROR: MultiThreader(0x1401ba0): Exception occurred during SingleMethodExecute
When desactivating streaming, ...A crash occured in automatic multithread (streaming activated) mode during process :
(FATAL) SARCartesianMeanEstimation: itk::ERROR: MultiThreader(0x1401ba0): Exception occurred during SingleMethodExecute
When desactivating streaming, a Region image error is added to the previous message(specific here to the input image chosen):
itk::ERROR: Region ImageRegion (0x7ffebf5b1bf0)
Dimension: 2
Index: [1852, 5500]
Size: [4346, 899]
is outside of buffered region ImageRegion (0x2d15240)
Dimension: 2
Index: [1852, 5500]
Size: [4342, 883]
=>This bug could be linked to the problem of metadata reading for SLC IW images than the issue #2220.
example:
otbcli_SARCartesianMeanEstimation -indem michigan8/N44W084-N44W085-N44W086-N44W087-N45W084-N45W085-N45W086-N45W087.vrt -insar /work/ALT/swot/swotdev/contivf/michigan/S1B_IW_SLC__1SDV_20210404T233244_20210404T233311_026324_032454_D678/S1B_IW_SLC__1SDV_20210404T233244_20210404T233311_026324_032454_D678.SAFE/measurement/s1b-iw1-slc-vh-20210404t233246-20210404t233311-026324-032454-001.tiff -indemproj michigan8/s1_onto_dem_s1b-iw1-slc-vh-20210404t233246-20210404t233311-026324-032454-001.tiff -mlran 1 -mlazi 1 -indirectiondemc -1 -indirectiondeml 1 -out michigan8/dems-onto-S1-030704.tiffhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2223Poor performance with VRT datasets2021-09-15T10:01:28ZLaurențiu NicolaPoor performance with VRT datasetsFor some reason, VRTs are much slower in OTB than in GDAL. I tested concatenating the same 10980x10980 file 100 times into a single one, and the equivalent with a single VRT as an input:
```
gdal_merge.py tiff -> tiff
18.41user 69.03sys...For some reason, VRTs are much slower in OTB than in GDAL. I tested concatenating the same 10980x10980 file 100 times into a single one, and the equivalent with a single VRT as an input:
```
gdal_merge.py tiff -> tiff
18.41user 69.03system 2:32.27elapsed 57%CPU (0avgtext+0avgdata 4650728maxresident)k
gdal_translate vrt/ComplexSource -> tiff
120.56user 11.24system 2:13.08elapsed 99%CPU (0avgtext+0avgdata 3342704maxresident)k
gdal_translate vrt/SimpleSource -> tiff (!)
15.50user 9.70system 0:25.28elapsed 99%CPU (0avgtext+0avgdata 3342984maxresident)k
otbConcatenateImages tiff -> tiff
224.53user 16.34system 1:39.64elapsed 241%CPU (0avgtext+0avgdata 3966920maxresident)k
otbConcatenateImages vrt/ComplexSource -> tiff
643.76user 325.83system 17:02.93elapsed 94%CPU (0avgtext+0avgdata 2179636maxresident)k
otbConcatenateImages vrt/SimpleSource -> tiff
807.17user 224.81system 13:10.33elapsed 130%CPU (0avgtext+0avgdata 1449820maxresident)k
otbConcatenateImages vrt/SimpleSource -> tiff, streaming:type=stripped
208.19user 27.56system 1:39.00elapsed 238%CPU (0avgtext+0avgdata 612944maxresident)k
plain gdal tiff -> tiff
35.26user 27.61system 0:30.50elapsed 206%CPU (0avgtext+0avgdata 3386168maxresident)k
plain gdal vrt/ComplexSource -> tiff
326.27user 20.42system 0:40.57elapsed 854%CPU (0avgtext+0avgdata 3415156maxresident)k
plain gdal vrt/SimpleSource -> tiff
35.78user 22.72system 0:30.32elapsed 192%CPU (0avgtext+0avgdata 3400296maxresident)k
```
The last implementation is a very simple one, intended to work as a baseline. It reads input blocks (regions, not TIFF blocks) in parallel, writes an output block, then repeats.
The numbers above should be on a warm cache. The inputs and output are striped with pixel interleaving. Band interleaving is yet faster, but I only have numbers for the last one.
This is caused by OTB picking a wrong tile size.
```
tiff:
(INFO): File merged.tif will be written in 999 blocks of 10980x11 pixels
vrt:
(INFO): File merged.tif will be written in 841 blocks of 384x384 pixels
```
Actually, GDAL reports a wrong block size (128x128). GDAL 3.3 supports setting the block size on the VRT bands, which can be another workaround.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2222Question about haralick module and in particular the "normalisation" aspect2022-01-27T07:42:28Zaline deprezQuestion about haralick module and in particular the "normalisation" aspect### Description
I become aware with different processing on different S2 images that the values obtained within a same image are not independent.
Indeed when there is snow or cloud,… on a part of the image, it seems that a bias appears ...### Description
I become aware with different processing on different S2 images that the values obtained within a same image are not independent.
Indeed when there is snow or cloud,… on a part of the image, it seems that a bias appears for the values on the all image.
After a discussion bu e-mails with Julien Michel, he assumes that it is perhaps a bug.
Could you please tell me more about the way of the computation of haralick feature computation ?
And perhaps (if the behavior of the module is normal) give me some advices of pre and/or post processing in order to obtain comparable values over time on my area of interest whatever the spectral content of the other parts of the image.
Thanks a lot for your help
Aline Déprezhttps://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 Traizet