This behavior seems incorrect as the final image will be converted to grayscale when it is sent to the host.
You can reproduce this issue in GIMP by running the G’MIC-QT Bokeh filter on a grayscale image.
The preview shows a color image, but when the apply or Ok buttons are pressed the final image is written as grayscale (matching the host image mode).
While this is a minor issue that does not really impact the usability of G’MIC-QT, I think that It would make more sense for users and developers if the G’MIC-Qt preview respected the host image mode.
I don’t totally agree with that. For the following reasons :
- The G’MIC-Qt plug-in previews the filter output as it get it from the G’MIC core, and in this case, the filter ‘Bokeh’ actually outputs a color image, whether the input image is in greyscale or in color. So the preview of the plug-in is correct.
- So, maybe the Bokeh filter should output an image that has the same number of channels as the input. But this is highly debatable. Clearly, it cannot be a general rule (see below).
- On the contrary, we could expect that the host software running the plug-in adapts the image colormode to the type of the filter output : if a filter outputs a color image, then it might be desirable that the host software switches the image mode to “color”. After all, if you have a filter that just adds an alpha channel in a RGB input (so output is RGBA), it’s almost never an issue. Nobody would say “it should output RGB images only, because the input is RGB”. That adapting behavior is maybe something to set in the ‘host_xxxx.cpp’ implementations of the plug-in, when possible.
- Another example : If, in the future, we implement a filter that performs auto-colorization of B&W images, e.g. with some CNN-based methods, the user won’t be happy if the (colorized) filter output is converted back to greyscale when passed to host software
That makes sense, thanks for the detailed explanation.
