otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2022-01-19T14:49:00Zhttps://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/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/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/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/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/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/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/2210"rounding" issue with large number using BandMath2021-08-04T06:25:12ZJulien Osman"rounding" issue with large number using BandMath### Description
Issue reported [on the forum](https://forum.orfeo-toolbox.org/t/rounding-issue-with-large-number-using-bandmath/1074).
When using the BandMath application, the large numbers are truncated.
### Steps to reproduce
Try u...### Description
Issue reported [on the forum](https://forum.orfeo-toolbox.org/t/rounding-issue-with-large-number-using-bandmath/1074).
When using the BandMath application, the large numbers are truncated.
### Steps to reproduce
Try using parameter `-exp "im1b1*100000 + im2b1"` where im1b1 is smaller that 10000.
### Configuration information
Tested on Linux, with OTB version 6.7 & 7.2 & 7.3.https://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???