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/2287Missing feature in DEMHandler2023-11-28T09:00:59ZLuc HermitteMissing feature in DEMHandler**TL;DR:** Provide `DEMHandler::GetGeoidHeight()`
## Rationale
`DEMHandler::GetHeightAboveEllipsoid()` has a convoluted behaviour. Depending on what is visible it would return:
- either geoid offset + DEM offset
- or DEM offset -- alm...**TL;DR:** Provide `DEMHandler::GetGeoidHeight()`
## Rationale
`DEMHandler::GetHeightAboveEllipsoid()` has a convoluted behaviour. Depending on what is visible it would return:
- either geoid offset + DEM offset
- or DEM offset -- almost equivalent to `GetHeightAboveMSL()`
- or default height above ellipsoid
- or geoid offset
Sometimes we only need the geoid offset (it's the case of DiapOTB SARDEMProjection application).
We could make sure to have no DEM information configured, but then the application can not be chained into memory with another application that will need DEM information. Indeed `DEMHandler` is still mostly used as a global object (a singleton) (which is another known issue #2093), which makes it impossible to simultaneously have and not have DEM information.
Even if we don't chain such applications _in-memory_, we must not forget to clear DEM configuration if the applications are used through Python API and not isolated in different _subprocesses_. Indeed the memory would be shared between the various application object, and as such all the singletons...
As a workaround, SARDEMprojection detects `$OTB_GEOID_FILE` value to directly read geoid data from that file, and it falls back to `DEMHandler::GetHeightAboveEllipsoid()` if it's not possible. It's much too easy to use incorrectly.
That's why it'd be better to provide a dedicated `DEMHandler::GetGeoidHeight()` that would simplify applications such as SARDEMProjection, and that would avoid troubles regarding whether we configure DEM information or not in the global `DEMHandler`.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/2268Support metadata option of GDAL as extended filename2022-04-04T14:28:30ZMickael SavinaudSupport metadata option of GDAL as extended filenameAdd the possibility to set metadata key if possible in the output of otb as for GDAL (with `-mo` key cf.https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-mo for gdaltranslate)
It could be useful to set metadata inst...Add the possibility to set metadata key if possible in the output of otb as for GDAL (with `-mo` key cf.https://gdal.org/programs/gdal_translate.html#cmdoption-gdal_translate-mo for gdaltranslate)
It could be useful to set metadata instead of openning the file after writing to set the metadata.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/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/2248Roadmap for OTB 9.02023-06-23T04:54:23ZJulien OsmanRoadmap for OTB 9.0### Introduction
During the [OTB User Days](https://www.orfeo-toolbox.org/otb-user-days-2021-plenary-talks-workshops-and-more/), we had the opportunity to talk about the future for OTB. This helped us make some plan regarding the coming...### Introduction
During the [OTB User Days](https://www.orfeo-toolbox.org/otb-user-days-2021-plenary-talks-workshops-and-more/), we had the opportunity to talk about the future for OTB. This helped us make some plan regarding the coming months. This issue is a story aiming at providing a single place to discuss everything that we (as a community) want to do in the scope of 9.0. Please, feel free to comment this issue to enhance the following propositions.
### Scope of OTB 9.0
The purpose of OTB 9.0 will be to improve packaging and maintainability.
#### Remove Qt, the GUI app and Monteverdi
The dependency to Qt makes the OTB package quite heavy, and requires much maintenance. The purpose of this dependency is to provide some nice GUI so user don't have to use the command line. QGIS with [the OTB plugin](https://www.orfeo-toolbox.org/CookBook/QGISInterface.html) allows one to run OTB applications without command line, and even more (display images, save result in memory, etc). So we wondered if the GUI provided with OTB were still relevant. The [survey](https://forum.orfeo-toolbox.org/t/please-participate-to-our-survey-how-do-you-use-otb/872) organized on November 2020 pointed out that very few people used it anyway.
Qt is also required to build Monteverdi. Monteverdi is a tool used for very specific applications, and does it's job very well. However, it hasn't evolved for years. So we decided to stop it's development. It will still be available for download with older version of OTB, but will be removed from OTB's main repository.
Of course, if anyone wants to take over the maintenance of the GUI or Monteverdi, they will be welcome to create a remote module.
#### Remove MacOS support
As MacOs is used by very few people, and Apple is moving to an ARM architecture, it is becoming more difficult to maintain OTB on this platform. Docker is fuly supported on MacOs, so we decided to concentrate on a Linux docker image that people can use on any MacOs.
#### Enhance the DEMHandler to manage huge directory
With OTB 8, when one provides a directory to the DEMHandler, it loads all the content of the directory into memory. If this directory contains a lot of DEM tiles, it can take a long time or even crash. We propose to improve the DEMHandler so it only loads the tiles needed by the process.
### Postponed to OTB 10
### Re-organize the packaging in modules
OTB should be modular, installable via light packages
#### Re-organize the tests
Many unit test relies on heavy data, and should be made a lot simpler.
#### Upgrade to ITK 5.x
ITK is one of OTB's the main dependencies. It's last major version, 5.0, was release on May 2019, and the latest version is 5.2.1 released on August 2021. But OTB still relies on ITK 4.x. The time has come for OTB to catch up. It requires [some adjustments](https://github.com/InsightSoftwareConsortium/ITK/blob/master/Documentation/ITK5MigrationGuide.md), but some preliminary work was already done (!194, !528).
~story9.0.0https://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.