Skip to content

Add option to change File Layer scaling filter

File Layers have an option in the Layer Properties to scale to image size or PPI, but they are hardcoded to use Bicubic scaling. This adds the option to change the scaling filter, for example to use Nearest Neighbor for pixel art.

Inspired by this thread:

Currently the UI way works, but the Python way does not: New function FileLayer.scaleFilter() works, but Document.createFileLayer() and FileLayer.setProperties() won't take their new arguments, and I'm not sure why.

"TypeError: setProperties(self, str, str): too many arguments" was caused by build files not being updated. I fixed it by deleting '[build folder]/plugins/extensions/pykrita/sip/_tmp' and rebuilding.

Test Plan

  1. Create a document and add a File Layer with a different size or PPI.
  2. Open the Layer Properties. With the default No Scaling, the Scaling Filter combobox should be disabled. The default Scaling Filter should be Bicubic.
  3. Set the scaling method to Scale to Image Size or Adapt to Image Resolution and press OK.
  4. Change the Scaling Filter and press OK. The filter should change.
  5. Undo and redo the Change File Layer command. The filter should change.
  6. Saving and reopening the document should preserve the layer's filter setting.
  7. To test the Python API changes, open the Scripter, paste this script, set a valid image path, and run it:
from krita import *

path = ""
doc = Application.activeDocument()
filelayer1 = doc.createFileLayer("filelayer", path, "None")
print(filelayer1.scalingFilter()) # Should print "Bicubic"
filelayer2 = doc.createFileLayer("filelayer2", path, "ToImageSize", "NearestNeighbor")
root = doc.rootNode();
root.addChildNode(filelayer1, None)
root.addChildNode(filelayer2, None)
filelayer1.setProperties(path, "ToImageSize", "NearestNeighbor")

In theory you should end up with two identical File Layers, but it doesn't seem to work.

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.

Reminder: the reviewer is responsible for merging the patch, this is to ensure at the least two people can build the patch. In case a patch breaks the build, both the author and the reviewer should be contacted to fix the build. If this is not possible, the commits shall be reverted, and a notification with the reasoning and any relevant logs shall be sent to the mailing list,

Edited by Freya Lupen

Merge request reports