otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2020-09-21T06:08:27Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2043App::OutputImageParameter::GetParameterOutputImage does not take the OutputPi...2020-09-21T06:08:27ZEsquis BenjaminApp::OutputImageParameter::GetParameterOutputImage does not take the OutputPixelType requested into accountDear,
When getting the pointer on an OutputImageParameter the requested pixel type is not taken into account thus always returning the initial type of the last filter's output.
This is importan when chaining applications with pointer in...Dear,
When getting the pointer on an OutputImageParameter the requested pixel type is not taken into account thus always returning the initial type of the last filter's output.
This is importan when chaining applications with pointer instead of filenames since the type has to be set (for exemple a mask should be in uint8)
Regardshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2042otb application GetParameterImageBase on InputImageListParameter always retur...2022-01-06T16:10:19ZEsquis Benjaminotb application GetParameterImageBase on InputImageListParameter always return a FloatVectorImageDear,
When calling this function on an InputImageListParameter the return pointer is always casted into a FloatVectorImage while there is an accessor on InputImageParameter to get the real ImageBase* not casted.
This is particularly impo...Dear,
When calling this function on an InputImageListParameter the return pointer is always casted into a FloatVectorImage while there is an accessor on InputImageParameter to get the real ImageBase* not casted.
This is particularly important when chaining the applications with pointers of specifiq types (uint8 ...) that needs to keep their types.
Regardshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2033Dimensionality Reduction: set bv pixels in the output as bv2022-01-06T15:52:52ZaloboaDimensionality Reduction: set bv pixels in the output as bvI observe the manual states:
> Background Value -bv float Background value to ignore in computation of the transformation matrix. Note that all pixels will still be processed when applying the transformation.
I think this a wrong choic...I observe the manual states:
> Background Value -bv float Background value to ignore in computation of the transformation matrix. Note that all pixels will still be processed when applying the transformation.
I think this a wrong choice: pixels with bv values in the input should be set as bv in the output.
Also, bv values should be ignored for calculating the input min,max values for rescaling (not sure they are, just in case)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2032Dimensionality Reduction: more problems with the -bv option2020-04-21T09:26:08ZaloboaDimensionality Reduction: more problems with the -bv option### Description
Results of two images that are identical except that nodata is coded with different values
produce different results despite adjusting the -bv parameter
### Steps to reproduce
`otbcli_DimensionalityReduction.bat -in min...### Description
Results of two images that are identical except that nodata is coded with different values
produce different results despite adjusting the -bv parameter
### Steps to reproduce
`otbcli_DimensionalityReduction.bat -in mini1.tif -out mini1PCAotbnowhit.tif uint8 -method pca -method.pca.whiten false -rescale minmax -rescale.minmax.outmin 1 -rescale.minmax.outmax 255 -nbcomp 5 -ram 256 -method.pca.outeigenvalues mini1PCAotbnowhit.eig.csv -outmatrix mini1PCAotbnowhit.eigmat.csv -bv 0`
`otbcli_DimensionalityReduction.bat -in mini2.tif -out mini2PCAotbnowhit.tif uint8 -method pca -method.pca.whiten false -rescale minmax -rescale.minmax.outmin 1 -rescale.minmax.outmax 255 -nbcomp 5 -ram 256 -method.pca.outeigenvalues mini2PCAotbnowhit.eig.csv -outmatrix mini2PCAotbnowhit.eigmat.csv -bv -9999`
min1.tif and mini2.tif are identical except that nodata are differently coded: 0 in mini1.tif and -9999 in mini2.tif
[mini1.tif](/uploads/ca05b01e3f508bc4325fbb917508329d/mini1.tif)
[mini2.tif](/uploads/688f394710df888ec1e2e59df38c6653/mini2.tif)
outmatrix from mini1.tif:
```
0.0225902 0.13464175 0.03616559 0.38740169 0.911028686
-0.2931714 -0.39771676 -0.61992474 -0.52302445 0.313066519
-0.2664791 -0.07863263 -0.57043029 0.72516423 -0.267491959
0.1835331 -0.90372588 0.31428125 0.22444948 0.021091448
0.8993579 0.02809663 -0.43614442 -0.01116367 -0.004392191
```
outmatrix from mini2.tif:
```
0.264344642 0.56605767 0.4501535 0.441180578 0.4608928
0.437861248 -0.01381594 0.2648024 -0.810937410 0.2834553
0.826028376 0.06059065 -0.3429448 0.193662447 -0.3986096
-0.236645417 0.82023511 -0.2316503 -0.331929794 -0.3276798
0.008689483 0.05413842 -0.7456330 -0.007594959 0.6640537
```
Eigenvectors calculated in R are identical for both images
and very close to those of otb for mini1.tif
(note R arranges eigenvectors by columns)
```
0.02172112 0.2969163 0.26230709 0.269461355 0.877470509
0.13260990 0.4015052 0.03351642 -0.896746212 0.126218499
0.03314596 0.6279545 0.57752377 0.242825808 -0.460517598
0.38654206 0.5127257 -0.72212125 0.253401650 -0.045012501
0.91182750 -0.3056467 0.27400516 0.007748542 -0.003436984
```
Finally, PCA images are quite different even the resulting from mini1.tif vs. the one calculated in R
[mini1PCARint.tif](/uploads/a833fd7e2f0e03a6d022b3fb8add0128/mini1PCARint.tif)
[mini1PCAotbnowhit.tif](/uploads/dba1ed0561c852ff76a8fe43dbdf0e94/mini1PCAotbnowhit.tif)
[mini2PCAotbnowhit.tif](/uploads/488ac748f5199cd9cc2fb85f049a4ee8/mini2PCAotbnowhit.tif)
### Configuration information
OTB-7.1.0-rc1-Win64https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2030symbol lookup failed in OTB-7.0.0 binary package with wrong order of import i...2022-01-06T15:16:31ZRashad Kanavathsymbol lookup failed in OTB-7.0.0 binary package with wrong order of import in python### Description
Segmentation fault (core dumped)
### Steps to reproduce
Download otb binary package for 7.0.0
wget https://www.orfeo-toolbox.org/packages/archives/OTB/OTB-7.0.0-Linux64.run
build python wrapping
`cmake -VV -S OTB-7.0....### Description
Segmentation fault (core dumped)
### Steps to reproduce
Download otb binary package for 7.0.0
wget https://www.orfeo-toolbox.org/packages/archives/OTB/OTB-7.0.0-Linux64.run
build python wrapping
`cmake -VV -S OTB-7.0.0-Linux64/share/otb/swig/build_wrapping.cmake`
test_ok.py
```python
#!/usr/bin/env python3
import otbApplication as otb
import gdal
```
test_fail.py
```python
#!/usr/bin/env python3
import gdal
import otbApplication as otb
```
python3 test_ok.py
python3 test_fail.py
I remember some discussion about this in old mantis tracker but can't remember all of its details.
### Configuration information
Ubuntu Linuxhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2018Floating point exception (core dumped) for otbcli_KMeansClassification2021-12-10T09:29:05ZGilles FOUVETFloating point exception (core dumped) for otbcli_KMeansClassification### Description
bug Floating point exception (core dumped) some time when used otbcli_KMeansClassification in OTB 7.0
### Steps to reproduce
command line : otbcli_KMeansClassification -in ./Bordeaux_Metropole_normalized.tif -out ./Bor...### Description
bug Floating point exception (core dumped) some time when used otbcli_KMeansClassification in OTB 7.0
### Steps to reproduce
command line : otbcli_KMeansClassification -in ./Bordeaux_Metropole_normalized.tif -out ./Bordeaux_Metropole_macroclass_solnu_mask_cleaned_tmp.tif uint8 -vm ./Bordeaux_Metropole_macroclass_solnu_mask_cleaned_clean.tif -ts 4642865 -nc 10 -maxit 2000 -centroids.out ./Bordeaux_Metropole_microclass_solnu_mask_cleaned_Kmeans_centroid.txt -rand 5 -ram 1800
for test :
Bordeaux_Metropole_normalized.tif : File is too big (506.3MiB). Max filesize: 10MiB" !!!!!
Bordeaux_Metropole_macroclass_solnu_mask_cleaned_clean.tif : File is too big (14171.54MiB). Max filesize: 10MiB
### Configuration information
OTB version 7.0.0 on Ubuntu 18.04 install from OTB-7.0.0-rc1-Linux64.runhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2016Incorrect signature for python.ImportImage()2022-01-06T15:13:34ZLuc HermitteIncorrect signature for python.ImportImage()### Description
When calling
```python
presum = otb.Registry.CreateApplication("SARPresummation")
input_dict = {
'array' : raw_master,
'origin' : [0,0],
'size' : raw_master.shape,
'metadat...### Description
When calling
```python
presum = otb.Registry.CreateApplication("SARPresummation")
input_dict = {
'array' : raw_master,
'origin' : [0,0],
'size' : raw_master.shape,
'metadata' : generate_kwl(input, None, input, antenna='master')
}
presum.ImportImage('in', input_dict)
```
with `raw_master` being a 2D `np.array` of complex numbers, I have the following errors
##### With OTB 7.0
```
Traceback (most recent call last):
File "/work/scratch/mine/dev/swot/install/SARModules/release/bin/chain-all.py", line 161, in <module>
chain_applis(options)
File "/work/scratch/mine/dev/swot/install/SARModules/release/bin/chain-all.py", line 131, in chain_applis
presum.ImportImage('in', input_dict)
File "/softs/projets/otb/rh7/7.0-python3.7.2/otb/lib/otb/python/otbApplication.py", line 3506, in ImportImage
img = self.SetImageFromNumpyArray(paramKey, pyImg["array"], index)
File "/softs/projets/otb/rh7/7.0-python3.7.2/otb/lib/otb/python/otbApplication.py", line 3431, in SetImageFromNumpyArray
img = self.ImageImporterMap[pixT](self,paramKey, index, npArray)
TypeError: SetImageFromCDoubleNumpyArray_() missing 3 required positional arguments: 'dim1', 'dim2', and 'dim3'
```
##### With current version in dev branch
```
Traceback (most recent call last):
File "/work/scratch/mine/dev/swot/install/SARModules/rel-myOTB/bin/chain-all.py", line 163, in <module>
chain_applis(options)
File "/work/scratch/mine/dev/swot/install/SARModules/rel-myOTB/bin/chain-all.py", line 133, in chain_applis
presum.ImportImage('in', input_dict)
File "/work/scratch/mine/dev/img/build/otb/superbuild_install/lib/otb/python/otbApplication.py", line 2088, in ImportImage
img = self.SetImageFromNumpyArray(paramKey, pyImg["array"], index)
File "/work/scratch/mine/dev/img/build/otb/superbuild_install/lib/otb/python/otbApplication.py", line 2013, in SetImageFromNumpyArray
img = self.ImageImporterMap[pixT](self,paramKey, index, npArray)
File "/work/scratch/mine/dev/img/build/otb/superbuild_install/lib/otb/python/otbApplication.py", line 1795, in SetImageFromCDoubleNumpyArray_
def SetImageFromCDoubleNumpyArray_(self, *args): return _otbApplication.Application_SetImageFromCDoubleNumpyArray_(self, *args)
TypeError: Application_SetImageFromCDoubleNumpyArray_() takes exactly 7 arguments (4 given)
```
### My understanding
In `otbApplication.i`, `SetImageFromNumpyArray()` calls the _typed_ python binding function from the map with only 4 parameters.
Then, depending on OTB version, the python binding may the correct number of parameters, but eventually it fails to call the OTB mapped function which expects 7 parameters.
If I understand correctly, `SetImageFromNumpyArray()` should be able to deduce the region (1) parameters. Either they could come from `ImportImage()` region key in the dictionary, or they could be deduced from the shape of the `np.array`. Then all these region information could be forwarded all the way to C++ mapped functions.
(1) At this time, size parameters are expected, but it should be possible to pass the complete region information instead of guessing something in the `SetFromNumpyArrayMacro` macro.
### Configuration information
- OS: Linux CentOS 7
- OTB 7.0 on HAL, or installed from dev branch
- Python: 3.7.2https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2013Improve non-regression testing methods2022-01-07T09:48:48ZYannick TANGUYImprove non-regression testing methodsOTBTestDriver is used to compare results (images, vector files, ascii files, ..) in OTB unit tests.
For ogr data, this driver compares different features (ie : nb of fields, nb of features, geometry, etc.) and then compares each feature ...OTBTestDriver is used to compare results (images, vector files, ascii files, ..) in OTB unit tests.
For ogr data, this driver compares different features (ie : nb of fields, nb of features, geometry, etc.) and then compares each feature by dropping content to an ASCII file and comparing reference and result.
=> There are a lot of temporary files written in temporary/testing folder and it may not be very efficient.
Here are some ideas to improve this behavior (thanks @gpasero for the explanations !) :
- the better solution would be to delegate this comparison to a specific OGR API (see GDAL API ?)
- we could compare md5 of result and reference file, and if there is a difference, compare the features : in most cases, it would save some time writing the temporary files.. But we need to get a MD5 sum API that we could call from the C++ test driver
- instead of writing ASCII files for each feature, we could drop content in two Strings and compare them. If there is a difference, the two Strings could be written to a file, as we do now.
=> This subject should be discussed to find the best solution !https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2006BundleToPerfectSensor propagates sensor kwl of Pan image2022-01-06T15:24:22ZRémi CressonBundleToPerfectSensor propagates sensor kwl of Pan imageShort summary of the requested feature
BundleToPerfectSensor propagates sensor keyword list of Pan image. It could be more useful to have the keywordlist of the MS image instead.Short summary of the requested feature
BundleToPerfectSensor propagates sensor keyword list of Pan image. It could be more useful to have the keywordlist of the MS image instead.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2001Problems in running OTB2021-11-08T11:42:35ZRashad KanavathProblems in running OTB### Description
Issue reported on qgis-developer https://lists.osgeo.org/pipermail/qgis-developer/2019-December/059544.html
@pcav
Hi all,
OTB algs apparently do not work on QGIS 3.10 out of the box:
* if a raster output is not expl...### Description
Issue reported on qgis-developer https://lists.osgeo.org/pipermail/qgis-developer/2019-December/059544.html
@pcav
Hi all,
OTB algs apparently do not work on QGIS 3.10 out of the box:
* if a raster output is not explicitly selected I get an error:
“.raster.out.tif” files are not supported as outputs for this algorithm
* if a vector output is not explicitly selected (with filename.ext) I
get another error:
2019-12-03 12:30:43 (FATAL) Segmentation: itk::ERROR: No OGR driver
known to OTB to create and handle a DataSource named
</tmp/processing_1845b856b9b44fa79bd7d1f2f834ffa0/processing_5bc31a5446744fff806de1d05d4b0240/4083978a97c840adbe135f8409847bfd/mode.vector.out.file>.
If confirmed I can open two tickets.
Additionally (but this must be done by OTB itself, nothing to do with QGIS):
ERROR 1: TopologyException: Input geom 1 is invalid: Ring
Self-intersection at or near point 1651438.0098749998 4818821.1863940004
at 1651438.0098749998 4818821.1863940004
probably related to #1559https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1995Wrong Error Message at opening ENVI files in DimensionalityReduction2022-01-07T10:14:02ZaloboaWrong Error Message at opening ENVI files in DimensionalityReduction### Description
Given the command:
`otbcli_DimensionalityReduction -in CupriteAVIRISSubset.dat -out outpca.tif`
for which I have both
CupriteAVIRISSubset.dat
CupriteAVIRISSubset.hdr
(note that the "non-hdr" file in ENVI format c...### Description
Given the command:
`otbcli_DimensionalityReduction -in CupriteAVIRISSubset.dat -out outpca.tif`
for which I have both
CupriteAVIRISSubset.dat
CupriteAVIRISSubset.hdr
(note that the "non-hdr" file in ENVI format can have any extension (even not extension at all), as it is ignored)
I get
`ERROR 1: The selected file is an ENVI header file, but to open ENVI datasets, the data file should be selected instead of the .hdr file. Please try again selecting the data file corresponding to the header file: CupriteAVIRISSubset.hdr`
Nevertheless, the process goes on and completes successfully
### Steps to reproduce
You can get the CupriteAVIRISSubset.dat and CupriteAVIRISSubset.hdr files from http://exelis.http.internapcdn.net/exelis/data/envi_tutorial_data/hyperspectral.zip
### Configuration information
Linux Debian testing OTB-7.0.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1972Improving log macro performances2022-01-06T15:01:07ZLuc HermitteImproving log macro performancesThe way logging macros are defined, they could consume a lot of time if passed slow functions. IOW,
```cpp
otbMsgDevMacro(somethingslowandcalledforeachpixel());
```
would yield to inefficient code.
The usual way to fix this would be
...The way logging macros are defined, they could consume a lot of time if passed slow functions. IOW,
```cpp
otbMsgDevMacro(somethingslowandcalledforeachpixel());
```
would yield to inefficient code.
The usual way to fix this would be
```cpp
#define otbLogMacro(level,msg) \
if (otb::Logger::Instance()->ShouldWeLog(level)) \ // <-- the new line
{ \
std::ostringstream itkmsg; \
itkmsg msg << "\n"; \
otb::Logger::Instance()->level(itkmsg.str().c_str()); \
}
```
BTW, the `std::string` shall not be converted into a `char const*` to be converted back into an `std::string` -> get rid of `.c_str()`.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1958otbQgisDescriptor execution fails when building using ninja on windows2022-01-06T15:03:32ZkishoreotbQgisDescriptor execution fails when building using ninja on windows![fail](/uploads/f1b2534b5d446b4e1cb50fa0a1d86d97/fail.PNG)
![fail2](/uploads/c45e05098e2b8f86988b533328450dd3/fail2.PNG) When building OTB using ninja through cmd on windows all the descriptor files are failing with some debug error.
I...![fail](/uploads/f1b2534b5d446b4e1cb50fa0a1d86d97/fail.PNG)
![fail2](/uploads/c45e05098e2b8f86988b533328450dd3/fail2.PNG) When building OTB using ninja through cmd on windows all the descriptor files are failing with some debug error.
I'm very new to OTB, could anyone help me out here! let me know if the information provided is vague to understand the issue.
Thanks for your time in advance.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1945Bring back FCLS2022-01-06T15:04:32ZAntoine RegimbeauBring back FCLS### Bring back FCLS
As pointed out in #1921 the NCLS algorithm we had (unmixing algorithm under Nonnegative Constrained Least Square) was buggy and was doing exactly the same as an UCLS (UnConstrained).
@terudel proposed to implement t...### Bring back FCLS
As pointed out in #1921 the NCLS algorithm we had (unmixing algorithm under Nonnegative Constrained Least Square) was buggy and was doing exactly the same as an UCLS (UnConstrained).
@terudel proposed to implement the FCLS algorithm (Fully Constrained) because:
>[..] it is widely used in the hyperspectral community. It is a linear spectral unmixing algorithm that is based both on the non-negativity constraint of factors (such as NCLS) but also on the fact that the sum of the coefficients of the abundance map must be equal to 1 (which makes sense from a physical point of view).
Moreover, if we believed the code, we used to have the two algorithms FCLS and NCLS in the HyperspectralUnmixing application. So it would be nice to have at least one back.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1938bug in otbcli_Segmentation2022-01-06T14:55:20ZDavid Michéabug in otbcli_SegmentationHi,
I run a lot of segmentations using OTB Meanshift segmentation module. But in a particular case, the segmentation ends well, with a non empty (200MB) shapefile:
> 212721664 18 juin 16:20 segments.shp
... but containing no...Hi,
I run a lot of segmentations using OTB Meanshift segmentation module. But in a particular case, the segmentation ends well, with a non empty (200MB) shapefile:
> 212721664 18 juin 16:20 segments.shp
... but containing no feature:
$ ogrinfo segments.shp segments
INFO: Open of `segments.shp'
using driver `ESRI Shapefile' successful.
Layer name: segments
Metadata:
DBF_DATE_LAST_UPDATE=2019-06-18
Geometry: Polygon
Feature Count: 0
Extent: (0.000000, 0.000000) - (0.000000, 0.000000)
...
To launch it, I ran the command:
`export ITK_GLOBAL_DEFAULT_NUMBER_OF_THREADS=12 && numactl --cpunodebind=1 --membind=1 otbcli_Segmentation -in attributes_multiband.tif -mode vector -mode.vector.out segments.shp -mode.vector.inmask data_cover.tif -mode.vector.tilesize 1024 -filter meanshift -filter.meanshift.spatialr 20 -filter.meanshift.ranger 20 -filter.meanshift.minsize 200 -ram 2048
`
using a superbuild compiled version with OpenMP activated (on a node with 12 cores/socket)
A link to the dataset I have used is included below (both input and output files). I ran this case several times with the same result.
If you have some difficulties reproducing the bug, I have made a docker image of my OTB build wich gives the same result. Just ask me.
The dataset can be downloaded with this [link](https://seafile.unistra.fr/d/b57956ff384748a2832b/) (1.7 GB)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1928LargeScaleMeanshift memory error with OTB6.7.0, works with OTB6.6.12022-01-07T11:47:25ZMichael WessLargeScaleMeanshift memory error with OTB6.7.0, works with OTB6.6.1### Description
We used OTB 6.7.0 for the zonalSTatistics feature, which worked well. When we tried to run LargeScaleMeanshift from the same version, we always got an out of memory error, while LargeScaleMeanshift from OTB 6.6.1 with ex...### Description
We used OTB 6.7.0 for the zonalSTatistics feature, which worked well. When we tried to run LargeScaleMeanshift from the same version, we always got an out of memory error, while LargeScaleMeanshift from OTB 6.6.1 with exactly the same command works without problems. We did not figure out exactly what the problem was, but we used the `-ram` parameter and set `GDAL_CACHEMAX` and `OTB_MAX_RAM_HINT` to exactly the same values in both versions...one worked, the other one didnt.
If important, we ran both tests in an isolated Docker image (docker v1.39) with exactly the same environment, just different OTB versions.
### Configuration information
OTB 6.6.1 and OTB 6.7.0
**edit**: I know 6.7.0 is not final, we used the nightly build; I just thought it mght be still helpful to report this issue!https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1917ITK 5 support2022-01-06T15:06:39ZVictor PoughonITK 5 supportIssue of !194
TODO:
* https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/merge_requests/194#note_78887Issue of !194
TODO:
* https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/merge_requests/194#note_78887Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1915use libressl instead of openssl in dependency to curl2019-06-06T09:06:38ZRashad Kanavathuse libressl instead of openssl in dependency to curllibressl has cmake and windows support that openssl. This is much easy to manage that having a perl everytime to just configure openssl.libressl has cmake and windows support that openssl. This is much easy to manage that having a perl everytime to just configure openssl.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1911Add CMake flag to disable QGIS descriptors2022-01-06T14:40:03ZVictor PoughonAdd CMake flag to disable QGIS descriptorsSee: https://forum.orfeo-toolbox.org/t/otb-without-qgis/281
default value should be ON
related to #1910See: https://forum.orfeo-toolbox.org/t/otb-without-qgis/281
default value should be ON
related to #1910https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/1909Refactor InputImageParameter::GetImage2019-05-27T13:45:27ZVictor PoughonRefactor InputImageParameter::GetImageAfter investigation during the fix of #1899 in !497, it was determined that `InputImageParameter::GetImage` should be refactored:
* Support multiple output types
* Make the getter constAfter investigation during the fix of #1899 in !497, it was determined that `InputImageParameter::GetImage` should be refactored:
* Support multiple output types
* Make the getter const