Skip to content

WIP: Change how the layer's paint device is passed to the filter dialogs

Deif Lou requested to merge deiflou/krita:deiflou/dont_use_original_paint_device_in_filters into master

Developing a filter of my own, I've noticed that in some cases the color space of the paint device passed to the filter dialog is different from that of the device passed to the processImpl function of the filter. In particular I've seen that this happens when trying to apply a filter to a filter or fill layer. It seems that as these two are KisSelectionBasedLayer they have two devices: one with the filtering or the filling result and other with the mask. So the KisSelectionBasedLayer::original() and KisSelectionBasedLayer::paintDevice() methods return two completely different devices:

KisPaintDeviceSP KisSelectionBasedLayer::original() const
{
    return m_d->paintDevice;
}
KisPaintDeviceSP KisSelectionBasedLayer::paintDevice() const
{
    return m_d->selection->pixelSelection();
}

The original method is used to obtain the device passed to the filter dialog and the paintDevice method is used to obtain the device passed to the processing function of the filter. So in the case of the fill/filter layer, if you go to apply a filter on it, in the gui you have access to a different paint device that in the processImpl function. My filter relies in applying one or other algorithm depending on the color space of the selected layer, so under this conditions I have a mismatch between the gui and the processing function. My suggestion with this MR is to use the paintDevice method to obtain the device passed to the gui, which will be the device of the mask. I think this is the correct device to pass since it is the one that is going to be modified by the filter.

For example, as it is now, if you want to apply a curves adjustement on a fill layer to modify the mask, you can't. The filter dialog will show that the image is rgba (which is the color space of the generated paint device, not of the mask) and modifying those rgba parameters will have no effect on the mask.

NOTE #1: I've noticed that the original method is used also in other places related to filters, but I don't know if they should be also modified (FiltersModel.cpp, lines 141 and 173; FiltersCategoryModel.cpp, line 229).

NOTE #2: With this modification the filters that show the color space could be made to show the alpha color space. As of now filters like curves will show the graya color space if the target device is alpha, because they use the compositionSourceColorSpace function internally. These filters would have to store if the color space was alpha or not, since in the processing function also a device with graya color space is passed, and there is no way of knowing if the layer is really alpha or graya (I need to make a distinction because I use different algorithms for alpha and graya in my filter).

Test Plan

  • Open an image
  • create a fill or filter layer
  • go to apply the curves adjustement filter on it

Formalities Checklist

  • I confirmed this builds.
  • I confirmed Krita ran and the relevant functions work.
  • I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!)
  • I made sure my commits build individually and have good descriptions as per KDE guidelines.
  • I made sure my code conforms to the standards set in the HACKING file.
  • I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.

Merge request reports