otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2022-01-07T09:56:32Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2203Improve the documentation of the RAM parameter2022-01-07T09:56:32ZCédric TraizetImprove the documentation of the RAM parameterA "ram" parameter is available in many OTB applications, it is documented as
> ram: Available memory for processing (in MB).
An environment variable `OTB_MAX_RAM_HINT` is also available :
> OTB_MAX_RAM_HINT: Default maximum memory th...A "ram" parameter is available in many OTB applications, it is documented as
> ram: Available memory for processing (in MB).
An environment variable `OTB_MAX_RAM_HINT` is also available :
> OTB_MAX_RAM_HINT: Default maximum memory that OTB should use for processing, in MB. If not set, default value is 128 MB.
The role of these parameters is to control the ram value used to determine the number of streaming block created by a writer (ImageFileWriter or virtual writer). It is compared by the memory print computed by the writer: the sum of the size of each intermediate filter output multiplied by the pixel size (in byte), for a requested region of a given size.
If we consider that the size of all non image C++ objects created by the application is negligible compared to the ram parameter, the ram parameter effectively controls the RAM used by the OTB application. In the common case of an application instantiating only a few filters and producing an output image, this assumption is probably reasonable). But in some applications, there are other voluminous objects that are not taken into account in the total RAM footprint. In this case the documentation of the ram parameter is misguiding because the total RAM used will be higher than the set RAM.
I think we should update the documentation to clarify what the effect of this parameter really is.
This also applies to the log:
> (INFO): Estimated memory for full processing: 41.1034MBhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2202Deprecated GDAL python scripts in OTB 7.3 binaries (Linux)2023-08-24T08:49:39ZYannick TANGUYDeprecated GDAL python scripts in OTB 7.3 binaries (Linux)### Description
As reported [here](https://forum.orfeo-toolbox.org/t/otb-7-x-and-osgeo-gdal-python-wrapper-lib/1097), it seems that OTB 7.3 binaries (at least on Linux) don't contain GDAL python scripts (gdal*.py).
The python scripts in...### Description
As reported [here](https://forum.orfeo-toolbox.org/t/otb-7-x-and-osgeo-gdal-python-wrapper-lib/1097), it seems that OTB 7.3 binaries (at least on Linux) don't contain GDAL python scripts (gdal*.py).
The python scripts indicate that they had been deprecated...
### Steps to reproduce
1. Install OTB 7.3 from the binary package
2. Source the environment file
3. Try to launch a GDAL script (for instance, gdalmove.py)
### Configuration information
Linux Ubuntu 18.04, OTB 7.3 (binaries)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2198Elevation management tricky bugs2022-01-07T11:47:23ZEmmanuel DuboisElevation management tricky bugs### Description
Discussing with @ytanguy , I open a bug happening in [cars](https://github.com/CNES/CARS) 3D software.
We are using several OTB applications and it occurs that there are tricky behaviors when using elevation management ...### Description
Discussing with @ytanguy , I open a bug happening in [cars](https://github.com/CNES/CARS) 3D software.
We are using several OTB applications and it occurs that there are tricky behaviors when using elevation management API.
When using only one time or with the same dem, geoid or default_alt, the problem doesn't appear
But using several apps (different or not) with elevation interface seems to not reproduce the same results.
It appears that the first setting is not reset and we cannot put another one in next apps which takes.
This behavior is difficult to detect. For instance, the default_alt is not changing the result if elev.dem is set before.
The default_alt is not stable when already used in another app, ...
Is there a way to reset the elevation management information between two apps usage ?
Thanks by advance. First Bug in OTB so don't hesitate to react, change this content if not clear.
Emmanuel
### Steps to reproduce
Take an OTB application with elevation management (Example ImageEnvelop) and launch it two times with two dem different and check values with Python interface in the same code.
Take two OTB application with elevation management (Example ImageEnvelop and ConvertSensorToGeoPoint) and see standalone results and when the two apps are sequenced in the same python file.
Reproducibility: always
### Configuration information
Ubuntu, Centos, OTB 7.x (7.2), installation from binary version.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/2191Wrong results using the neural network classifier2022-01-07T10:17:55ZCédric TraizetWrong results using the neural network classifierSee https://forum.orfeo-toolbox.org/t/trainvectorclassifier-returns-no-result-when-using-artificial-neural-network/1022/2
Models trained with `TrainVectorClassifier` using the ann classifier (OpenCV neural network) produce wrong results...See https://forum.orfeo-toolbox.org/t/trainvectorclassifier-returns-no-result-when-using-artificial-neural-network/1022/2
Models trained with `TrainVectorClassifier` using the ann classifier (OpenCV neural network) produce wrong results. When the application computes the confusion matrix after the training part, all samples are classified as the first class, even when using the training dataset as validation dataset.Cédric TraizetCédric Traizethttps://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/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/2176Incorrect epipolar size in StereoRectificationGridGenerator2021-11-08T10:04:04ZsteuxyoIncorrect epipolar size in StereoRectificationGridGenerator### Description
We noticed an error in the epipolar sizes generated by the `StereoRectificationGridGenerator` function when the pixel size in not 1.
This leads to an error when followed by the `GridBasedImageResampling` function, using ...### Description
We noticed an error in the epipolar sizes generated by the `StereoRectificationGridGenerator` function when the pixel size in not 1.
This leads to an error when followed by the `GridBasedImageResampling` function, using the outputs `epi.rectsizex` `epi.rectsizey` `epi.baseline` for example. These outputs are incoherent with the generated grid.
Epipolar `mean_spacing` is not returned by `StereoRectificationGridGenerator`, therefore epipolarsize is not enough to parametrize `GridBasedImageResampling`
### Steps to reproduce
If you chain `StereoRectificationGridGenerator` with `GridBasedImageResampling` using the generated epiplar sizes :
- Using an image with the pixel resolution of 1 :
image size : 500 x 500
the resampled epipolar image 612 x 612 :
<img src="/uploads/845de0f50fd94e9d7f78d2b74cbfdb92/image.png" width="250" >
- Using an image with the pixel resolution of 2 ( for example generated resampling the previous image):
image size : 225 x 225
the resampled epipolar image 306 x 306 :
<img src="/uploads/d9b20a14256b1c2b1721fe6cbe00b17a/image.png" width="300">
- Using an image with the pixel resolution of 0.5 :
image size : 1000 x 1000
the resampled epipolar image 1225 x 1225 :
<img src="/uploads/7b144080e73e5c5f602499b448c06bd9/image.png" width="200">
### Configuration information
- Unix
- otb/7.0-python3.7.2
- otb-depends/7.0-python3.7.2https://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/2171Support reading products from virtual file system2022-01-07T09:48:59ZMickael SavinaudSupport reading products from virtual file systemAs described by GDAL [here](https://gdal.org/user/virtual_file_systems.html), EO products are delivered as archive and in parallel more and more stored on network (in object storage for example).
Currently (with 8.0.0-alpha1) even if a...As described by GDAL [here](https://gdal.org/user/virtual_file_systems.html), EO products are delivered as archive and in parallel more and more stored on network (in object storage for example).
Currently (with 8.0.0-alpha1) even if a part of metadata are read with GDAL, we use specific code to retrieve the missing metadata. This code don't support virtual file system although the GDAL part yes. For example, you can made otbcli_ReadImage on a Sentinel-1 data in an archive and retrieve some metadata thanks to GDAL but not from the OTB part.
It would be nice to support this virtual file system in the OTB metadata. With that we can run an ortho on the Pleiades data without unarchive the product or run SARCalibration on a Sentinel1 data store in an object storage.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2166Severe insufficiencies in the documentation of Connected Components Segmentation2021-03-03T15:11:22ZaloboaSevere insufficiencies in the documentation of Connected Components Segmentation
It is impossible to use the application Connected Components with the current documentation.
If this documentation is not going to be improved, it would be better to remove this application from the package or at least label it as "seve...
It is impossible to use the application Connected Components with the current documentation.
If this documentation is not going to be improved, it would be better to remove this application from the package or at least label it as "severely under-documented": in its current situation, the user just wastes time trying it and never gets any meaningful result.
Yannick recognized in Feb 2020 (https://forum.orfeo-toolbox.org/t/segmentation-bias-towards-rivers/563/3): "OBIA expressions are not very well documented in OTB" (they are actually not documented at all) and said he was "going to open an issue to improve documentation of this application". I have not been able to find any issue related to this in GitLab, so I'm doing it here.
In the same message, Yannick could just suggest https://wiki.orfeo-toolbox.org/index.php/Connected_component_segmentation_module a page that was last modified on 14 March 2013 !!!
(BTW, where is the nice interactive GUI that is reproduced on that page?)
Problems I have found in the documentation (https://www.orfeo-toolbox.org/CookBook/Applications/app_ConnectedComponentSegmentation.html?highlight=connected):
* "For instance, expression “((b1>80) and intensity>95)” will merge two neighbouring pixel in a single segment if their intensity is more than 95 and their value in the first image band is more than 80. See parameters documentation for a list of available attributes"
* Where is "intensity" defined? Is it the sum or the mean of a given pixel across all bands?
* Where is the "parameters documentation" that the user is supposed to consult?
* Regarding OBIA, the only documentation is
```
OBIA Expression -obia string
OBIA mathematical expression
```
along with the example:
`"-obia "SHAPE_Elongation>8"`
Where is the documentation on valid OBIA expressions?
Problems I have found in the wiki page (https://wiki.orfeo-toolbox.org/index.php/Connected_component_segmentation_module)
* The wiki page refers to the ITK Software guide for the "computed attributes". Considering that such a guide is a 985 pp document, at least the appropriate section should be stated. Actually, I have ve not been able to locate any info related to these attributes in that guide...
* The wiki page states "intensity of each pixel is accessible by intensity (arithmetic mean of pixel band)." This definition is likely to be wrong, I understand the author meant "intensity of a pixel = mean(b1, b2, b3...) for that pixel", so I understand there is a missing "s" in the writing
"(arithmetic mean of pixel bandS)": with no final "S", intensity would be understood as the average of a given band over all pixels. Sometimes a single "s" may mean a lot, and a formal notation would be less ambiguous.
* The wiki page states: "intensity_p1 (intensity_p2) : mean intensity of first pixel (resp. second pixel)."
* What is meant by "first pixel"??? first of what?
* The wiki page states: "pXbY : Band Y value of pixel X."
* How is "X" stated? An example is required here.
* The wiki page states: "spectralAngle : Spectral angle between adjacent pixels (first pixel is set as reference)."
* is it really spectral angle or its cosinus? if angle, radians? degrees?
* "SHAPE_Flusser01" to "SHAPE_Flusser11" appear in the wiki page, what is that???https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2165Hoover Compare Segmentation: simplify output raster2021-03-03T12:22:24ZaloboaHoover Compare Segmentation: simplify output rasterShort summary of the requested feature
In Hoover Compare Segmentation, I would prefer a simpler output as a single-band raster with pixels ranging 1:4 and let the user color code as he/she wishes.Short summary of the requested feature
In Hoover Compare Segmentation, I would prefer a simpler output as a single-band raster with pixels ranging 1:4 and let the user color code as he/she wishes.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2163Support Copernicus DEM2022-01-07T09:40:30ZMickael SavinaudSupport Copernicus DEM[Copernicus DEM](https://spacedata.copernicus.eu/web/cscda/dataset-details?articleId=394198) is provided free at 30m and 90m. It could nice to check if we support this DEM with the new framework.
[EDIT 2022-01-07]
This DEM is supported ...[Copernicus DEM](https://spacedata.copernicus.eu/web/cscda/dataset-details?articleId=394198) is provided free at 30m and 90m. It could nice to check if we support this DEM with the new framework.
[EDIT 2022-01-07]
This DEM is supported in OTB 8.0. We should had some tests.Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2146ImageClassifier to handle a list of images/masks2021-02-11T08:37:32ZThomas TilakImageClassifier to handle a list of images/masksClassifying an image with [ImageClassifier](https://www.orfeo-toolbox.org/CookBook/Applications/app_ImageClassifier.html) could be (at least in my use case) a long operation.
When one need to classify several images with a model, the l...Classifying an image with [ImageClassifier](https://www.orfeo-toolbox.org/CookBook/Applications/app_ImageClassifier.html) could be (at least in my use case) a long operation.
When one need to classify several images with a model, the loading of the model is repeated for each image.
One improvement would be to accept a list of images/masks as input of `otbcli_ImageClassifier`.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/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/2140Build: pass `-pipe` to GCC/Clang2021-02-08T17:30:15ZLaurențiu NicolaBuild: pass `-pipe` to GCC/ClangThis can speed up the builds a bunch. Unfortunately, I don't think CMake can do it automatically where it makes sense.This can speed up the builds a bunch. Unfortunately, I don't think CMake can do it automatically where it makes sense.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2136RFC: Enable `zstd` support in SuperBuild2021-02-10T07:39:09ZLaurențiu NicolaRFC: Enable `zstd` support in SuperBuild### What changes will be made and why they would make a better Orfeo ToolBox?
ZSTD is a modern compression format that offers compression ratios comparable with `zlib`, but faster compression and decompression speeds: https://engineerin...### What changes will be made and why they would make a better Orfeo ToolBox?
ZSTD is a modern compression format that offers compression ratios comparable with `zlib`, but faster compression and decompression speeds: https://engineering.fb.com/2016/08/31/core-data/smaller-and-faster-data-compression-with-zstandard/. GDAL supports ZSTD since 2.3.
This is a proposal to include `libzstd` in the SuperBuild package, and enable GDAL's support of it. OTB applications will be able to use ZSTD compression seamlessly, by virtue of GDAL.
Results for a noisy `Float32` 10980x10980 TIFF, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 482 330 028 b | N/A | N/A | N/A |
| DEFLATE | 419 729 334 b | 4.030s | 0.687s | 1.647s |
| ZSTD-9 | 415 737 011 b | 8.514s | 3.787s | 0.903s |
Results for a 15-bit `Int16` 10980x10980 TIFF, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 226 122 884 b | N/A | N/A | N/A |
| DEFLATE | 201 822 038 b | 9.292s | 7.615s | 8.064s |
| ZSTD-9 | 207 553 979 b | 13.921s | 7.801s | 7.696s |
Results for a the file above, converted to 16-bit, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 241 187 444 b | N/A | N/A | N/A |
| DEFLATE | 177 040 501 b | 1.736s | 0.396s | 0.869s |
| ZSTD-9 | 184 242 872 b | 12.715s | 3.077s | 0.558s |
Results for a the file above, converted to 16-bit, horizontal differencing predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 241 187 444 b | N/A | N/A | N/A |
| DEFLATE | 159 937 804 b | 2.053s | 0.392s | 1.722s |
| ZSTD-9 | 153 871 845 b | 13.487s | 3.058s | 0.735s |
| ZSTD-3 | 154 626 632 b | 1.643s | 0.378s | 0.565s |
Times are best of three runs, taken on my computer, with GDAL from `osgeo/gdal:ubuntu-full-3.2.0`.
It seems that users would need to be very careful selecting the compression level, because the default is less efficient than DEFLATE-6.
#### Risks and benefits
- it makes SuperBuild more complex (one more library to keep track of)
- the SuperBuild package will be slightly larger (`libzstd.so` is about 678 KB)
- files saved with ZSTD will probably be unreadable by most software, but it's not used by default
- it allows users to take advantage of the faster compression and decompression speeds
#### Alternatives for implementations
Do nothing.
### Who will be developing the proposed changes?
Not sure.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2133Wrong input layer size in TrainImagesRegression using the ANN classifier2022-01-07T09:18:56ZCédric TraizetWrong input layer size in TrainImagesRegression using the ANN classifier### Description
This bug was reported by a user on the [forum](https://forum.orfeo-toolbox.org/t/problems-doing-imageregression-with-ann-created-model/934)
The input layer of the output model produced `TrainImagesRegression` when using...### Description
This bug was reported by a user on the [forum](https://forum.orfeo-toolbox.org/t/problems-doing-imageregression-with-ann-created-model/934)
The input layer of the output model produced `TrainImagesRegression` when using the artificial neural network classifier (`ann`) always has a size of 1, when it should match the number of bands of the input image. The training does not fail, and a mse is computed. However awhen trying to use the model with `ImageRegression` an error is thrown by OpenCV:
```
(FATAL) ImageRegression: itk::ERROR: MultiThreader(000001D5109CC040): Exception occurred during SingleMethodExecute OpenCV(4.1.1) C:\build\otb\build\OPENCV\src\OPENCV\modules\ml\src\ann_mlp.cpp:350: error: (-215:Assertion failed) (type == CV_32F || type == CV_64F) && inputs.cols == layer_sizes[0] in function ‘cv::ml::ANN_MLPImpl::predict’
```
Note that training an artificial neural network model with `TrainVectorRegression` works correctly, so the problem is likely located in `TrainImagesRegression`. Also note that `TrainImagesClassifier` works correctly whn trying to train an artificial neural network for classification.
### Steps to reproduce
```
otbcli_TrainImagesRegression -io.il input.tif -io.ip "predicted_values.tif" -io.out model.txt -classifier ann -classifier.ann.sizes 10
otbcli_ImageRegression -in input.tif -model model.txt -out out.tif
```
leads to the following model :
``` yml
%YAML:1.0
---
opencv_ml_ann_mlp:
format: 3
layer_sizes: [ 1, 10, 1 ]
[...]
```
but the input image has 4 bands.
### Configuration information
OTB 7.2, reproduced on Windows 10 and Ubuntu 16.04Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2126orfeo-toolbox Conda package WSL2022-01-07T08:55:18Zschwarzcsorfeo-toolbox Conda package WSL### Description
I am able to install the orfeo-toolbox on WSL Ubuntu, using Anaconda and creating a python=3.7 virtual environment (conda install -c conda-forge -c orfeotoolbox otb).
I am able to successfully run the "Smoothing" test ca...### Description
I am able to install the orfeo-toolbox on WSL Ubuntu, using Anaconda and creating a python=3.7 virtual environment (conda install -c conda-forge -c orfeotoolbox otb).
I am able to successfully run the "Smoothing" test case using the above described setup (https://www.orfeo-toolbox.org/packages/nightly/2019-06-28/CookBook-stable/recipes/python.html).
However when I run the command "print(str(otb.Registry.GetAvailableApplications()))", I get the error message:
[...]/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so: undefined symbol: _ZN5shark6random9globalRngE
I further looked into the problem and it seems some applications are working, e.g. "TrainImageClassifier", while others such as "TrainVector Classifier" produces the same error:
run--> app1= otb.Registry.CreateApplication("TrainVectorClassifier")
error--> 2020-11-17 12:30:03 (WARNING): Failed to load libraries from /home/cschwarz/miniconda3/envs/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so while trying to create application TrainVectorClassifier
because: -> /home/cschwarz/miniconda3/envs/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so: undefined symbol: _ZN5shark6random9globalRngE
### Steps to reproduce
- install conda on WSL Ubuntu
1. conda create --name oftb python=3.7 spyder=4
2a. conda activate oftb
2b. conda install -c conda-forge -c orfeotoolbox otb
3. python
4. import otbApplication as otb
5. print(str(otb.Registry.GetAvailableApplications()))
### Configuration information
conda version: 4.9.2
python version: 3.7.8
otb : 7.1.0 / Build: py37h06a4308_1
I am very excited to use OTB for patch-image-processing and would value your advice on how to solve this issue?
Best Regards,
Christian