Mosaic do not work anymore with rgb mode

Description

Mosaic does not work anymore with rgb-lab color space

Steps to reproduce

Select rgb mode for color/spectral harmonization.

TODO:

• fix bug
• add test

Configuration information

any OTB build >= 7.0.0

added bug label

changed the description

its strange, because this bug is already covered by this test https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/blob/develop/Modules/Applications/AppImageUtils/test/CMakeLists.txt#L475

mentioned in commit 77299c78

I made a quick fix. I simply have replaced the otb::FunctorFilter with itk::UnaryFunctorImageFilter. It seems like the otb::FunctorFilter is not registered in the pipeline, or something like that. Can someone who knows well otb::FunctorFilter take a look? I really would keep otb::FunctorFilter but I fail to solve this another way that replacing it.

What do you mean by does not work ? Does it crash ? Or does it produce bad results ?

I get a itk exception telling that the requested region is outside the largest possible region. After debugging I found that the filters were unitialized, even if they were pushed in a std::vector that is member of the application. Strangely the itk filter behaves differently... I am a bit lost

I must say that I can not see what's wrong in the application code. Are you sure that the filter are really uninitialized ? Sometimes gdb can be a little mis-leading if you have optimization flags during compilation ...

@jmichel This commit solves the problem. I do not use gdb, there is no segfault, everything is handled with clean exception. But I am still trying to understand

@jmichel I just found that the otb::FunctorFilter does not like when its requested region is [0,0].

In otb::StreamingMosaicFilterBase filters, when an output requested region is entirely outside the largest possible region of a particular input, the requested region of this one is set to [0,0].

That's why we end here when the input is a otb::FunctorFilter.

The itk::UnaryFunctorFilter tolerates a requested region of [0,0], but not the otb::FunctorFilter.

Maybe we can change this behavior? Processing a null region might have sense... like in Mosaic!

mentioned in commit 7af7b73f

mentioned in merge request !649 (merged)

Are you sure that your are not undoing something like #1963 (closed) ?

hmm, from my understanding (which could not be exact) #1963 (closed) enables the StreamingWarpImageFilter to behaves correctly when a requested region is empty. I do not think that this will have an impact. Let's consider the following piece of pipeline (illustrated with this fine ascii art) bellow:

F1, F2, F3 and F4 are instances of FunctorImageFilter, image1 and image2 are instances of readers, and output is a writer instance for the output image. Mosaic is a mosaic filter.

image1 --> F1 --> warp_filter --> F4 --> |        |
                                         | Mosaic | --> F3 -->output
image2 --> F2 -------------------------> |        |

Now suppose the writer of output is generating a chunk of image that is completely outside the image1 largest possible region. 0. output propagates the region to F3, then F3 to Mosaic

1. Mosaic request an empty region to F4
2. Before fix: F4 throw an exception. After fix: F4 propagates upstream an empty region
3. Thank to #1963 (closed), warp_filter is able to manage correctly the request
4. All requested regions have reached the readers, which produce the regions
5. Mosaic reads what it needs (it won't read any of the output of warp_filter, even if it exists)
6. etc.

closed via merge request !649 (merged)

mentioned in commit 12e13bea

closed via commit 8344d59f

mentioned in commit 8344d59f