otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2022-05-17T06:16:46Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2283VectorClassifier can't read filenames with spaces2022-05-17T06:16:46ZLinusVectorClassifier can't read filenames with spaces### Description
When I train a model with TrainVectorClassifier. I get a correct output in the location I choose.
When I try to use the model (rf, ann, svm) I get the following error:
### Steps to reproduce
Algorithmus beginnt bei: ...### Description
When I train a model with TrainVectorClassifier. I get a correct output in the location I choose.
When I try to use the model (rf, ann, svm) I get the following error:
### Steps to reproduce
Algorithmus beginnt bei: 2022-05-16T10:26:01
Algorithmus VectorClassifier startet…
Eingabeparameter:
{ 'in' : '/Users/linussommer/ownCloud/HiWi 2/GIS Modell/690_5704_statistic.gpkg', 'instat' : '', 'model' : '/Users/linussommer/ownCloud/HiWi 2/GIS Modell/690_5704_svm_model.svm', 'cfield' : '', 'feat' : ['mean_0','stdev_0','min_0','max_0'], 'confmap' : False, 'out' : **'/Users/linussommer/ownCloud/HiWi 2/GIS Modell/output.shp'** }
2022-05-16 10:26:02 (INFO) VectorClassifier: Default RAM limit for OTB is 256 MB
2022-05-16 10:26:02 (INFO) VectorClassifier: GDAL maximum cache size is 409 MB
2022-05-16 10:26:02 (INFO) VectorClassifier: OTB will use at most 4 threads
**Could not read file /Users/linussommer/ownCloud/HiWi**
Execution completed in 2.70 Sekunden
Ergebnisse:
**{'out': '/Users/linussommer/ownCloud/HiWi 2/GIS Modell/output.shp'}**
Lade Ergebnis Layer
Algorithmus 'VectorClassifier' beendet
### Configuration information
QGIS-Version: 3.22.5-Białowieża
QGIS-Codeversion: 2a0a86f142
Qt-Version: 5.14.2
Python-Version: 3.8.7
GDAL-Version: 3.2.1
GEOS-Version: 3.9.1-CAPI-1.14.2
PROJ-Version: Rel. 6.3.2, May 1st, 2020
OTB Version 8.0.0
macOS Catalina 10.15.7https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2273Sentinel-1 metadata reader don't support manifest.safe as input2022-04-13T07:21:11ZMickael SavinaudSentinel-1 metadata reader don't support manifest.safe as inputIf you try to read information from the manifest.safe of a product, `otbcli_ReadImageInfo` return the following warning:
``` bash
otbcli_ReadImageInfo -in /eodata/Sentinel-1/SAR/GRD/2020/08/30/S1A_IW_GRDH_1SDV_20200830T025119_20200830T02...If you try to read information from the manifest.safe of a product, `otbcli_ReadImageInfo` return the following warning:
``` bash
otbcli_ReadImageInfo -in /eodata/Sentinel-1/SAR/GRD/2020/08/30/S1A_IW_GRDH_1SDV_20200830T025119_20200830T025144_034130_03F6BD_0EC0.SAFE/manifest.safe
2022-04-11 09:27:58 (INFO) ReadImageInfo: Default RAM limit for OTB is 256 MB
2022-04-11 09:27:58 (INFO) ReadImageInfo: GDAL maximum cache size is 802 MB
2022-04-11 09:27:58 (INFO) ReadImageInfo: OTB will use at most 4 threads
2022-04-11 09:28:00 (WARNING): Unable to parse XML file /eodata/Sentinel-1/SAR/GRD/2020/08/30/manifest.safe
2022-04-11 09:28:00 (INFO): Loading metadata from official product
2022-04-11 09:28:00 (WARNING): The SensorTransform factory could not find a compatible Sensor Transform
2022-04-11 09:28:00 (WARNING): The SensorTransform factory could not find a compatible Sensor Transform
2022-04-11 09:28:00 (WARNING): The SensorTransform factory could not find a compatible Sensor Transform
2022-04-11 09:28:00 (INFO) ReadImageInfo:
...
```
More information in [S1A_IW_GRDH_1SDV_20200830T025119_20200830T025144_034130_03F6BD_0EC0.SAFE.out](/uploads/7a091af0fccd498becf9b63f2309ec3a/S1A_IW_GRDH_1SDV_20200830T025119_20200830T025144_034130_03F6BD_0EC0.SAFE.out)
OTB don't recognize the fact it is a Sentinel-1!
If you pass directly the tiff file, OTB detect the Sentinel-1 product:
```
otbcli_ReadImageInfo -in /eodata/Sentinel-1/SAR/GRD/2020/08/30/S1A_IW_GRDH_1SDV_20200830T025119_20200830T025144_034130_03F6BD_0EC0.SAFE/measurement/s1a-iw-grd-vh-20200830t025119-20200830t025144-034130-03f6bd-002.tiff
2022-04-11 09:35:29 (INFO) ReadImageInfo: Default RAM limit for OTB is 256 MB
2022-04-11 09:35:29 (INFO) ReadImageInfo: GDAL maximum cache size is 802 MB
2022-04-11 09:35:29 (INFO) ReadImageInfo: OTB will use at most 4 threads
ERROR 1: PROJ: proj_create_from_database: ellipsoid not found
ERROR 1: PROJ: proj_create_from_database: ellipsoid not found
2022-04-11 09:35:31 (INFO): Loading metadata from official product
2022-04-11 09:35:31 (INFO) ReadImageInfo:
Image general information:
Number of bands : 1
Data type : unsigned_short
No data flags : Not found
Start index : [0,0]
Size : [25273,16795]
Origin : [0.5,0.5]
Spacing : [1,1]
Estimated ground spacing (in meters): [10.0425,10.1884]
Image acquisition information:
Sensor : SENTINEL-1A
Acquisition time : 2020-08-30T02:51:19.023121Z
...
```
If you compare to `gdalinfo`, the behavior is the opposite: use the manifest.safe detect the product and its sub-dataset and the tiff not (cf. [Sentinel-1 SAFE driver](https://gdal.org/drivers/raster/safe.html))
For example you can run the following command:
```
gdalinfo SENTINEL1_CALIB:UNCALIB:/eodata/Sentinel-1/SAR/GRD/2020/08/30/S1A_IW_GRDH_1SDV_20200830T025119_20200830T025144_034130_03F6BD_0EC0.SAFE:IW_VH:AMPLITUDE
```
It could be interesting to see how to converge on that to avoid misunderstanding between otb and gdal.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2061Available drivers in Datasource and VectorData2022-04-12T09:42:06ZCédric TraizetAvailable drivers in Datasource and VectorDataThe list of drivers available to open and write vector data is not the same in `otb::VectorData` and `otb::ogr::DataSource`. The lists of (file extensions / driver) are :
* For `otb::ogr::DataSource` :
``` cpp
const ExtensionDriverAss...The list of drivers available to open and write vector data is not the same in `otb::VectorData` and `otb::ogr::DataSource`. The lists of (file extensions / driver) are :
* For `otb::ogr::DataSource` :
``` cpp
const ExtensionDriverAssociation k_ExtensionDriverMap[] = {
{".SHP", "ESRI Shapefile"}, {".TAB", "MapInfo File"}, {".GML", "GML"}, {".GMT", "OGR_GMT"}, {".GPX", "GPX"},
{".SQLITE", "SQLite"}, {".KML", "KML"}, {".CSV", "CSV"}, {".GPKG", "GPKG"}};
```
* For `otb::VectorData` (OGRVectorDataIO)
``` cpp
const std::map<std::string, std::string> m_OGRExtensionsToDrivers = {
{".SHP", "ESRI Shapefile"}, {".TAB", "MapInfo File"}, {".GML", "GML"}, {".GPX", "GPX"}, {".SQLITE", "SQLite"}, {".KML", "KML"},
{".GMT", "OGR_GMT"}, {".GPKG", "GPKG"}, {".JSON", "GeoJSON"}, {".GEOJSON", "GeoJSON"}};
```
This is confusing and limiting for OTB users. Some application are based on `VectorData` and some are base on `otb::ogr::Datasource`.
I think the same list should be used for both classes (the union of the two list). The reading/writing is done by ogr so I don't think there is any limitation on this side.
See this [forum post](https://forum.orfeo-toolbox.org/t/problem-when-saving-geojson-file-with-sampleselection-app/700/2)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2178The projection of the output of HomologousPointsExtraction should be the same...2022-04-12T05:45:56ZJonathan GuinetThe projection of the output of HomologousPointsExtraction should be the same than the input image## Requested feature
The application HomologousPointsExtraction systematically sets the `outvector`, which contains left\right matches, to the WGS84 crs.
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Applicat...## Requested feature
The application HomologousPointsExtraction systematically sets the `outvector`, which contains left\right matches, to the WGS84 crs.
https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Applications/AppDescriptors/app/otbHomologousPointsExtraction.cxx#L511
This is not very natural. And it can lead to some complication, for instance if input images are not projected in WGS84 then raster and vector are not superimposable.
Expected behavior: Setting the output vector to the same projection than the input image.
## Conception
Instead of hard coding the value of [`projref`](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Applications/AppDescriptors/app/otbHomologousPointsExtraction.cxx#L511), we should read it from the input image 1. `std::string projref = image1->GetImageMetadata()->GetProjectedGeometry();`
## Test
A test should be added to assert that the projection of the outputs is correct.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2270Learning - TrainVectorClassifier OTB-8.0 - Fatal Error2022-04-08T17:07:21ZjoaonaimeLearning - TrainVectorClassifier OTB-8.0 - Fatal ErrorRunning **OTB-8.0.0-Linux64** on QGIS 3.22.5. In this version, the only way to select **"Field names for training features"** is by means of check boxes with field names retrieved from training vector file. The text field for typing a li...Running **OTB-8.0.0-Linux64** on QGIS 3.22.5. In this version, the only way to select **"Field names for training features"** is by means of check boxes with field names retrieved from training vector file. The text field for typing a list is not available anymore. Anyway I try the parameters I get this fatal error:
2022-04-05 09:44:45 **(FATAL) TrainVectorClassifier: itk::ERROR: FieldParameter(0x25ad820)**: Value ['b1_stdev', 'b2_stdev'] not found in the list of choices: DN, b1_sum, b1_mean, b1_median, b1_stdev, b1_min, b1_max, b1_varianc, b2_sum, b2_mean, b2_median, b2_stdev, b2_min, b2_max, b2_varianc, Classe.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2268Support metadata option of GDAL as extended filename2022-04-04T14:28:30ZMickael SavinaudSupport metadata option of GDAL as extended filenameAdd the possibility to set metadata key if possible in the output of otb as for GDAL (with `-mo` key cf.https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-mo for gdaltranslate)
It could be useful to set metadata inst...Add the possibility to set metadata key if possible in the output of otb as for GDAL (with `-mo` key cf.https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-mo for gdaltranslate)
It could be useful to set metadata instead of openning the file after writing to set the metadata.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2259Incoherence with GCPs in BurstExtraction and SARDeburst application2022-03-08T07:15:14ZGaëlle USSEGLIOIncoherence with GCPs in BurstExtraction and SARDeburst application### Description
An incoherence is present with GCPs after extracting a burst from a S1 IW products.
GCPs in v8 API, are composed of `GCP` elt (with cartesian coordinates and L/C index) and `GCPTimes`. After a burst extraction, number ...### Description
An incoherence is present with GCPs after extracting a burst from a S1 IW products.
GCPs in v8 API, are composed of `GCP` elt (with cartesian coordinates and L/C index) and `GCPTimes`. After a burst extraction, number of `GCP` elts and `GCPTimes` do not match anymore.
`BurstExtraction` in [SarSensorModel](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/release-8.0/Modules/Core/Transform/src/otbSarSensorModel.cxx#L943) removes some GCPs in order to keep only GCPs which are inside the current burst. This operation was not applied on `SARParam.GCPTimes`. It may have an impact on projection because GCPs are used to in `SarSensorModel`.
`NB : SARDeburst application has the same problem`
### Steps to reproduce
* Apply `SARBurstExtraction` on a given S1 IW product
* Display `GCP` and `GCPTimes` metadata.
For instance :
```
time otbApplicationLauncherCommandLine SARBurstExtraction -in ../../S1A_IW_SLC__1SDV_20171107T025348_20171107T025415_019153_02069A_D2C6.SAFE/measurement/s1a-iw3-slc-vv-20171107t025348-20171107t025413-0
19153-02069a-006.tiff -burstindex 4 -out out_burst_extract_v8.tiff -allpixels true
# Result : 210
gdalinfo out_burst_extract_0_v8.tiff | grep -in "GCPTimes" | wc -l
# Result : SAR.GCP.number=42
gdalinfo out_burst_extract_0_v8.tiff | grep -in "GCP.number"
```
### Configuration information
OS centos 7.9 (HAL), OTB release-8.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2174Synchronize the writing of several products from Python API.2022-01-27T09:27:05ZLuc HermitteSynchronize the writing of several products from Python API.## Feature description
It would be nice to have a way of using multiwriter from Python API without having to define a new application like `AppImageListWriter` in MAJA.
If we consider a flow like the following:
```
+----+ /-------...## Feature description
It would be nice to have a way of using multiwriter from Python API without having to define a new application like `AppImageListWriter` in MAJA.
If we consider a flow like the following:
```
+----+ /--------\ +-----+ /----------------\ +---------+ /------------\ +----------+ /----------\ +-------+
| S1 | --> | to_xyz | --> | XYZ | --> | extractNormals | --> | Normals | --> | computeLIA | --> | LIA | --> | OrthoLIA | --> | S2LIA |
+----+ \--------/ +-----+ \----------------/ +---------+ \------------/ +----------+ \----------/ +-------+
|
|
v
+------------+ /----------\ +----------+
| Sin | --> | OrthoSin | --> | S2Sin |
+------------+ \----------/ +----------+
```
We don't have any way (as of v7.2) to plug extra applications on separate paths after an application that produces several images.
In an ideal world, we could write something like
```python
import otbApplication as otb
to_xyz = otb.Registry.CreateApplication("to_xyz")
to_xyz.SetParameterString("in", "S1")
extract_normals = otb.Registry.CreateApplication("extractNormals")
extract_normals.SetParameterInputImage("in", to_xyz.GetParameterOutputImage("out"))
compute_lia = otb.Registry.CreateApplication("computeLIA")
compute_lia.SetParameterInputImage("in", extract_normals.GetParameterOutputImage("out"))
ortho_lia = otb.Registry.CreateApplication("OrthoLIA")
ortho_lia.SetParameterInputImage("in", compute_lia.GetParameterOutputImage("out.lia"))
ortho_lia.SetParameterString("out", "S2LIA")
ortho_sin = otb.Registry.CreateApplication("OrthoSIN")
ortho_sin.SetParameterInputImage("in", compute_lia.GetParameterOutputImage("out.sin"))
ortho_sin.SetParameterString("out", "S2SIN")
otb.WriteOutputs([ortho_lia, ortho_sin])
```
## Implementation
Add the static function `WriteOutputs` to `otb::Wrapper::Application`.
```c++
void WriteOutputs(std::vector<otb::Wrapper::Application> apps);
```
This function does the same work than MAJA's application `AppImageListWriter`: instantiate an otbMultiImageFileWriter filter, set its parameters and update it.
Add the signature of this function to `Application.i`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/2097On redirecting standard output into a Python logger2022-01-21T14:16:56ZLuc HermitteOn redirecting standard output into a Python logger# TL;DR
We should document that Python bindings require the `sys.stdout` object to provide an `isatty()` method.
This need appears when we try to redirect `sys.stdout` elsewhere, like for instance a Python logger.
# Details
When using...# TL;DR
We should document that Python bindings require the `sys.stdout` object to provide an `isatty()` method.
This need appears when we try to redirect `sys.stdout` elsewhere, like for instance a Python logger.
# Details
When using OTB applications through Python bindings, one may be tempted to redirect OTB logs into the Python logger currently configured for the application.
After a few minutes we find many solutions on stackoverflow or even directly available through pip. But, these solutions will induce a very cryptic error message (sorry I can't remember it, I fixed the issue a long time ago).
By injecting the solution proposed in https://github.com/swig/swig/issues/1117 we can find what goes wrong: the redirected output doesn't provide the `isatty()` method.
I think this requirement should be documented in OTB cookbook in _Python binding_ chapter.
For information a _stdout 2 logger_ redirection compatible with OTB is provided in S1Tiling: https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling/-/blob/eodag/s1tiling/Utils.py#L256
# Side notes
An open question is should we report this patch (for SWIG) (or a similar one, for licensing issues) into `otbApplication.i`?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2194MPI is not initialzed when using the python API2022-01-20T16:34:38ZqueyrutoMPI is not initialzed when using the python API### Description
I installed the [SLIC](https://gitlab.orfeo-toolbox.org/remote_modules/otb-slic) remote module following the official OTB [documentation](https://www.orfeo-toolbox.org/CookBook-8.0/RemoteModules.html#installation-and-usa...### Description
I installed the [SLIC](https://gitlab.orfeo-toolbox.org/remote_modules/otb-slic) remote module following the official OTB [documentation](https://www.orfeo-toolbox.org/CookBook-8.0/RemoteModules.html#installation-and-usage). I built it against an installed OTB on the CNES Hal cluster (OTB v7.2 - python v3.7.2) :
```bash
mkdir /Path/to/Module/build && cd /Path/to/Module/build
cmake -DOTB_DIR=/PathTo/OTB/install -DOTB_BUILD_MODULE_AS_STANDALONE=ON -DCMAKE_INSTALL_PREFIX=/theModulePath/install -DCMAKE_INSTALL_RPATH=/theModulePath/install/lib -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE ../
make install
```
I also updated the following variables:
```bash
export OTB_APPLICATION_PATH=/theModuleInstallFolder/lib:$OTB_APPLICATION_PATH
export PATH=/theModuleInstallFolder/bin:$PATH
```
When I ran the SLIC remote module, I systematically got an MPI error:
```bash
[queyruto@node123 DATA]$ python
Python 3.7.2 (default, Aug 14 2019, 14:00:35)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-36)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import otbApplication
>>> app = otbApplication.Registry.CreateApplication("SLIC")
>>> params = {"in": "SENTINEL2X_all.tif", "out": "SLIC.tif" }
>>> app.SetParameters(params)
>>> app.ExecuteAndWriteOutput()
2021-05-07 15:00:04 (INFO) SLIC: Default RAM limit for OTB is 256 MB
2021-05-07 15:00:04 (INFO) SLIC: GDAL maximum cache size is 0 MB
2021-05-07 15:00:04 (INFO) SLIC: OTB will use at most 24 threads
Auto tiling mode selected, available RAM = 128MB
Number of x tiles = 1
Number of y tiles = 1
Starting segmentation
*** The MPI_Barrier() function was called before MPI_INIT was invoked.
*** This is disallowed by the MPI standard.
*** Your MPI job will now abort.
[node123.sis.cnes.fr:24702] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed!
```
### Steps to reproduce
Follow the steps above.
Note: the OTB that is installed on the CNES HPC is compiled with the MPI support activated.
### Configuration information
OS: Redhat 7
OTB: v7.2 with python 3.7.2
SLIC: clone from the master branch on 2021/05/10.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2251Extended filenames "writegeom" option2022-01-19T14:49:00ZBenjamin TardyExtended filenames "writegeom" option### Description
The extended filenames "writegeom" does not seem to work with OTB 8.0.0 rc1 binaries.
I didn't see anything about this in the [documentation](https://www.orfeo-toolbox.org/CookBook-8.0/ExtendedFilenames.html) or the [ch...### Description
The extended filenames "writegeom" does not seem to work with OTB 8.0.0 rc1 binaries.
I didn't see anything about this in the [documentation](https://www.orfeo-toolbox.org/CookBook-8.0/ExtendedFilenames.html) or the [changelog](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/release-8.0/RELEASE_NOTES.txt).
Does this functionality is only available thanks to ossim ?
### Steps to reproduce
```otbcli_BandMath -il input.tif -exp im1b1 -out "output.tif?&writegeom=true"```
creates a "output.geom" file with OTB 7.4 but no with OTB 8.0
### Configuration information
Linux, OTB 8.0.0 rc1 binarieshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2180Modernize the code of factories in OTB2022-01-13T13:42:02ZThibaut ROMAINModernize the code of factories in OTBShort summary
The current design of factories in OTB can be reworked to be more efficient, and more C++1x compliant.
At the moment we use an old fashioned code to handle concurrency and we register a new factory each time we request an...Short summary
The current design of factories in OTB can be reworked to be more efficient, and more C++1x compliant.
At the moment we use an old fashioned code to handle concurrency and we register a new factory each time we request an object creation. We could use std::once to register our factories once, or use singletons.
This change will not give a significant performance boost because objects instantiation done using factories is only a small part of objects instantiation in OTB, but it is worth modernizing this code to make it safer and easier to understandThibaut ROMAINThibaut ROMAINhttps://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.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/2054DEMToImageGenerator crash / strange output2022-01-07T11:47:25ZLaurențiu NicolaDEMToImageGenerator crash / strange output### Description
I'm trying to run the `DEMToImageGenerator` example, but I feel like I'm missing something.
### Steps to reproduce
```
$ bin/DEMToImageGenerator out.tif outpr.tif 35 50 6000 6000 0.000833333333333 -0.000833333333333 /...### Description
I'm trying to run the `DEMToImageGenerator` example, but I feel like I'm missing something.
### Steps to reproduce
```
$ bin/DEMToImageGenerator out.tif outpr.tif 35 50 6000 6000 0.000833333333333 -0.000833333333333 /Downloads/europe/
2020-05-19 15:01:23 (INFO): Default RAM limit for OTB is 256 MB
2020-05-19 15:01:23 (INFO): GDAL maximum cache size is 795 MB
2020-05-19 15:01:23 (INFO): OTB will use at most 8 threads
2020-05-19 15:01:23 (INFO): Estimated memory for full processing: 549.24MB (avail.: 256 MB), optimal image partitioning: 3 blocks
2020-05-19 15:01:23 (INFO): File out.tif will be written in 4 blocks of 3472x3472 pixels
[~3 minutes later]
Segmentation fault (core dumped)
```
That's the SRTM DEM. With a lower output resolution the output seems random:
```
$ bin/DEMToImageGenerator out.tif outpr.tif 35 50 600 600 0.00833333333333 -0.00833333333333 /Downloads/europe/
```
![image](/uploads/217aed52e83490c6f2c327afdbbe7762/image.png)
![image](/uploads/6f886c0c6de73b8d5357a17754d025d8/image.png)
The coordinates should correspond to the extent of `srtm_44_03.tif`:
```
Data axis to CRS axis mapping: 2,1
Origin = (35.000000000000000,50.000000000000000)
Pixel Size = (0.000833333333333,-0.000833333333333)
Metadata:
AREA_OR_POINT=Area
Image Structure Metadata:
COMPRESSION=DEFLATE
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 35.0000000, 50.0000000) ( 35d 0' 0.00"E, 50d 0' 0.00"N)
Lower Left ( 35.0000000, 45.0000000) ( 35d 0' 0.00"E, 45d 0' 0.00"N)
Upper Right ( 40.0000000, 50.0000000) ( 40d 0' 0.00"E, 50d 0' 0.00"N)
Lower Right ( 40.0000000, 45.0000000) ( 40d 0' 0.00"E, 45d 0' 0.00"N)
Center ( 37.5000000, 47.5000000) ( 37d30' 0.00"E, 47d30' 0.00"N)
```
The output coordinates match that if you account for the difference in precision and/or the pixel convention:
```
Size is 600, 600
Origin = (34.995833333333337,50.004166666666663)
Pixel Size = (0.008333333333330,-0.008333333333330)
Image Structure Metadata:
INTERLEAVE=BAND
Corner Coordinates:
Upper Left ( 34.9958333, 50.0041667)
Lower Left ( 34.9958333, 45.0041667)
Upper Right ( 39.9958333, 50.0041667)
Lower Right ( 39.9958333, 45.0041667)
Center ( 37.4958333, 47.5041667)
```
Also, GDAL seems much faster than OTB even accounting for any resampling:
```
time gdalwarp -te 34.9958333 45.0041667 39.9958333 50.0041667 -r cubic -overwrite ~/Downloads/europe/europe.vrt outgdal.tif
Creating output file that is 6000P x 6000L.
Processing ~/Downloads/europe/europe.vrt [1/1] : 0...10...20...30...40...50...60...70...80...90...100 - done.
gdalwarp -te 34.9958333 45.0041667 39.9958333 50.0041667 -r cubic -overwrite 2.06s user 0.19s system 99% cpu 2.254 total
```
### Configuration information
Ubuntu 18.04, OTB `develop` HEAD, system libs.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2143Crashes in DEMToImageGenerator2022-01-07T11:47:25ZCédric TraizetCrashes in DEMToImageGeneratorDEMToImageGenerator crashes randomly, this has been observed on `ioTvDEMToImageGeneratorFromImageTest` and `ioTvDEMToImageGeneratorFromImageTest2` tests on [CI](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/pipelines/6781). This mi...DEMToImageGenerator crashes randomly, this has been observed on `ioTvDEMToImageGeneratorFromImageTest` and `ioTvDEMToImageGeneratorFromImageTest2` tests on [CI](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/pipelines/6781). This might also be the cause of [this issue](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2054) (DEM example)
I think it is caused by the fact that OGRCoordinateTransformation is [not thread safe](http://osgeo-org.1560.x6.nabble.com/gdal-dev-OGRCoordinateTransformation-Thread-Safety-td5421166.html), but the same OGRCoordinateTransformation is used by different threads in `DEMToImageGenerator`.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2144LargeScaleMeanShift leads to fatal error when asking for sqlite / gpkg as output2022-01-07T11:47:25ZJulien OsmanLargeScaleMeanShift leads to fatal error when asking for sqlite / gpkg as output### Description
As described [on the forum](https://forum.orfeo-toolbox.org/t/largescalemeanshift-sqlite-gpkg-fatal-error/943), the LargeScaleMeanShift application works fine when asked to produce a shapefile, but results in a fatal err...### Description
As described [on the forum](https://forum.orfeo-toolbox.org/t/largescalemeanshift-sqlite-gpkg-fatal-error/943), the LargeScaleMeanShift application works fine when asked to produce a shapefile, but results in a fatal error when asked for an other output format.
### Steps to reproduce
- sqlite
```
$ otbcli_LargeScaleMeanShift -in <otb_source_dir>/Data/Input/QB_1_ortho.tif -spatialr 0.2 -ranger 15 -minsize 10 -mode vector -mode.vector.out output.sqlite -progress 1
[...]
(FATAL) LargeScaleMeanShift: itk::ERROR: Cannot update a feature in the layer <output>:
```
- gpkg
```
$ otbcli_LargeScaleMeanShift -in <otb_source_dir>/Data/Input/QB_1_ortho.tif -spatialr 0.2 -ranger 15 -minsize 10 -mode vector -mode.vector.out output.gpkg -progress 1
[...]
Warning 1: A geometry of type POLYGON is inserted into layer region1_lsms_pca of geometry type MULTIPOLYGON, which is not normally allowed by the GeoPackage specification, but the driver will however do it. To create a conformant GeoPackage, if using ogr2ogr, the -nlt option can be used to override the layer geometry type. This warning will no longer be emitted for this combination of layer and feature geometry type.
(INFO) LargeScaleMeanShift: Merging polygons across tiles ...
ERROR 1: Transaction not established
(FATAL) LargeScaleMeanShift: itk::ERROR: Vectorization(0x1831500): Unable to commit transaction for OGR layer output.
```
- kml works fine
```
$ otbcli_LargeScaleMeanShift -in <otb_source_dir>/Data/Input/QB_1_ortho.tif -spatialr 0.2 -ranger 15 -minsize 10 -mode vector -mode.vector.out output.kml -progress 1
[...]
(INFO) LargeScaleMeanShift: Final clean-up ...
```
But the result contains a lot of attributes set as NULL (nbPixel, etc)
![image](/uploads/aa14cf9f53cad2e627162d0d65db558c/image.png)
- geojson
```
$ otbcli_LargeScaleMeanShift -in <otb_source_dir>/Data/Input/QB_1_ortho.tif -spatialr 0.2 -ranger 15 -minsize 10 -mode vector -mode.vector.geojson output.gpkg -progress 1
[...]
(FATAL) LargeScaleMeanShift: itk::ERROR: No OGR driver known to OTB to create and handle a DataSource named <output.geojson>.
```
### Configuration information
I tried with Ubuntu 18.4 and OTB 7.2 and OTB 7.1. The initial poster on the forum tried on MacOS.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2100otbcli_LargeScaleMeanShift does not cleanup all temporary files2022-01-07T11:47:25Zaloboaotbcli_LargeScaleMeanShift does not cleanup all temporary files### Description
otbcli_LargeScaleMeanShift does not cleanup temporary *FINAL.tif files, even if -cleanup is stated.
Furthermore, in the -mode.vector case, undocumented images *_labelmap.tif and *_labelmap_merged.tif are produced (even i...### Description
otbcli_LargeScaleMeanShift does not cleanup temporary *FINAL.tif files, even if -cleanup is stated.
Furthermore, in the -mode.vector case, undocumented images *_labelmap.tif and *_labelmap_merged.tif are produced (even if -mode.vector.imfield has not been set). It looks like the two labelmap images correspond, respectively, to the unfilterd and filtered versions, but this should be documented (actually, only written if specifically so requested by an specific option).
In the case of -mode.raster, the undocumented *_labelmap.tif image (corresponding to the unfiltered version) is also produced.
### Steps to reproduce
`otbcli_LargeScaleMeanShift.bat -in QB_1_ortho.tif -spatialr 4 -ranger 80 -minsize 16 -tilesizex 256 -tilesizey 256 -cleanup 1 -mode.vector.out regions.shp`
`otbcli_LargeScaleMeanShift.bat -in QB_1_ortho.tif -spatialr 4 -ranger 80 -minsize 16 -tilesizex 256 -tilesizey 256 -cleanup 1 -mode raster -mode.raster.out regions.tif`
### Configuration information
Windows 7, OTB 7.1.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1928LargeScaleMeanshift memory error with OTB6.7.0, works with OTB6.6.12022-01-07T11:47:25ZMichael WessLargeScaleMeanshift memory error with OTB6.7.0, works with OTB6.6.1### Description
We used OTB 6.7.0 for the zonalSTatistics feature, which worked well. When we tried to run LargeScaleMeanshift from the same version, we always got an out of memory error, while LargeScaleMeanshift from OTB 6.6.1 with ex...### Description
We used OTB 6.7.0 for the zonalSTatistics feature, which worked well. When we tried to run LargeScaleMeanshift from the same version, we always got an out of memory error, while LargeScaleMeanshift from OTB 6.6.1 with exactly the same command works without problems. We did not figure out exactly what the problem was, but we used the `-ram` parameter and set `GDAL_CACHEMAX` and `OTB_MAX_RAM_HINT` to exactly the same values in both versions...one worked, the other one didnt.
If important, we ran both tests in an isolated Docker image (docker v1.39) with exactly the same environment, just different OTB versions.
### Configuration information
OTB 6.6.1 and OTB 6.7.0
**edit**: I know 6.7.0 is not final, we used the nightly build; I just thought it mght be still helpful to report this issue!