otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2022-01-07T09:48:59Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2171Support reading products from virtual file system2022-01-07T09:48:59ZMickael SavinaudSupport reading products from virtual file systemAs described by GDAL [here](https://gdal.org/user/virtual_file_systems.html), EO products are delivered as archive and in parallel more and more stored on network (in object storage for example).
Currently (with 8.0.0-alpha1) even if a...As described by GDAL [here](https://gdal.org/user/virtual_file_systems.html), EO products are delivered as archive and in parallel more and more stored on network (in object storage for example).
Currently (with 8.0.0-alpha1) even if a part of metadata are read with GDAL, we use specific code to retrieve the missing metadata. This code don't support virtual file system although the GDAL part yes. For example, you can made otbcli_ReadImage on a Sentinel-1 data in an archive and retrieve some metadata thanks to GDAL but not from the OTB part.
It would be nice to support this virtual file system in the OTB metadata. With that we can run an ortho on the Pleiades data without unarchive the product or run SARCalibration on a Sentinel1 data store in an object storage.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2172RPC Refinement Zeroes Height Coefficients2022-01-07T09:34:35ZMustafa TekeRPC Refinement Zeroes Height Coefficients### Description
Describe what happens and why you think it is a bug
### Steps to reproduce
Describe as precisely as possible how to reproduce the bug. Try to isolate a minimal number of steps. Also describe reproducibility (always, ra...### Description
Describe what happens and why you think it is a bug
### Steps to reproduce
Describe as precisely as possible how to reproduce the bug. Try to isolate a minimal number of steps. Also describe reproducibility (always, random ...).
### Configuration information
OS, OTB version or tag, information related to build (binaries, superbuild, system libs ...)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2173Pansharpening issue with SPOT products2021-04-30T15:05:55ZSimon GascoinPansharpening issue with SPOT productsMessage d'Etienne Berthier avec BundleToPerfectSensor version 7.2.0 qui fait écho aux issues #1823 #2148
"Bonjour,
Je souhaite faire un pansharpening sur des images SPOT6. J'ai comparé deux outils. La fonction "pansharp" de Ames Stere...Message d'Etienne Berthier avec BundleToPerfectSensor version 7.2.0 qui fait écho aux issues #1823 #2148
"Bonjour,
Je souhaite faire un pansharpening sur des images SPOT6. J'ai comparé deux outils. La fonction "pansharp" de Ames Stereo Pipeline et otbcli_BundleToPerfectSensor appelé ainsi
otbcli_BundleToPerfectSensor -inp Chamoli_2020-09-20_ortho_1.5m_001_mapproj.tif -inxs Chamoli_2020-09-20_ortho_6m_001_RGB.tif -out Chamoli_2020-09-20_ortho_1.5m_001_P+XS_OTB.tif
Le résultat avec ASP est satisfaisant alors que la sortie d'OTB est floue. Je vais continuer avec ASP mais l'équipe OTB est probablement intéressée par ce résultat. Les images d'entrée et de sortie sont disponibles ici :
ftp://ftp.legos.obs-mip.fr/pub/tmp1m/berthier/Chamoli_2020-09-20_ortho_1.5m_001_P+XS.zip
Notez que le même problème s'est présenté avec des images Pléiades.
Cordialement,
Etienne Berthier"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/2175Imprecise error messages in Python API for `SetParameters`2022-01-20T14:51:10ZLuc HermitteImprecise error messages in Python API for `SetParameters`When we pass data of the wrong type or even `None` to `otb.Application.SetParams()`, we have no way to know what we did wrong.
In the stack trace we see messages like:
```
File "/path/to/OTB-7.2.0-Linux64/lib/python/otbApplication.p...When we pass data of the wrong type or even `None` to `otb.Application.SetParams()`, we have no way to know what we did wrong.
In the stack trace we see messages like:
```
File "/path/to/OTB-7.2.0-Linux64/lib/python/otbApplication.py", line 2920, in SetParameterString
val = _otbApplication.Application_SetParameterString(self, parameter, value, hasUserValueFlag)
TypeError: in method 'Application_SetParameterString', argument 3 of type 'std::string'
```
But, which parameter is it? What is its value?
Instead, we could have
```
File "/home/luc/dev/tests/OTB-7.2.0-Linux64/lib/python/otbApplication.py", line 3239, in SetParameterValue
raise TypeError('Expected a string for %s, got %s for %s' % (paramKey, type(value), value))
TypeError: Expected a string for elev.geoid, got <class 'NoneType'> for None
```
thanks to something like
```python
def SetParameterValue(self, paramKey, value):
paramType = self.GetParameterType(paramKey)
if paramType in [ParameterType_RAM,
ParameterType_String, ParameterType_InputFilename,
ParameterType_OutputImage, ParameterType_OutputVectorData,
ParameterType_OutputFilename,
ParameterType_Directory, ParameterType_InputImage,
ParameterType_InputVectorData]:
if not isinstance(value, str):
raise TypeError('Expected a string for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterString(paramKey, value)
elif paramType in [ParameterType_InputImageList, ParameterType_InputVectorDataList,
ParameterType_InputFilenameList, ParameterType_StringList,
ParameterType_ListView]:
if not isinstance(value, list):
raise TypeError('Expected a list for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterStringList(paramKey, value)
elif paramType in [ParameterType_Int, ParameterType_Radius]:
if not isinstance(value, int):
raise TypeError('Expected an int for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterInt(paramKey, value)
elif paramType in [ParameterType_Float]:
if not isinstance(value, float):
raise TypeError('Expected a float for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterFloat(paramKey, value)
elif paramType in [ParameterType_Double]:
if not isinstance(value, float):
raise TypeError('Expected a float for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterDouble(paramKey, value)
elif paramType in [ParameterType_Bool]:
if not isinstance(value, bool):
raise TypeError('Expected a bool for %s, got %s for %s' % (paramKey, type(value), value))
return self.SetParameterString(paramKey, str(value) )
elif paramType in [ParameterType_Group]:
return ApplicationProxy(self, paramKey)
elif paramType in [ParameterType_Choice]:
return ApplicationProxy(self, paramKey, value)
else:
print ("Unsupported parameter type '%s' with key '%s'" %(self.GetParameterTypeAsString(paramType) ,paramKey))
return
```
All I've added are tests + `raise`. It seems that some implicit conversions work like `string` to `bool` though. A more precise analysis shall be done in order to ignore the implicit conversions which are already supported.8.1.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2176Incorrect epipolar size in StereoRectificationGridGenerator2021-11-08T10:04:04ZsteuxyoIncorrect epipolar size in StereoRectificationGridGenerator### Description
We noticed an error in the epipolar sizes generated by the `StereoRectificationGridGenerator` function when the pixel size in not 1.
This leads to an error when followed by the `GridBasedImageResampling` function, using ...### Description
We noticed an error in the epipolar sizes generated by the `StereoRectificationGridGenerator` function when the pixel size in not 1.
This leads to an error when followed by the `GridBasedImageResampling` function, using the outputs `epi.rectsizex` `epi.rectsizey` `epi.baseline` for example. These outputs are incoherent with the generated grid.
Epipolar `mean_spacing` is not returned by `StereoRectificationGridGenerator`, therefore epipolarsize is not enough to parametrize `GridBasedImageResampling`
### Steps to reproduce
If you chain `StereoRectificationGridGenerator` with `GridBasedImageResampling` using the generated epiplar sizes :
- Using an image with the pixel resolution of 1 :
image size : 500 x 500
the resampled epipolar image 612 x 612 :
<img src="/uploads/845de0f50fd94e9d7f78d2b74cbfdb92/image.png" width="250" >
- Using an image with the pixel resolution of 2 ( for example generated resampling the previous image):
image size : 225 x 225
the resampled epipolar image 306 x 306 :
<img src="/uploads/d9b20a14256b1c2b1721fe6cbe00b17a/image.png" width="300">
- Using an image with the pixel resolution of 0.5 :
image size : 1000 x 1000
the resampled epipolar image 1225 x 1225 :
<img src="/uploads/7b144080e73e5c5f602499b448c06bd9/image.png" width="200">
### Configuration information
- Unix
- otb/7.0-python3.7.2
- otb-depends/7.0-python3.7.2https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2177Document the supported sensors2021-12-01T07:17:10ZJulien OsmanDocument the supported sensors### Target documentation resources
Either the CookBook or the websites. Or both (a complete description on the cookbook and a summary on the webpage)?
### Change requested
Describe precisely the sensors supported by OTB. "All sensor s...### Target documentation resources
Either the CookBook or the websites. Or both (a complete description on the cookbook and a summary on the webpage)?
### Change requested
Describe precisely the sensors supported by OTB. "All sensor supported by GDAL" is not accurate. OTB doesn't read the metadata in the same way for all the sensor. Some applications don't work for every sensor. All this subtleties need to be documented.8.0.0Julien OsmanJulien Osmanhttps://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/2179Using montevardi app for hyperspectral unmixing of 3d tif stacks2021-04-06T09:06:47ZSKUsing montevardi app for hyperspectral unmixing of 3d tif stacksHello,
I am a first time user of this toolbox for the purpose of unmixing some fluorescence images.
I have 2 tif stacks each of dimension 512*512*32 where 32 is the number of frames. They are of different wavelengths. I'd like to know ...Hello,
I am a first time user of this toolbox for the purpose of unmixing some fluorescence images.
I have 2 tif stacks each of dimension 512*512*32 where 32 is the number of frames. They are of different wavelengths. I'd like to know how to use this toolbox to unmix these stacks.
I tried to make a hyperstack using ImageJ with the 2 channel image stacks above. Choosing 512 mb as RAM, i click 'execute' on the EndmemberNumberEstimation page of montevardi application. The end members estimates comes up as 1 with "virtual dimensionality" algorithm.
Next, i select the VertexComponentAnalysis" and run it with the hyperstack. This gives the error: : Invalid Matrix size. Number of columns must be the same as the image number of channels.
Can someone please tell me how to use this app with the above image stacks ?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2180Modernize the code of factories in OTB2022-01-13T13:42:02ZThibaut ROMAINModernize the code of factories in OTBShort summary
The current design of factories in OTB can be reworked to be more efficient, and more C++1x compliant.
At the moment we use an old fashioned code to handle concurrency and we register a new factory each time we request an...Short summary
The current design of factories in OTB can be reworked to be more efficient, and more C++1x compliant.
At the moment we use an old fashioned code to handle concurrency and we register a new factory each time we request an object creation. We could use std::once to register our factories once, or use singletons.
This change will not give a significant performance boost because objects instantiation done using factories is only a small part of objects instantiation in OTB, but it is worth modernizing this code to make it safer and easier to understandThibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2181K parameter has no effect in KNN classifier2021-05-05T07:43:51ZCédric TraizetK parameter has no effect in KNN classifierBug reported by users on [the forum](https://forum.orfeo-toolbox.org/t/problem-with-input-k-in-knn-trainvectorclassifier/956)
When using the KNN classifier, for example in `TrainVectorClassifier` or `TrainImageClassifier`, the input num...Bug reported by users on [the forum](https://forum.orfeo-toolbox.org/t/problem-with-input-k-in-knn-trainvectorclassifier/956)
When using the KNN classifier, for example in `TrainVectorClassifier` or `TrainImageClassifier`, the input number of neighbor has no impact on the trained classifier.
Step to reproduce: (OTB 7.2.0)
``` bash
otbcli_TrainVectorClassifier -io.vd trainExtract.shp -io.out knn.txt -cfield classlabel -feat value_0 value_1 -classifier knn -valid.vd validExtract.shp -classifier.knn.k 10
[...]
2021-04-16 11:43:46 (INFO) TrainVectorClassifier: Confusion matrix (rows = reference labels, columns = produced labels):
[0] [1] [2] [3]
[0] 25 0 1 0
[1] 0 296 0 0
[2] 9 0 76 7
[3] 0 21 0 593
[...]
otbcli_TrainVectorClassifier -io.vd trainExtract.shp -io.out knn.txt -cfield classlabel -feat value_0 value_1 -classifier knn -valid.vd validExtract.shp -classifier.knn.k 1
[...]
2021-04-16 11:43:46 (INFO) TrainVectorClassifier: Confusion matrix (rows = reference labels, columns = produced labels):
[0] [1] [2] [3]
[0] 25 0 1 0
[1] 0 296 0 0
[2] 9 0 76 7
[3] 0 21 0 593
[...]
```7.3.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2182Take into account AREA_OR_POINT metadata for GeoTIFF images2021-11-08T10:03:05ZThibaut ROMAINTake into account AREA_OR_POINT metadata for GeoTIFF imagesThe geoTIFF format provides 2 ways of describing the raster space : http://geotiff.maptools.org/spec/geotiff2.5.html
GDAL correctly handles those two ways since 3.2.0. (see : https://github.com/opengeospatial/ogcapi-coverages/issues/92)...The geoTIFF format provides 2 ways of describing the raster space : http://geotiff.maptools.org/spec/geotiff2.5.html
GDAL correctly handles those two ways since 3.2.0. (see : https://github.com/opengeospatial/ogcapi-coverages/issues/92)
In OTB 7.x, the metadata key AREA_OR_POINT was read in the keywordlist allowing GDAL to determine if a shift has to be applied on the GCP position. This metadata key was written on the output image, so input and output images had the same raster space.
In OTB 8.0, this metadata is not read, thus the output images always have a default value for AREA_OR_POINT (Area, as described in gdal documentation), instead of taking the value from the input image. This causes problems because GDAL now makes a differences between the two modes, which results failing tests due to a difference of AREA_OR_POINT between the baseline and the tests, leading to shifted GCPs.
Actions :
- Add "AREA_OR_POINT" key in otbMetadataKey
- Read it in GDALImageIO
- Write it in GDALImageIO
- Update the baseline => cherry-pick the commit d20ac1c13dc14c2be4cc14c965709d2e6e648957 from release-7.38.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2183Update GDAL to last patch version of 3.x in Superbuild2021-04-20T07:12:55ZMickael SavinaudUpdate GDAL to last patch version of 3.x in SuperbuildCurrent version of GDAL in Superbuild is 3.2.1 but the last version of GDAL 3.x is 3.2.2. It could be interesting for 7.3 release to update to 3.2.2 cf. [changelog](https://github.com/OSGeo/gdal/blob/v3.2.2/gdal/NEWS)Current version of GDAL in Superbuild is 3.2.1 but the last version of GDAL 3.x is 3.2.2. It could be interesting for 7.3 release to update to 3.2.2 cf. [changelog](https://github.com/OSGeo/gdal/blob/v3.2.2/gdal/NEWS)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2184Update OpenJPEG to the last patch version of 2.3 in Superbuild2021-04-22T15:55:09ZMickael SavinaudUpdate OpenJPEG to the last patch version of 2.3 in SuperbuildCurrent version of OpenJPEG is 2.3.0 in Superbuild but a patch version exists 2.3.1 cf. [changelog](https://github.com/uclouvain/openjpeg/blob/v2.3.1/CHANGELOG.md). It could be interesting to update to 2.3.1 for 7.3.Current version of OpenJPEG is 2.3.0 in Superbuild but a patch version exists 2.3.1 cf. [changelog](https://github.com/uclouvain/openjpeg/blob/v2.3.1/CHANGELOG.md). It could be interesting to update to 2.3.1 for 7.3.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2185Update OpenJPEG to 2.4 in Superbuild2021-04-29T13:01:44ZMickael SavinaudUpdate OpenJPEG to 2.4 in SuperbuildCurrent version of OpenJPEG is 2.3.0 in Superbuild but a minor version exist 2.4.0 cf. [changelog](https://github.com/uclouvain/openjpeg/blob/v2.4.0/CHANGELOG.md). It could be interesting to update to 2.4.0 for 7.3.Current version of OpenJPEG is 2.3.0 in Superbuild but a minor version exist 2.4.0 cf. [changelog](https://github.com/uclouvain/openjpeg/blob/v2.4.0/CHANGELOG.md). It could be interesting to update to 2.4.0 for 7.3.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2186Update superbuild dependencies (patch version)2021-04-29T12:44:32ZMickael SavinaudUpdate superbuild dependencies (patch version)Several dependencies can be updated at patch level :
- [x] EXPAT from 2.1.0 to 2.1.1 Upated to 2.3 due to security issue : !815
- [x] fftw from 3.3.8 to 3.3.9 #2189
- [x] GEOS from 3.6.1 to 3.6.5 #2190
- [ ] hdf5 from 1.10.1 to 1.10.7...Several dependencies can be updated at patch level :
- [x] EXPAT from 2.1.0 to 2.1.1 Upated to 2.3 due to security issue : !815
- [x] fftw from 3.3.8 to 3.3.9 #2189
- [x] GEOS from 3.6.1 to 3.6.5 #2190
- [ ] hdf5 from 1.10.1 to 1.10.7
- [x] libjpeg-turbo from 1.4.1 to 1.4.2
- [x] MUPARSERX from 4.0.7 to 4.0.8
- [x] netcdf-cfrom 4.7.3 to 4.7.4
- [x] OPENCV from 4.1.1 to 4.1.2
- [x] OpenSceneGraph /OpenThreads from 3.4.0 to 3.4.1
- [x] libpng 1.6.16 to 1.6.37
- [x] qwt from 6.1.5 to 6.1.6
- [x] swig from 3.0.7 to 3.0.12
- [x] zlib from 1.2.8 to 1.2.11
- [x] GDAL cf. #2183
- [x] OpenJPEG cf. #2184
These updates has been done in release-7.3 branch, they will be backported to develop7.3.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2187Update Superbuild dependencies (minor version)2022-01-07T11:15:36ZMickael SavinaudUpdate Superbuild dependencies (minor version)Several dependencies can be updated at minor level :
- [ ] Boost from 1.69 to 1.76
- [ ] CURL from 7.54.1 to 7.76.1
- [x] EXPAT from 2.1.0 (or 2.1.1) to 2.3.0 done in release-7.3 and develop
- [x] GEOS from 3.6.1 (or 3.6.5) to 3.9.1
- [...Several dependencies can be updated at minor level :
- [ ] Boost from 1.69 to 1.76
- [ ] CURL from 7.54.1 to 7.76.1
- [x] EXPAT from 2.1.0 (or 2.1.1) to 2.3.0 done in release-7.3 and develop
- [x] GEOS from 3.6.1 (or 3.6.5) to 3.9.1
- [x] geotiff from 1.5.1 to 1.6.0
- [ ] gsl from 2.3.0 to 2.6.0
- [ ] hdf5 from 1.10.1 (1.10.7) to 1.12
- [ ] libjpeg-turbo from 1.4.1 (or 1.4.2) to 1.5.3
- [ ] netcdf-c from 4.7.3 (4.7.4) to 4.8.0
- [x] OPENCV from 4.1.1 (4.1.2) to 4.5.2
- [x] OPENSSL from 1.0.1 to 1.1.1 done in release-7.3 for security reasons
- [ ] OpenSceneGraph from 3.4.0 (3.4.1) to 3.6.5
- [ ] proj from 6.2.1 to 6.3.2.tar.gz
- [x] qt from 5.11.3 to 5.15.2
- [ ] tiff from 4.2.0 to 4.3.0
- [ ] OpenJPEG from 2.3.0 to 2.4.08.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2188Update Superbuild dependencies (major version)2022-01-07T11:15:51ZMickael SavinaudUpdate Superbuild dependencies (major version)Several dependencies can be updated at major level:
- [ ] glew from 1.13.0 to 2.1.0
- [ ] freeglut from 2.8.1 to 3.2.1
- [ ] libjpeg-turbo from 1.4.1 to 2.0.6
- [x] proj from 6.2.1 to 8.0.0
- [ ] qt from 5.11.3 to 6
- [x] swig from 3.0.7...Several dependencies can be updated at major level:
- [ ] glew from 1.13.0 to 2.1.0
- [ ] freeglut from 2.8.1 to 3.2.1
- [ ] libjpeg-turbo from 1.4.1 to 2.0.6
- [x] proj from 6.2.1 to 8.0.0
- [ ] qt from 5.11.3 to 6
- [x] swig from 3.0.7 to 4.0.28.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2189Update superbuild dependencies for fftw2021-04-29T12:56:01ZMickael SavinaudUpdate superbuild dependencies for fftwMove fftw from 3.3.8 to 3.3.9 in Superbuild cf. [Release Notes](http://www.fftw.org/release-notes.html)Move fftw from 3.3.8 to 3.3.9 in Superbuild cf. [Release Notes](http://www.fftw.org/release-notes.html)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2190Update superbuild dependencies for geos (patch version)2021-04-22T15:56:20ZMickael SavinaudUpdate superbuild dependencies for geos (patch version)Move geos from 3.6.1 to 3.6.5 cf. [NEWS](https://github.com/libgeos/geos/blob/svn-3.6/NEWS)Move geos from 3.6.1 to 3.6.5 cf. [NEWS](https://github.com/libgeos/geos/blob/svn-3.6/NEWS)