otb merge requestshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests2019-09-19T08:55:00Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/191Parameter Refactoring : String Parameter2019-09-19T08:55:00ZAntoine RegimbeauParameter Refactoring : String Parameter**The target branch of this MR is *param_refactoring***
This MR presents the new `StringParameter` class. It derives from the `SingleParameter` class. Here is its API :
```c++
public :
virtual void SetDefaultValue( std::string val...**The target branch of this MR is *param_refactoring***
This MR presents the new `StringParameter` class. It derives from the `SingleParameter` class. Here is its API :
```c++
public :
virtual void SetDefaultValue( std::string val)
virtual const std::string & GetDefaultValue() const
virtual void Reset() override
//Public coming from the SingleParameter class
virtual void SetValue( const std::string & val , int i = 0 ) override
virtual std::string GetValue( int i = -1 ) const override
//Public coming from the Parameter class
/*(function toggling boolean such as Mandatory, Active, UserValue, UserLevel
or dealing with Role, Root, Key, Name and Description are omitted)*/
virtual void ClearValue()
virtual std::string GetValue( int i = -1 ) const = 0;
virtual void SetValue( const std::string & val , int i = 0 ) = 0;
```
If you have any ideas or comments on what we could add to the API of the parameter, feel free to express yourself!
As this kind of MR has not been done for the other classes (Parameter, SingleParameter, NumericalParameter) you can also comment on it here.
Associated MR !367.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/938Robust extended filename options interpretation2022-10-18T09:39:48ZRémi CressonRobust extended filename options interpretation#### Summary
Closes #2312
#### Rationale
When input file paths are HTTP URIs, like the one we can use with [vsicurl](https://gdal.org/user/virtual_file_systems.html#network-based-file-systems), the extended filename options deduction...#### Summary
Closes #2312
#### Rationale
When input file paths are HTTP URIs, like the one we can use with [vsicurl](https://gdal.org/user/virtual_file_systems.html#network-based-file-systems), the extended filename options deduction can be a mess.
The current implementation only split the filename from the first encountered `?` character.
This is wrong, since such character can be part of a HTTP request pointing to an online raster file.
#### Implementation Details
The new implementation consider that the last occurrence of `?&` marks the beginning of the extended filename options.
##### Classes and files
- ENH: `Modules/Core/Common/src/otbExtendedFilenameHelper.cxx` (new implementation)
- REFAC: `Modules/IO/ExtendedFilename/src/otbExtendedFilenameToReaderOptions.cxx` (shorter code)
- FIX: some tests contained wrong extended filename pattern ([the documentation](https://www.orfeo-toolbox.org/CookBook/ExtendedFilenames.html) clearly states the right pattern is _Path/Image.ext_**?&**_key1=value1&key2=value2_).
- `Modules/Adapters/GdalAdapters/test/CMakeLists.txt`
- `Modules/IO/ExtendedFilename/test/CMakeLists.txt`
- `Modules/IO/ImageIO/test/CMakeLists.txt`
- `Modules/Applications/AppSARCalibration/test/CMakeLists.txt`
- `Modules/Core/ImageBase/test/CMakeLists.txt`
#### Copyright
The copyright owner is *INRAE* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commitRémi CressonRémi Cressonhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/937Draft: Reduce memory footprint when ImageFileWriter can't stream its input pi...2022-10-18T08:37:20ZRémi CressonDraft: Reduce memory footprint when ImageFileWriter can't stream its input pipeline to the output fileCloses #2310
This MR enables to reduce memory footprint to write output images into file formats that does not support streaming write.
# Benchmarks
All benchmarks have been performed on a laptop with 32Gb RAM, SSD, Ubuntu 20.04 + a l...Closes #2310
This MR enables to reduce memory footprint to write output images into file formats that does not support streaming write.
# Benchmarks
All benchmarks have been performed on a laptop with 32Gb RAM, SSD, Ubuntu 20.04 + a lot of tabs opened in web browser (that makes roughly **20Gb** RAM available). We let OTB with the default `OTB_MAX_RAM_HINT` which I believe is 256Mb.
Our goal is to perform the pansharpening of a Spot-7 (or Pléiades, or PNeo) image, in an output image format for which the GDAL driver only supports the `GDALDriver::CreateCopy()`, which is intended to create a copy of an existing dataset (hence the whole dataset must already exist, either in-memory or in another raster file).
In the following, we use the [GDAL Cloud Optimized Geotiff driver](https://gdal.org/drivers/raster/cog.html) to write the output image.
We use the following command to perform the processing:
```
otbcli_BundleToPerfectSensor -inp $dim_pan -inxs $dim_xs -out "/data/pxs.tif" int16
```
We did use some Spot-7 image but of course we expect the same kind of behavior for Pléiades and PNeo.
# Measurements
We have measured the processing time on the `BundleToPerfectSensor`.
## 10k x 10k subset:
When everything is fine, and the memory budget is enough.
* BundleToPerfectSensor (cog): **52s**
- BundleToPerfectSensor (cog, OTB_FORCE_STREAMING=1): **53s**
## 20k x 20k subset:
When the image is big and the processing without streaming requires extra memory.
### Original approach (trigger the entire pipeline, everything is in-memory)
![Fail](/uploads/2d18343dd79e5a5162f6eeb00539674e/image140.jpg)
### Proposed approach (when OTB_FORCE_STREAMING is set to 1)
![Force_streaming](/uploads/d5d88d1354feb5e56fb49964af251500/toto.jpg)
### Comparison with original approach + gdal_translate
- BundleToPerfectSensor (cog, `OTB_FORCE_STREAMING=1`): **3m37s**
- BundleToPerfectSensor (gtiff) + gdal_translate (cog): 1m24s + 2m09s = **3m33s**
# Conclusion
## PROS
- The MR enables to save memory when writing output image format for which the GDAL driver only supports the `GDALDriver::CreateCopy()`
## CONS
- Saving the output image in a streamable-capable raster format + using gdal_translate to achieve the final conversion is **as fast**, and **use a ridiculous smaller memory footprint** (because the whole output image is not stored in memory).
- Ultimately, there will always be an image size, for which the memory budget won't be enough, even with the `OTB_FORCE_STREAMING` approach. In this case, the user will fall back to the otb + gdal_translate approach.
# Discussion
Maybe this MR should be generalized to python API in order to get the output as numpy array with `OTB_FORCE_STREAMING` (for now, the entire pipeline is triggered over the largest possible image region).Rémi CressonRémi Cressonhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/926rpcSolver: Avoid setting equation system multiple times2022-09-01T08:49:43ZJulien OsmanrpcSolver: Avoid setting equation system multiple times#### Summary
Implements !897 that was closed prematurely.
Also update the link to the Geoid files, [after a message on the forum](https://forum.orfeo-toolbox.org/t/update-egm96-gr-hdr-file-in-otb-data-repository/1435?u=julienosman).
#...#### Summary
Implements !897 that was closed prematurely.
Also update the link to the Geoid files, [after a message on the forum](https://forum.orfeo-toolbox.org/t/update-egm96-gr-hdr-file-in-otb-data-repository/1435?u=julienosman).
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.1.0Julien OsmanJulien Osmanhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/917Avoid reloading the same DEM directory2022-07-12T18:53:22ZJulien OsmanAvoid reloading the same DEM directory#### Summary
Avoid reloading the same DEM directory.
Fix segfault when a corrupted simlink is present in the DEM directory.
#### Rationale
To set the directory containing the DEM in the DEMHandler, one calls `DEMHandler::OpenDEMDirec...#### Summary
Avoid reloading the same DEM directory.
Fix segfault when a corrupted simlink is present in the DEM directory.
#### Rationale
To set the directory containing the DEM in the DEMHandler, one calls `DEMHandler::OpenDEMDirectory`. Due to how the Application framework works, with the DoUpdateParameters function being called for each parameter, the same directory may be set multiple times, unloading and loading the same data each time. To avoid this, we propose to modify the DEMHandler so it doesn't reload a directory if one calls `DEMHandler::OpenDEMDirectory` with the same path.
Also, when there is a simlink in the DEM directory, if this simlink links to itself, it makes OTB exit with a segfault. We propose to handle this case correctly by ignoring this simlink.
#### Implementation Details
##### Classes and files
- `Modules/IO/IOGDAL/src/otbDEMHandler.cxx`
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.1.0Julien OsmanJulien Osmanhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/916Draft: Resolve "Add support for Pleiades Neo products"2023-06-05T12:59:58ZFlorian DouziechDraft: Resolve "Add support for Pleiades Neo products"Closes #2289Closes #22898.2.0Florian DouziechFlorian Douziechhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/904ENH: Add default radius value to NewFunctorFilter overload2022-08-11T06:54:20ZLaurențiu NicolaENH: Add default radius value to NewFunctorFilter overloadThis should allow the usage described at the bottom of https://www.orfeo-toolbox.org/CookBook-8.0/C++/FunctorImageFilter.html#number-of-output-bands.This should allow the usage described at the bottom of https://www.orfeo-toolbox.org/CookBook-8.0/C++/FunctorImageFilter.html#number-of-output-bands.8.1.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/890ADD: role output for mean, min, max, std2022-04-12T05:45:57ZRémi CressonADD: role output for mean, min, max, stdCloses #2261
I took the liberty to add the following in the stats.
- min
- max
In the proposed implementation, the output are strings.
Maybe it could be better to have a proper parameter_output dedicated to pixels? Maybe that is part...Closes #2261
I took the liberty to add the following in the stats.
- min
- max
In the proposed implementation, the output are strings.
Maybe it could be better to have a proper parameter_output dedicated to pixels? Maybe that is part of another issue8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/862Add INFO message about metadata source2021-11-03T16:19:37ZJulien OsmanAdd INFO message about metadata source#### Summary
An *INFO* message indicates where the metadata were read. It can be either the product itself, an GEOM file next to the product or an external GEOM file.
#### Implementation Details
##### Classes and files
Add the log me...#### Summary
An *INFO* message indicates where the metadata were read. It can be either the product itself, an GEOM file next to the product or an external GEOM file.
#### Implementation Details
##### Classes and files
Add the log message in ImageFileReader.
#### Additional notes
This behavior was present in OTB 7.4, and was accidentally removed with OSSIM.
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.0.0Julien OsmanJulien Osmanhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/849FIX: mosaic output image size fit best inputs extents2021-08-30T08:17:30ZRémi CressonFIX: mosaic output image size fit best inputs extents#### Summary
Closes #2217
#### Rationale
The Mosaic application computes the output image origin, size, and spacing in the `GenerateOutputInformation` method of the base mosaic filter.
First, the extent of the output image is retrie...#### Summary
Closes #2217
#### Rationale
The Mosaic application computes the output image origin, size, and spacing in the `GenerateOutputInformation` method of the base mosaic filter.
First, the extent of the output image is retrieved. The pixel spacing is computed from the smallest pixel spacing values of the input images. Then, the origin is computed (from this pixel spacing, and the extent). After that, the output image size is finally computed.
In the current implementation, the output image size is rounded to the upper number of pixels (the idea was to avoid losing one col/row of pixels, and it was not a big deal if we add some extra row/col to the output image):
```
// Set final size
m_OutputSize[0] = vcl_floor((extentSup[0] - extentInf[0]) / vcl_abs(m_OutputSpacing[0])) + 1;
m_OutputSize[1] = vcl_floor((extentSup[1] - extentInf[1]) / vcl_abs(m_OutputSpacing[1])) + 1;
```
However this is very embarrassing when you need to mosaic several images of the same extent/size, because the output image size will have +1 row/col.
The proposed change intend to correct that using `std::round` to compute the output image size from the extent and the pixel spacing.
This way, the output image size is more correctly adjusted and fits better the actual content: if the continuous size of the output image falls between the start corner of the pixel and its center, it will be rounded to the lower number. If it falls between its center and its end corner, it will be rounded to the upper number.
```
// Set final size (proposed changes)
m_OutputSize[0] = std::round((extentSup[0] - extentInf[0]) / vcl_abs(m_OutputSpacing[0]));
m_OutputSize[1] = std::round((extentSup[1] - extentInf[1]) / vcl_abs(m_OutputSpacing[1]));
```
#### Implementation Details
##### Classes and files
Only 2 lines of `Modules/Filtering/Mosaic/include/otbStreamingMosaicFilterBase.hxx` are changed (as described above).
##### Tests
~~If we are lucky, tests could pass (depending on the rounding of the input images extents...)~~
If not, the baseline of **all Mosaic tests** must be updated.
##### Documentation
No need
#### Copyright
The copyright owner is INRAe (ex-IRSTEA) and has signed the ORFEO ToolBox Contributor License Agreement.7.4.0Rémi CressonRémi Cressonhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/812Resolve "Update OpenJPEG to the last patch version of 2.3 in Superbuild"2021-04-21T15:29:38ZMickael SavinaudResolve "Update OpenJPEG to the last patch version of 2.3 in Superbuild"Closes #2184Closes #2184Mickael SavinaudMickael Savinaudhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/809Update version of diapOTB to 1.0.12021-06-09T13:53:34ZJulien OsmanUpdate version of diapOTB to 1.0.1#### Summary
Include latest release of DiapOTB (v1.0.1)
#### Rationale
DiapOTB v1.0.1 is about to be released. The purpose of this MR is to include this new release in OTB.
#### Implementation Details
The first step consist in setti...#### Summary
Include latest release of DiapOTB (v1.0.1)
#### Rationale
DiapOTB v1.0.1 is about to be released. The purpose of this MR is to include this new release in OTB.
#### Implementation Details
The first step consist in setting the DiapOTB tag to v1.0.1, to follow DiapOTB's release branch. This allow to run the CI on this release branch.
When DiapOTB's release is official, the tag will be changed to the release commit value.
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit7.3.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/799Switch to c++172023-04-03T06:21:10ZJulien OsmanSwitch to c++17#### Summary
Upgrade to the C++ 2017 standard
#### Rationale
OTB is currently compiled with c++14. Now that the c++17 standard is well implemented by the compilers, we could upgrad to c++17. This would come with a lot of advantages:
...#### Summary
Upgrade to the C++ 2017 standard
#### Rationale
OTB is currently compiled with c++14. Now that the c++17 standard is well implemented by the compilers, we could upgrad to c++17. This would come with a lot of advantages:
- There are a lot of TODOs in the code telling that when we switch to c++17 we will be able to simplify that part of code.
- The new `std::clamp` is useful (and could simplify !797).
- We will be able to remove the homemade emulation of the string_view, and use the standard one.
- A bunch of new algorithms and mathematical functions.
- Some new features concerning the templates
- The new `if constexpr` will be handful to simplify the code.
- Many other goodies.
This update means we drop support for older compilers (like VisualC++14).
#### Implementation Details
Modify CMAKE_CXX_STANDARD to 17 in main CMakeFiles.txt.
Remove the REGISTER keyword from 6S code.
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commithttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/795Improve opticalibration pleiades2021-04-06T20:32:40ZThibaut ROMAINImprove opticalibration pleiadesCloses #2123 and #2161
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from ...Closes #2123 and #2161
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.0.0Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/793COMP: Add a high level OTB_WRAP_QGIS cmake option and Fix BUILD_DEFAULT_MODUL...2021-03-09T20:36:34ZThibaut ROMAINCOMP: Add a high level OTB_WRAP_QGIS cmake option and Fix BUILD_DEFAULT_MODULE bug when listing module dependenciesCloses #2139
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core devel...Closes #2139
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.0.0Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/769Resolve "Missing kernels parameters in libsvm"2021-04-16T11:24:24ZRémi CressonResolve "Missing kernels parameters in libsvm"Add the following parameters for libsvm:
- gamma (used in `rbf`, `poly`, `sigmoid` kernel functions)
- coef0 (used in `poly`, `sigmoid` kernel functions)
- degree (used in `Poly` kernel function)
Closes #2124Add the following parameters for libsvm:
- gamma (used in `rbf`, `poly`, `sigmoid` kernel functions)
- coef0 (used in `poly`, `sigmoid` kernel functions)
- degree (used in `Poly` kernel function)
Closes #21248.0.0Rémi CressonRémi Cressonhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/767ENH: Improve QGIS interface for ExtractROI application2021-08-17T09:23:03ZJulien CabiecesENH: Improve QGIS interface for ExtractROI application#### Summary
This Merge request proposes to fix/improve some issues in QGIS ExtractROI parameters selection IHM.
#### Rationale
Hi,
I'm Julien Cabieces and I work for Oslandia on behalf of CNES and I'm a regular QGIS contributor (@tr...#### Summary
This Merge request proposes to fix/improve some issues in QGIS ExtractROI parameters selection IHM.
#### Rationale
Hi,
I'm Julien Cabieces and I work for Oslandia on behalf of CNES and I'm a regular QGIS contributor (@troopa81 on GitHub). I will contribute occasionally to OTB in order to improve OTB interface in QGIS.
I'll do my best to to contribute as expected in contribution guidelines. still, if I miss something please let me know.
This first PR is about fixing *ExtractRoi* application. When user try to use this application from QGIS, he faces two issues:
- **1.** When you select an other mode than *standard* one, you still have the standard parameters (Start X, Start Y, Size X, Size Y)
- **2.** On *fit* mode, you have to select both a vector and a raster when only one should be needed
#### Implementation Details
- **1.**
The issue is due to the fact that these parameters switch from *Input_Role* in *standard mode* to *Output_Role* in the other modes (in order to print the computed extent), but QGIS is not aware of this. I propose to add specific parameter for standard, and keep the actual ones as always output. One drawback of this is that the parameter are repeated in standard mode in Monteverdi.
![extractroi](/uploads/3e0994c3322df05aa8dd18df5b23f890/extractroi.png)
Another drawback is if some people use it from the command line, they'd have to change *startx* parameters to *mode.standard.x* (same for starty, sizex, sizey). I'm not sure if this is considered as an *API break* and should be documented/advertised somewhere.
- **2.** Both *reference vector* and *reference image* fields are Mandatory and their state switch in *DoUpParameters*. I propose to set them as not mandatory in *DoInit* and update their state in *DoUpdateParameters*.
<!---
##### Classes and files
Give an overview of the implementation: main changes made to classes, files and modules. Do not paste complete diff, as it is available in the merge request already.
-->
<!---
##### Applications
Describe any changes made to existing applications, or new applications that have been added.
-->
<!---
##### Tests
Describe the testing strategy for new features.
-->
<!---
##### Documentation
List or link documentation modifications that were made (doxygen, example, Software Guide, application documentation, CookBook).
-->
#### Additional notes
<!--- List remaining open issues if any, and additional notes. -->
#### Copyright
The copyright owner is Oslandia and has signed the ORFEO ToolBox Contributor License Agreement.
cc @ytanguy @esarrazin
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit8.0.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/736Integrate S1Tiling support apps as official remote module2020-10-05T11:59:05ZLuc HermitteIntegrate S1Tiling support apps as official remote module#### Summary
@tkoleck and I propose in this MR the integration of [S1Tiling](https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling) support applications as an official remote module.
#### Rationale
This remote module is made of 4 applic...#### Summary
@tkoleck and I propose in this MR the integration of [S1Tiling](https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling) support applications as an official remote module.
#### Rationale
This remote module is made of 4 applications that we'll like to see distributed alongside OTB.
We actually plan to eventually propose the applications as official OTB applications, but prefer first to provide them as a remote module.
#### Implementation Details
Comments on the code are welcomed. In particular, I have doubts regarding the documentation tags to use.
##### Applications
The following applications are provided:
- `ClampROI`: that sets margins to 0 outside the ROI -- name suggestions are welcomed
- `Synthetize`: that iterates overs a list of overlapping images to keep the
first non null pixel -- name suggestions are welcomed
- `MultitempFilteringFilter`: that implements Quegan speckle filter for SAR Images.
- `MultitempFilteringOutcore`: that computes the outcore of the filter
##### Classes and files
A few helper classes and functions are provided. They should eventually be part of OTB. They are:
- `otb::Interval`, inspired by `boost::numeric::interval` but with a much simpler interface. It can be seen as a 1D region. Its main purpose is to check intersections between (1D) regions and simplify the definition of functions like the generation of input and/or ouput (requested regions)
- `otb::NeatRegionLogger` permits to change the way regions are logged, example: `x ∈ [0..42[, y ∈ [12..24[, size=42x12 @(0, 12)`
- `otb::Span<>` is a C++14 implementation of C++20 `std::span`.
- `otb::ZipIterator<>` aggregates (zips!) multiple image iterators into one. It permits to handle lists of images without having to pay the price for dynamic variable length vector pixels.
- `otb::Synthetize<>` is an alternative (C++) lambda compliant filter that works on list of images (instead of `VectorImage`s) -- name suggestions are welcomed. Note: the current OTBApplication kernel prevents this application from being _pipelined_ in memory.
Other filters are functors are dedicated to the multitemp filter applications.
##### Tests
Some tests exists but we'll have to find some storage to add the tests.
In the current state, tests will fail.
#### Copyright
The copyright owner is CNES and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit7.2.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/709Add "epsg" filename extension2020-07-09T08:39:30ZJulien OsmanAdd "epsg" filename extension#### Summary
Add the *epsg* new filename extension. It allows the user to chose the map projection of the output image.
#### Rationale
Fixes issue #1889.
#### Implementation Details
##### Classes and files
- *otbGDALImageIO*: Add ...#### Summary
Add the *epsg* new filename extension. It allows the user to chose the map projection of the output image.
#### Rationale
Fixes issue #1889.
#### Implementation Details
##### Classes and files
- *otbGDALImageIO*: Add possibility to define the output projection with EPSG code
- *otbExtendetFilenameToWriterOptions*: Add management of the EPSG code
- *otbImageFileWriter*: Providing the epsg code to otbGDALImageIO
##### Tests
- Add the epsg filename extension to the otbExtendetFilenameToWriterOptions tests
- Add a new test for ImageFileWriter that uses the epsg filename extension
##### Documentation
- Update cookbook page for Filename Extensions.
#### Additional notes
- Would be great to add the possibility to test the projection of the output image in the test named ioTvImageFileWriterTIF2TIF
#### Copyright
The copyright owner is *CS* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit7.2.0Mickael SavinaudMickael Savinaudhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/708Spectral angle classification2020-07-09T08:39:34ZCédric TraizetSpectral angle classification#### Summary
description wip
Refactor spectral angle functors in otb and add a new application : SpectralAngleClassification
closes #2012
#### SAM
The spectral angle mapper (SAM) and spectral information divergence (SID) ...#### Summary
description wip
Refactor spectral angle functors in otb and add a new application : SpectralAngleClassification
closes #2012
#### SAM
The spectral angle mapper (SAM) and spectral information divergence (SID) are widely used in hyperspectral image processing, but otb does not provide an application implementing these algorithms.
The SAM of a pixel `x` with a reference pixel `r` is defined by :
``` math
sam[x, r] = cos^{-1}(\frac{<x,r>}{\|x\| * \|r\| } )
```
where `<x,r>` denotes the scalar product between x and r. This is also called the spectral angle between `x` and `r`. In SAM classification the spectral angle is computed for each pixel with a set of reference pixels, the class associated with the pixel is the index of the reference pixel that has the lowest spectral angle.
In otb there are several classes that computes spectral angle :
1) `BinarySpectralAngleFunctor` : computes spectral angle between two pixels.
2) `SpectralAngleFunctor` : computes spectral angle between a pixel and a reference (different from the above because the norm of the reference is cached and not computed again for each pixel
3) `SpectralAngleDistanceImageFilter` : Filter computing spectral angle on an image (it doesn't use a functor).
4) `sqrtSpectralAngleFunctor` : computes the square root of the spectral angle between a pixel and a reference.
5) `waterSqrtSpectralAngleFunctor` : computes the square root of the spectral angle between a pixel and a reference, with band indices (`blue`, `green`, `red` and `nir`). Note that this functor is not available in the `RadiometricIndices` application.
6) `waterSqrtSpectralAngleFilter` : `UnaryFunctorImageFilter` specialized with `waterSqrtSpectralAngleFunctor`
7) `ConnectedComponentMuParserImageFunctor` : defines the `spectralAngle` variablr for muParser in the connected component framework.
All these classes re-implement the spectral angle computation. In these merge request, they have been refactored to use the function
``` cpp
template <class TInput, class TReference, class TOutput>
TOutput ComputeSpectralAngle(TInput const & input, typename TInput ::ValueType const & inputNorm,
TReference const & reference, typename TReference::ValueType refNorm)
```
Note that the norm of input pixels is a parameter of the same norm might be used for several spectral angle computations.
A new functor has been implement for spectral angle with a vector of reference pixels : `SpectralAngleMapperFunctor`, and is used is the new `SpectralAngleClassification` application.
`WaterSqrtSpectralAngleFunctor` has been refactored to be a `RadiometricIndex` and can be used with a `FunctorImageFilter` like the other radiometry filters (with the SetBandIndex/GetBandIndex syntax etc)
`WaterSqrtSpectralAngleImageFilter` has been deprecated to stay coherent with the other radiometry functor. The filters corresponding to the functor are not defined in this module, and are defined on the fly with the `NewFunctorFilter(functor)` free function.
`SpectralAngleDistanceImageFilter` has been deprecated because it is a clone of `FunctorImageFilter< SpectralAngleFunctor>`
#### SID
The probability mass function p of a pixel x is defined by :
``` math
x = [x_1, x_2 ,..., x_L ]^T \\
p = [p_1, p_2 ,..., p_L ]^T \\
p_i = \frac{x_i}{\sum_{j=1}^L x_j}
```
The spectral information divergence between a pixel `x` and a reference `r` is defined by :
``` math
sid[x, r] = \sum_{j=1}^{L} p_j *log(\frac{p_j}{q_j}) + \sum_{j=1}^{L} q_j * log(\frac{q_j}{p_j})
```
where p and q are respectively the probability mass function of x and r.
A new functor has been implemented to compute SID on a vector of reference pixel.
Note that SID is only defined for strictly positive pixels. The functor will throw an exception if one of the channel of its input (pixels and reference pixels) is negative or equal to 0.
#### SpectralAngleClassification
A new application has been added, it takes as input :
* `in` : a hyperspectral image
* `ie` : endmembers stored in an image. Possibly the output of [VertexComponentAnalysis](https://www.orfeo-toolbox.org/CookBook/Applications/app_VertexComponentAnalysis.html).
* `mode` : `sid` or `sam`, the algorithm to be used.
and output :
* `out` : the output classification, i.e. the index of the endmember corresponding to the min sid or sam value, starting at 1.
* `measure` : the computed sid or sam map.
Note that the two output supports `multiwriting`.
Additional parameters are :
* `threshold` : value of sid or sam above the threshold are not considered for classification and are classified as background (not mandatory, if not set all pixels are classfied).
* `bv` : the background value (default 0)
Two tests have been added (`sid` and `sam` modes)
#### Implementation Details
<!---
##### Classes and files
Give an overview of the implementation: main changes made to classes, files and modules. Do not paste complete diff, as it is available in the merge request already.
-->
<!---
##### Applications
Describe any changes made to existing applications, or new applications that have been added.
-->
<!---
##### Tests
Describe the testing strategy for new features.
-->
<!---
##### Documentation
List or link documentation modifications that were made (doxygen, example, Software Guide, application documentation, CookBook).
-->
#### Additional notes
<!--- List remaining open issues if any, and additional notes. -->
#### Copyright
The copyright owner is *CNES* and has signed the ORFEO ToolBox Contributor License Agreement.
<hr>
***Check before merging:***
- All discussions are resolved
- At least 2 :thumbsup: votes from core developers, no :thumbsdown: vote.
- The feature branch is (reasonably) up-to-date with the base branch
- Dashboard is green
- Copyright owner has signed the ORFEO ToolBox Contributor License Agreement
- Optionally, run `git diff develop... -U0 --no-color | clang-format-diff.py -p1 -i` on latest changes and commit7.2.0Cédric TraizetCédric Traizet