otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2024-02-01T08:58:17Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2294The application RefineSensorModel is missing in version 8.0+2024-02-01T08:58:17Zhello-willyThe application RefineSensorModel is missing in version 8.0+# Refactoring the RefineSensorModel application
## Context
The application RefineSensorModel uses a set of tie points to adjust the parameters of a sensor model.
It uses an optimization algorithm (least-square) to fit the model to the...# Refactoring the RefineSensorModel application
## Context
The application RefineSensorModel uses a set of tie points to adjust the parameters of a sensor model.
It uses an optimization algorithm (least-square) to fit the model to the fit points.
The inputs of the application are
- a geom file containing the sensor model
- a text file containing the tie points
The outputs are
- a geom file containing the refined sensor model
- a text file containing output precision statistics
- a text file containing segments representing residues
Since OTB 8, this application is not available.
We want to reintroduce it, since it is of great interest.
## Details of the refactoring
To reintroduce RefineSensorModel, we need to address multiple issues
### OTB doesn't write geom files anymore
The new version of OTB can't produce a geom file as output of the application.
We propose to change the RefineSensorModel application to work at the product level.
Instead of reading and writing a geom file, it will read and write an image file.
Impact:
- The `ingeom` and `outgeom` parameters become `inImage` and `outImage`, and are of type "ParameterType_InputImage" instead of "ParameterType_InputFilename".
- Use the `SensorTransformFactory` to load the RPC or SAR model from the metadata of the input image.
### Hold the fit points
The fit points used to be stored in the SensorModelAdapter class.
This class was removed with OSSIM, so we need to store the fit points somewhere else.
The proposed class for this task is `SensorTransformBase`.
Impact:
- Add the attribute `m_TiePoints` and implement the function `AddTiePoint` to `SensorTransformBase`.
### Run the optimization
The optimization algorithm was provided by OSSIM.
So we need to implement the optimization algorithm and call it for each sensor model (SAR, RPC).
Impact:
- Implement the Least-Square Optimization algorithm ?
- Add an `Optimize` virtual function to `SensorTransformBase`.
- Implement an `Optimize` function in `RPCTransformBase` class that apply the optimization algorithm to the RPC model (RpcParam).
- Implement an `Optimize` function in `SARTransformBase` class that apply the optimization algorithm to the SAR model (SarParam).8.2.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2292Python export image to numpy is always float322022-08-29T15:47:26ZVincent DelbarPython export image to numpy is always float32It would be really nice to preserve the output data type, because right now, if we try to convert a big 8bit image to numpy, this will come out 4x bigger and since we need a copy in case the app ref is lost, it requires x8 times the imag...It would be really nice to preserve the output data type, because right now, if we try to convert a big 8bit image to numpy, this will come out 4x bigger and since we need a copy in case the app ref is lost, it requires x8 times the image footprint of available RAM...
This does not change anything to set the app's output parameter pixel type.
Ideally this could also apply to the python copy of the array.
Is it something feasible without a lot of code or do you think this should go in the 9.0 roadmap ?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2284Large scene segmentation : Error in LargeScaleMeanShift - File size cannot re...2022-06-08T13:35:48ZArthur de GrandpréLarge scene segmentation : Error in LargeScaleMeanShift - File size cannot reach [size]Hi,
I have been using MeanShiftSegmentation in a GEOBIA workflow successfully until larger scenes with large nodata areas appeared in our input images. The large nodata areas generated a very large amount of output polygons, making the ...Hi,
I have been using MeanShiftSegmentation in a GEOBIA workflow successfully until larger scenes with large nodata areas appeared in our input images. The large nodata areas generated a very large amount of output polygons, making the files much harder to manipulate.
To circumvent this issue, I have been trying to implement LargeScaleMeanShift, which seems to perform correctly until the Vectorization step, where the following error message is generated :
`
(FATAL) LargeScaleMeanShift: itk::ERROR: Cannot create a new feature in the layer <.shp>: Failed to write shape object. File size cannot reach 4294967160 + 136
`
The following input command is used to launch the app, where the input is a ~150Go 8 bands GeoTIFF Worldview-2 image:
`
-in image.tif -spatialr 5 -ranger 0.05 -minsize 3 -mode vector -mode.vector.out output/test.shp -cleanup true -ram 4000
`
[edit] I am using using OTB 7.1.0 on Windows 8.1 64bits
I have also tried with higher ram limits, without success.
Are there any tricks to fix this issue, and/or what would be the best practices when applying MeanShiftSegmentation to larger scenes?
Many thanks,
Arthurhttps://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/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/2266OTB 8.0 : Warning / Issues with metadata on Sentinel1 images2023-11-06T17:02:51ZNicolas EkicierOTB 8.0 : Warning / Issues with metadata on Sentinel1 images### Description
It seems there are some issues with metadata in SARCalibration process, just an example in one image (S1A_IW_GRDH_1SDV_20220306T174909_20220306T174934_042204_050795_54AF.SAFE) :
Outputs lines :
```
Warning 1: s1a-iw-...### Description
It seems there are some issues with metadata in SARCalibration process, just an example in one image (S1A_IW_GRDH_1SDV_20220306T174909_20220306T174934_042204_050795_54AF.SAFE) :
Outputs lines :
```
Warning 1: s1a-iw-grd-vh-20220306t174909-20220306t174934-042204-050795-002_calOk.tiff: Metadata exceeding 32000 bytes cannot be written into GeoTIFF. Transferred to PAM instead.
Warning 1: s1a-iw-grd-vv-20220306t174909-20220306t174934-042204-050795-001_calOk.tiff: Metadata exceeding 32000 bytes cannot be written into GeoTIFF. Transferred to PAM instead.
```
It cause also an issue with Orthorectification for the next of processing :
```
2022-03-24 16:39:31 (WARNING): Input image has SAR calibration metadata, but OTB was not able to read it: ../Modules/Core/Metadata/src/otbSARMetadata.cxx:43:
otb::ERROR: Unable to find 'SARCalib.RadiometricCalibrationIncidenceAngle' in the input keywordlist
2022-03-24 16:39:31 (WARNING): Input image has SAR calibration metadata, but OTB was not able to read it: ../Modules/Core/Metadata/src/otbSARMetadata.cxx:43:
otb::ERROR: Unable to find 'SARCalib.RadiometricCalibrationIncidenceAngle' in the input keywordlist
```
### Configuration information
Ubuntu 18.04, OTB 8.0.0https://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/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/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/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/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/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.