Different results between Segmentation and the actual chained individual processes

As far as I understand, these 2 approaches should render very similar results:

otbcli_Segmentation -in QB_Toulouse_Ortho_PAN.tif -mode vector -mode.vector.out QB_Toulouse_Ortho_PAN.shp -filter meanshift \
-filter.meanshift.spatialr 5 \
-filter.meanshift.ranger 15


otbcli_MeanShiftSmoothing -in QB_Toulouse_Ortho_PAN.tif -fout QB_Toulouse_Ortho_PAN_MS.tif -foutpos QB_Toulouse_Ortho_PAN_MS_spat.tif \
-spatialr 5 \
-ranger 15
otbcli_LSMSSegmentation -in QB_Toulouse_Ortho_PAN_MS.tif \
    -out  segmentation.tif uint32 \
    -ranger 7 \
    -spatialr 2 \
    -minsize 1
otbcli_LSMSVectorization -in QB_Toulouse_Ortho_PAN.tif -inseg segmentation.tif -out QB_Toulouse_Ortho_PAN_v2.shp

But the results are actually very different:



The Segmentation application using the MeanShift algorithm is not the same thing as using the individual LSMS applications individually. Segmentation applies the mean shift filter within the Segmentation framework (image tiling, segmentation, vectorization and merging of the resulting segments). In particular I don’t think Segmentation applies the smoothing algorithm.

If you want to reproduce the results of the individual applications in one step, you can try the LargeScaleMeanShift application (which actual calls the individual applications internally).


In particular I don’t think Segmentation applies the smoothing algorithm

Segmentation — Orfeo ToolBox 7.3.0 documentation states:
OTB implementation of the Mean-Shift algorithm

thus, how can it be a Mean shift algorithm with no smoothing?
Also, the parameters are the same as for MeanShift and the doc refers to
“This application chains together the 4 steps of the MeanShift framework, that is the [MeanShiftSmoothing] the [LSMSSegmentation], the [LSMSSmallRegionsMerging] and the [LSMSVectorization]”
What are the actual differences between both applications? I remind you that “Orfeo ToolBox is not a black box”.

Also, for completeness, the code:

otbcli_LargeScaleMeanShift -in QB_Toulouse_Ortho_PAN.tif -mode.vector.out QB_Toulouse_Ortho_PAN_v3.shp \
-spatialr 5 \
-ranger 15 \
-minsize 1

produces a result that is quite similar to the one using the individual processes:

I can understand the slight differences between QB_Toulouse_Ortho_PANseg_v3.png and QB_Toulouse_Ortho_PANseg_v2.png , but the result of otbcli_Segmentation (QB_Toulouse_Ortho_PANseg.png) is totally different (and a lot better!), while based on the same algorithm and with the same radii.

I’ve found that the actual difference is just the -filter.meanshift.minsize parameter in Segmentation, which is set to 100 by default. If -filter.meanshift.minsize is set to 1, I get a segmentation as busy as the
ones with the chain.
What is curious is that -filter.meanshift.minsize 0 yields the same result as -filter.meanshift.minsize 100