otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2020-08-21T17:50:07Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2070Uninitialized values (and ITK setters) in `otb::ImageToGenericRSOutputParamet...2020-08-21T17:50:07ZLuc HermitteUninitialized values (and ITK setters) in `otb::ImageToGenericRSOutputParameters`### Description
When `itkSetMacro()` is used with member-data left uninitialized in their constructors, quality related tools will emit error/warning messages.
### Steps to reproduce
It's for instance the case for valgrind that'll bar...### Description
When `itkSetMacro()` is used with member-data left uninitialized in their constructors, quality related tools will emit error/warning messages.
### Steps to reproduce
It's for instance the case for valgrind that'll barks things like
```
==26964== Conditional jump or move depends on uninitialised value(s)
==26964== at 0x34B56F4D: operator!= (itkSize.h:145)
==26964== by 0x34B56F4D: SetOutputSize (otbImageToGenericRSOutputParameters.h:106)
==26964== by 0x34B56F4D: otb::ImageToGenericRSOutputParameters<otb::VectorImage<float, 2u> >::EstimateOutputSize() (otbImageToGenericRSOutputParameters.hxx:249)
==26964== by 0x34B5CAE4: otb::ImageToGenericRSOutputParameters<otb::VectorImage<float, 2u> >::Compute() (otbImageToGenericRSOutputParameters.hxx:66)
==26964== by 0x34B5D137: otb::Wrapper::OrthoRectification::DoUpdateParameters() (otbOrthoRectification.cxx:285)
==26964== by 0x2D034A93: otb::Wrapper::Application::UpdateParameters() (otbWrapperApplication.cxx:490)
```
### Proposed resolution
I've identified the issue in `otb::ImageToGenericRSOutputParameters` class, where it could be fixed with
```c++
PointType m_OutputOrigin{0.0};
SpacingType m_OutputSpacing{0.0};
SizeType m_OutputSize{0, 0};
```
(IMO, the easiest is to use C++11 member initialization given we have these setters; and unfortunately ITK constructors prevents zero-initialisation with empty braces.)
I haven't checked whether it happens elsewhere.7.2.0Julie BrossardJulie Brossardhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2052Support for GDAL 3.12020-07-17T08:17:48ZCédric TraizetSupport for GDAL 3.1GDAL 3.1 is available ! See the related [osgeo post](https://www.osgeo.org/foundation-news/gdal-3-1-0-is-released/)
We should :
* Test OTB compatibility with this release, and modify the library accordingly.
* Upgrade gdal version in S...GDAL 3.1 is available ! See the related [osgeo post](https://www.osgeo.org/foundation-news/gdal-3-1-0-is-released/)
We should :
* Test OTB compatibility with this release, and modify the library accordingly.
* Upgrade gdal version in Superbuild to 3.1 ?7.2.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2014Refactor compare image2020-07-09T12:30:55ZGuillaume PaseroRefactor compare imageThe implementation of `otb::TestHelper::RegressionTestImage` could be improved, mostly to deal with large images. I was a bit shocked to read this at the beginning of the function:
```
baselineReader->UpdateLargestPossibleRegion();
[......The implementation of `otb::TestHelper::RegressionTestImage` could be improved, mostly to deal with large images. I was a bit shocked to read this at the beginning of the function:
```
baselineReader->UpdateLargestPossibleRegion();
[...]
testReader->UpdateLargestPossibleRegion();
```
and a few lines later, there is finally a check on the image size, to decide if we upload the difference image to CDash. But if your input images are large (let say a few GB), you already have flooded the RAM memory of your laptop, and maybe the swap as well. As OTB is supposed to manage properly large images this behaviour has to be changed.
My solution step by step:
* First call a `UpdateOutputInformation()` on both readers (baseline and test image) in a try/catch
* Check images have the same size
* Plug the pipeline with the `otb::DifferenceImageFilter` (also: add the Reset/Synthetise function to make it streamable)
* Test if the total number of pixel is above the "cdash" limit
* No: proceed with actual behaviour
* Update() on the difference filter
* check amount of different pixels
* rescale and write difference image as PNG, as well as baseline and test image
* Yes:
* plug a virtual writer after the difference image and update it (streaming processing)
* TBD: write the difference image (not as a PNG but as a geotiff)7.2.0Cédric TraizetCédric Traizethttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2012Spectral Information Divergence2020-07-17T08:19:04ZCédric TraizetSpectral Information DivergenceFeature request from the [forum](https://forum.orfeo-toolbox.org/t/feature-request-spectral-information-divergence/502) :
After abundance maps are generated by the following available module:
https://www.orfeo-toolbox.org/CookBook/App...Feature request from the [forum](https://forum.orfeo-toolbox.org/t/feature-request-spectral-information-divergence/502) :
After abundance maps are generated by the following available module:
https://www.orfeo-toolbox.org/CookBook/Applications/app_HyperspectralUnmixing.html
Could you add a module for classifying the bundance maps using Spectral Information-Divergence (SID) and Spectral Angle Mapper (SAM) like below?
https://pysptools.sourceforge.io/classification.html#spectral-information-divergence-sid
Thank you.7.2.0Cédric TraizetCédric Traizet