otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2023-04-06T07:49:12Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2338C++17 ?2023-04-06T07:49:12ZRémi CressonC++17 ?Hi,
I am trying to switch to C++17, to build OTB along with a project that required it.
From what I saw, setting the `set(CMAKE_CXX_STANDARD 17)` in CMakeLists.txt enables to compile the whole library, at least on Ubuntu:22.04, and my ...Hi,
I am trying to switch to C++17, to build OTB along with a project that required it.
From what I saw, setting the `set(CMAKE_CXX_STANDARD 17)` in CMakeLists.txt enables to compile the whole library, at least on Ubuntu:22.04, and my project's functional tests all pass (I don't use all OTB applications though!). So that is great news.
But when I try to enable `BUILD_TESTING=ON`, I got a lot on compilation errors that I dont well understand.
I tried to solve a few of them but unfortunately I am stuck with some `error: invalid use of 'void'` errors. [Here](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/commits/tryto_compile_cpp17) is my working copy.
Moving from C++14 to C++17 doesn't look so complicated, since the library can be compiled (without tests).
Any plans to switch to C++17? (There was !799 but it's old)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2325SPOT5 orthorectification fails in 8.0.12023-05-02T08:08:16Zadescamps-aslSPOT5 orthorectification fails in 8.0.1### Description
Applying the orthorectification process in monteverdi fails when the input image is loaded with the following error: "(FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0000024E4F8AD130): No informa...### Description
Applying the orthorectification process in monteverdi fails when the input image is loaded with the following error: "(FATAL) OrthoRectification: itk::ERROR: ImageToGenericRSOutputParameters(0000024E4F8AD130): No information in the metadata, please set an image with non empty metadata"
I get the same error with the otbcli_Orthorectification program.
It worked in 7.4.1, but fails in 8.0.1 and 8.1.1
### Steps to reproduce
In Monteverdi, open OrthoRectification application and select the SPOT5 image as input. The error should appear in the log tab.
### Configuration information
Tested on :
- 8.1.1 (Windows Monteverdi binary) : fails
- 8.1.1 (Docker cli) : fails
- 8.0.1 (Docker cli) : fails
- 7.4.4 (Windows Monteverdi binary) : ok
SPOT5 image is a Level1A from SPOT World Heritage (002-003_S5_042-247-0_2013-06-07-10-55-23_HRG-1_J_DT_TT)9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2321pleiade neo pansharpening2023-10-19T14:02:43Znicodebopleiade neo pansharpeningHello and happy new year,
I tried to use the bundletoperfectsensor application on pleiades neo images and the results seems blurry.
I'm wondering if this issue comes from the input data or the pansharpening algorithm.Hello and happy new year,
I tried to use the bundletoperfectsensor application on pleiades neo images and the results seems blurry.
I'm wondering if this issue comes from the input data or the pansharpening algorithm.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2320Eager mode for ReadImageFilter2024-01-09T14:11:43ZRémi CressonEager mode for ReadImageFilterI was wondering if one could enable/disable a specific behavior of the processing workflow.
In particular I am wondering if the reading and the processing operations could be done in parallel in an OTB pipeline.
This could be an interest...I was wondering if one could enable/disable a specific behavior of the processing workflow.
In particular I am wondering if the reading and the processing operations could be done in parallel in an OTB pipeline.
This could be an interesting feature when accessing the input takes a while, e.g. when processing remote images (/vsicurl/http://.../image.tif). Indeed one region could be downloaded while another one is processed.
The typical processing flow in OTB is the following (we consider a simple pipeline composed of 1 reader --> 1 filter --> 1 writer):
1. Propagates the filter's requested output region to the reader. At the end of this step, the filter knows which region of the input it has to fetch.
2. Read the input data over this requested region
3. Process the requested region
4. Write the output
It's sequential.
What if we could run step 2 and 3 in parallel?
I am just wondering if that is somehow possible.
The only thing to do is for the reader, to not wait until the filter ask him the data, to go grab it. But this supposes that the reader knows in advance what the next requested region would be. I am wondering if somehow this is doable in the ITK framework?
I'll ask for toughs here, then I guess I will ask the ITK community...
Thanks,
Rémihttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2315Separate tool for stitching segments2022-11-17T07:50:45ZAndrew PlowrightSeparate tool for stitching segmentsI use the mean shift segmentation tool a lot, often for large datasets. I just finished running it for 30 hours to generate a 12GB geopackage.
Given the length of time this takes, I'd be very useful to have a workflow that can be interr...I use the mean shift segmentation tool a lot, often for large datasets. I just finished running it for 30 hours to generate a 12GB geopackage.
Given the length of time this takes, I'd be very useful to have a workflow that can be interrupted. More than once I've had unexpected stoppages and lost hours of processing time.
Ideally, given that my data is usually already tiled, it'd run the segmentation tool independently for each tile, **and then** stitch it all together at the end.
Otherwise, thank you very much for developing these excellent tools. They're very useful. Cheers.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2311Refactoring task for the modularization of OTB2023-11-28T09:00:57ZThibaut ROMAINRefactoring task for the modularization of OTB**New modular architecture**
![otb_9_archi](/uploads/219354ce907b36807efaf3a0e0dfac18/otb_9_archi.png)
**1. Simplify CMake options**
In OTB there is almost 40 cmake options when you call ccmake which is a bit confusing for the average...**New modular architecture**
![otb_9_archi](/uploads/219354ce907b36807efaf3a0e0dfac18/otb_9_archi.png)
**1. Simplify CMake options**
In OTB there is almost 40 cmake options when you call ccmake which is a bit confusing for the average user wanting to compile OTB for his project. A lot of option are about the dependencies of OTB, where you can mix system and superbuild dependencies, which can lead to eratic behaviors which the OTB team can't give a lot of time to debug.
- [x] Propose a simplified approach for the dependencies:
The user who wants to compile OTB will be given two options:
- Use all dependencies from the Superbuild which will be built before OTB
- Use all system dependencies, which will be listed in the cookbook for a one line simple installation
This approach permits to hide all USE_SYSTEM_DEPNAME flags which complicates the cmake process. The user will have to enable or disable the only flag `USE_SUPERBUILD_DEPS` which will activate/deactivate the flags USE_SYSTEM_XXX in the background
- [x] Review of all other cmake variables to determine which ones are mandatory, and which ones can be hidden/removed
- [x] Create OTB_BUILD_CORE, OTB_BUILD_LEARNING ... cmake targets to compile thematic modules
Instead of the current OTBGroup_XXX which is not thematic and can lead to misunderstandings for beginners, we propose to add options which will correspond to the future modules of OTB, which will be packaged with the same name.
**2. New source organisation**
The main idea is to reorganize the modules of OTB in coherent groups, which implies a reorganization of the source code.
Here is an example of a module (Core for example):
- Applications
- Functional_Tests : which will call one or a bunch of applications related to real treatments in production chains
- SubModule1... (For example IO)
- src
- include
- unit_tests
- SubModule2... (For example Common)
- src
- include
- unit_tests
- ...
With this organization, we have the applications related to this module, the tests calling those applications, and a list of submodules which contains filters/C++ classes grouped by theme. These filters are unit tested in each sub module.
To do this reorganization, the following guideline has been done:
- [x] Create a folder for each module (Learning, Stereo, SAR...)
- [x] Move src, include, tests and the related CMakeLists of each submodule to its related module
- [x] Connect CMAKE variables (OTB_BUILD_CORE etc) to the right module folder
- [x] Adapt the declared dependencies of each module in the CMakeLists
- [x] Reactivate the unit tests on the CI for each module
- [x] Reactivate the app tests ont the CI for each module
- [x] Package OTB Core and OTB Full with the current packaging method
- [x] Test the compilation of remote modules with otb core
- [x] move "to be deprecated" apps to a miscellaneous folder
**3. Test refactoring**
All the tests (TU + app) for each modules have been reactivated on the CI. Now it is important to see if all those tests are relevant.
- **Unit test + app tests**
A Lot of baselines and input has been added since the beginning of the project, but some tests have been deprecated. In order to make this refactoring relevant, we will follow this guideline :
- [x] Make a listing of currently used baselines/input files, to see what file is not needed anymore, and if some files are not too old to be relevant.
- [ ] See if there are any non relevant tests
- [ ] Determine which largeInput tests can be transformed into functional tests
- **Use cases for validation (fonctional tests)**
The current LargeInput tests are kind of outdated and not really relevant of real production chains.
The idea is to replace thoses tests with functional tests, containint one or a sequence of applications, which is the case in production chains.
We have to determine real use cases with production teams, to create those functional tests. They will be present in each thematic module.
While the unit test + app tests will be run on the CI, the new functional tests will be run on the HAL cluster
**4. New packaging**
The current packaging of OTB contains everything, all dependencies, all apps... Makeself is currently used to deliver a .run.
At the moment, there is an OTB Core package, and a full OTB package produced by the CI.
The idea is to use CPack which is integrated with cmake, to deliver packages of each OTB modules, that can install along the otb-core package.
For example, a user needs to do some machine learning with OTB, he should then install otb-core package which contains the core modules / apps of OTB and its dependencies, and then he will install otb-ML module, which will be installed in the same install tree.
This modularity permits each user to customize its installation, instead of having a big package while using 50% of it.9.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2310Reduce memory footprint when the output image is not streamable2022-10-03T07:01:21ZRémi CressonReduce memory footprint when the output image is not streamableI propose to implement something in the `ImageFileWriter` to reduce the memory footprint when the output image is not streamable (e.g. when output raster is JPEG2000 or COG (see investigations with `GDALImageIO` in #2309)).
Indeed when t...I propose to implement something in the `ImageFileWriter` to reduce the memory footprint when the output image is not streamable (e.g. when output raster is JPEG2000 or COG (see investigations with `GDALImageIO` in #2309)).
Indeed when the output format `CanStreamWrite` is `False`, the whole image is generated once, without streaming.
The downside is that every pipeline block is triggered over the `LargestPossibleRegion`, which may require a lot of memory, especially when the pipeline has many blocks (or greedy ones!).
A simple enhancement could consist in using an in-memory image object, fully allocated, that is updated with an explicit streaming mechanism that uses the original `m_StreamingManager` parameters.
Of course sometimes we want to keep the original behavior (default).Rémi CressonRémi Cressonhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2309OTB must be able to write Cloud Optimized Geotiff (COG)2022-09-29T11:54:15ZRémi CressonOTB must be able to write Cloud Optimized Geotiff (COG)Cloud Optimized Geotiff (COG) has gained increasing popularity in recent years, thanks to its ability to transit smoothly in HTTP requests, enabling unprecedented rasters interoperability.
OTB is able to read COG. However, it's not able ...Cloud Optimized Geotiff (COG) has gained increasing popularity in recent years, thanks to its ability to transit smoothly in HTTP requests, enabling unprecedented rasters interoperability.
OTB is able to read COG. However, it's not able to write COG with overviews, a crucial feature. IMO the implementation of COG writing in OTB would be huge.
# GDAL does everything
A lot of work has been made in recent GDAL versions to access and write COG more easily.
For instance since GDAL 3.1 we can simply convert any raster into COG using [[1]](https://www.cogeo.org/developers-guide.html):
```bash
gdal_translate input.tif output_cog.tif -of COG -co COMPRESS=LZW
```
A lot of work has also been done in GDAL to read COG files through most kind of online providers based on the `/vsicurl` provider.
Thanks to that, OTB is able to read most of online COG smoothly (there are still some small problems when the input URI has some `?` chars and OTB believes its an extended filename... however that's not the topic of this issue, and I'll submit another one soon, or propose an MR for that since it's not a big issue).
# OTB is not able to write COD with overviews
But right now, OTB (8.1.0) is **not able to write COG with overviews** (the issue has been described on the forum [here](https://forum.orfeo-toolbox.org/t/does-otb-support-cloud-optimized-geotiffs-in-any-manner/1038)).
The following trick enables to write COG, however output raster don't include overviews (which is one crucial feature of COG).
```bash
otbcli_SomeApplication ... -out "/path/to/output.tif?&gdal:co:TILED=YES&gdal:co:COPY_SRC_OVERVIEWS=YES"
gdalinfo /tmp/toto.tif | grep Overviews # Nothing here...
```
And of course using `gdaladdo` on the output after its creation doesn't lead to a valid COG (we can use `dist-packages/osgeo_utils/samples/validate_cloud_optimized_geotiff.py` to know if it's a valid COG).
# What could be done
First we should investigate if the creation of a COG is a streamable process. Given how overviews are computed, I am tempted to answer "yes".
**However** quick hacking in the `otbGDALImageIO.cxx` (replacing 'GTiff' drivers with 'COG') gaves me this message: `(WARNING): The file format of /tmp/cogtest.tif does not support streaming. All data will be loaded to memory`.
I don't know how this should be implemented in term of user interface, but I was thinking maybe with a COG-specific extended filename, and/or an environment variable to default the writing of all output rasters in the COG way.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2304Use GDAL metadata from an input raster gdal_translated from a DIMAP product2022-10-18T10:41:04ZRémi CressonUse GDAL metadata from an input raster gdal_translated from a DIMAP productIt looks like OTB 8.0.1 is not able to use metadata that are stored in Geotiff metadata, when doing some sensor-based operations (at least for optical calibration of Spot-6 and Spot-7 DIMAP products)
This is an example with a DIMAP from...It looks like OTB 8.0.1 is not able to use metadata that are stored in Geotiff metadata, when doing some sensor-based operations (at least for optical calibration of Spot-6 and Spot-7 DIMAP products)
This is an example with a DIMAP from Spot-7. My goal is to convert the XS image to TOA.
Here we go in plain OTB:
```bash
otbcli_OpticalCalibration -in DIM_SPOT7_MS_2021..._1.XML -out toa.tif
```
Everything works fine.
Now suppose I have an intermediate product, for instance a COG for the XS image.
```bash
gdal_translate DIM_SPOT7_MS_2021..._1.XML cog.tif -of COG
```
Now I can do some `gdalinfo` on the `cog.tif`
```
gdalinfo cog.tif
```
We can see that GDAL (3.4.2) has exported the product metadata in the geotiff. It has everything we need for the optical calibration:
```
Metadata:
AREA_OR_POINT=Area
BAND_MODE=PMS
CLOUDCOVER_MEASURE_DESC=Region of interest mask
CLOUDCOVER_MEASURE_NAME=Area_Of_Interest (ROI)
CLOUDCOVER_MEASURE_TYPE=AUTOMATIC
...
...
Band 1 Block=512x512 Type=UInt16, ColorInterp=Gray
Overviews: 5069x5171, 2534x2585, 1267x1292, 633x646, 316x323
Metadata:
RADIANCE_BIAS=0
RADIANCE_CALIBRATION_DATE=2020-09-22T12:00:00Z
RADIANCE_GAIN=8.07
RADIANCE_MEASURE_DESC=Raw radiometric counts (DN) to TOA Radiance (L). Formulae L=DN/GAIN+BIAS
RADIANCE_MEASURE_UNCERTAINTY=4
RADIANCE_MEASURE_UNIT=watt/m2/steradians/micrometers
SOLAR_IRRADIANCE_CALIBRATION_DATE=2011-09-20T12:00:00Z
...
```
However, OTB fails to use this metadata.
My guess is that the metadata factory fails to recognize the sensor.
I believe OTB should be able to do that, it would be a very useful feature.
Maybe that applies to other kind of products as well (e.g. PHR).
Do you think that is easily implementable in OTB 8.x ?
Could someone can point me to the right C++ classes and metadata-classes documentation so I can take a look?
Many thanks,
Rémihttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2300Allow disconnected builds of remote modules2022-09-05T12:27:17ZStefanBruensAllow disconnected builds of remote modulesAllow/simplify builds of remote modules when no network is available
Currently, OTB requires remote modules to be fetched at cmake configure time. This is problematic for several reasons:
- Build hosts are often isolated for security r...Allow/simplify builds of remote modules when no network is available
Currently, OTB requires remote modules to be fetched at cmake configure time. This is problematic for several reasons:
- Build hosts are often isolated for security reasons
- Fetching git HEAD of a branch makes a build non-reproducible, as HEAD may change
Preferably, OTB would allow to supply remote modules as tarballs (or expanded in the appropriate directory).
Although it is possible to download e.g. https://gitlab.orfeo-toolbox.org/jinglada/temporalgapfilling/-/archive/master/temporalgapfilling-master.tar.bz2 and expand it to the correct directory, this is rejected by `otb_fetch_content` as the tarball does not contain the `.git` subdirectory.
CMake since 3.11 has the [FetchContent module](https://cmake.org/cmake/help/v3.11/module/FetchContent.html) which does everything OTBs homegrown fetch code does, but also allows to disable fetching content using the `FETCHCONTENT_FULLY_DISCONNECTED` cache variable. Using `FetchContent` would require a small bump of the minimum version, from 3.10.2 to 3.11.9.0.0Thibaut ROMAINThibaut ROMAINhttps://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/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/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/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/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/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/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/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/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.