Krita may store oversized layers (lots of empty space around the actual drawing). For instance: create a 4K image, draw a small circle in the center, then draw in Erase mode in the corner of the layers: full 4k layer for a dot. This can be easily verified in the layer's hover preview (initially cropped to the circle, then a dot with large margins all around). There are other situations where Krita does not properly optimize the drawing space on-the-fly. This can lead to several GB of memory, notably when such a layer is duplicated (copy-n-edit, animations...). This are hard to track down for the end user (took me a while to figure out), who is lead to believe Krita is just a buggy memory hog ;) To reclaim the RAM (and reduce the on-disk document size), a work-around is to crop each layer individually, but with complex documents this takes forever, and this may need to be done several time over the life of the painting. A no-op "Layers > Transform all layers > Scale" with the exact same size does help, though it doesn't crop the empty spaces in all situations; moreover this is a manual step that requires prior understanding of this issue. I would suggest auto-cropping all layers _on save_. This would prevent the issue and avoid manually optimizing one's documents. What do you think? If that sounds reasonable I could work on a patch.
If you have two dots at opposite corners in a layer, the tiles in-between won't be created for that layer (though projection tiles might be created when calculating the complete image). The thumbnail isn't telling you which tiles are created, only the the bounds of the layer (which are around those dots.) There already is an option to trim all layers to the image size for this: image->trim to image size, so you don't need to crop layers manually. About autocropping on saving, we've had a lot of back and forth about that over the years.
I just cropped empty spaces on a bunch of my .kra files. "image->trim to image size" didn't help much. "Layers > Transform all layers > Scale" helped some. "Select opaque > crop" individually on each layer did the rest reliably. I got 2.5->1 size optimization on average (both RAM and .kra). i.e. I more than halved the RAM requirements, and the disk usage. So there IS something to fix. What do we do?
@beuc Can you please provide a file that shows the issue? Will be easier to talk. Also, if I understand @beuc correctly, the problem is that Krita counts pixels changed by using eraser on already transparent pixels as inside the bounds(), is that correct? (That's also why Select Opaque -> Crop worked fine; and that's why Layer -> crop to image size didn't work, because the transparent areas were already on the image). @boud if you're talking about autocropping the actual content of layers on saving, I'm really really strongly against it; fortunately I believe @beuc has something else on mind, as in, recounting bounds() to make sure all transparent areas has been cropped out.
Created attachment 124364 [details] 2 layers with different blank spaces
> Can you please provide a file that shows the issue? Attached. Both layers have extra space. Initially: 100MB RAM (says Krita title bar) Layers > Transform all layers > Scale" (no-op same-size): trims some layers but interestingly some not, no idea why; 70MB RAM Select opaque > crop individual: 40MB RAM > Also, if I understand @beuc correctly, the problem is that Krita counts > pixels changed by using eraser on already transparent pixels as inside > the bounds(), is that correct? I believe that's one of the several reasons why unoptimized blank space lie around. Fixing this particular occurrence does not fix the general issue IMHO, and more importantly it does not fix existing documents. > that's why Layer -> crop to image size didn't work, > because the transparent areas were already on the image). Do you mean "Image > Trim to Image Size"? AFAICS this only trims hidden layer pixels outside the image area (e.g. when finishing a stroke outside of image). No effect in this test case. > @boud if you're talking about autocropping the actual content of layers on > saving, I'm really really strongly against it Would you mind elaborating on why? The main reason I opened this bug rather than directly attempt a patch is because I suspected this might be an issue, though I have no precise idea on why (concurrency issue when saving in the background maybe?). > fortunately I believe @beuc has something else on mind, as in, recounting > bounds() to make sure all transparent areas has been cropped out. No, auto-cropping on save is exactly what I had in mind. (I'm not sure I understand what you're proposing though ;)) I liked the solution because I think it safely optimizes existing documents without having to teach users about it.
It would probably be better to write a system that automatically harvests completely empty tiles regularly. The way krita works is NOT that all pixels between two points take space. We do not use scanlines or a single area allocated to the boundingrect of a layer, we use a tile system where tiles are only created if there are pixels written to the tile. There are ways that empty tiles can be created and have memory located, and that's a waste of memory. This is really hard-core Krita coding right inside the scariest part of Krita: the tile manager. See https://bugs.kde.org/show_bug.cgi?id=412560 Trim to image size does not grow layers to the image size, allocating tiles, it only cuts off pixel data outside the image bounderies.
> > @boud if you're talking about autocropping the actual content of layers on > > saving, I'm really really strongly against it > > Would you mind elaborating on why? > The main reason I opened this bug rather than directly attempt a patch is > because I suspected this might be an issue, though I have no precise idea on > why (concurrency issue when saving in the background maybe?). > > No, auto-cropping on save is exactly what I had in mind. > (I'm not sure I understand what you're proposing though ;)) I'm strongly against cropping the content behind user's back. First of all, that kind of defeats the whole purpose of being able to paint outside of the canvas if every time you save - including autosave, I presume? - it crops out the content from outside the canvas. Gimp users asked for this feature for years, are we supposed to just light-handedly get rid of it? For example, one of the advantage of having content outside of the canvas is transforming the layer later without an artificial edge where the canvas boundary was. It's very useful both at the beginning of painting process when you can sketch and modify the sketch a lot to figure out composition, and later too, when you see that the composition needs some improvement or that because of some changes you need to bring back something that was outside of the canvas but now it's needed inside again. Another thing is our future animated Transform Mask. To get a nice zooming-in or out animation, it's better to paint a very big, much bigger than the canvas, background, and then zoom in using the Transform Mask. Cutting the content outside of the canvas won't allow for such trick. In both cases, just the fact that you can paint outside of the canvas doesn't mean a lot when saving the file destroys the data. What I would be supposed to do, avoid saving to make sure I don't lose it? That doesn't sound like a good idea at all. Removing empty tiles is of course very much fine with me, since they wouldn't contain any data that I may want/need later.
@Tymond Then that's not what I suggested - for me "auto-crop" preserves out-of-canvas data. Let's call this "trim" maybe. @boud The testcase's "crop" layer contains 99% of LZF-compressed empty 64*64*4*'\0' tiles. Indeed these could be easily stripped, even just on save (fast compare compressed tile with empty 292-byte compressed tile, if match don't write tile). The "nocrop" layer however contains >2000 tiles (covering ~100% canvas), though only 20 different ones. It's just a small rectangle, I'm not sure what's happening with this one.
* I meant to write: 2000 non-empty tiles. Most of them are a tile with 75% of 0x4d ("M"), then 25% 0x00. They don't appear in "Select Opaque", or anywhere AFAICS.
@beuc can you please explain how do you see that those tiles are not empty? Do you get those information from the .kra file itself or in a different way? (Sorry if the question is obvious, but afaik for example Transform Tool should find all not empty areas, and it only shows those rectangles (the bounding box is only around those rectangles), which means everything else must be empty).
Forensics-style: I inspect "Sans nom/layers/layer4" in the .kra archive, and lzf-uncompress the tiles. Most probably you guys have tools to inspect the tiles in-memory and can confirm. > which means everything else must be empty And yet, there is non-empty data :) Which probably explains why the no-op-scale technique trims the other layer but not this one.
Thanks for your comment! Automatically switching the status of this bug to REPORTED so that the KDE team knows that the bug is ready to get confirmed. In the future you may also do this yourself when providing needed information.
I inspected the files some more, but I can't figure out why there are unexpected non-blank tiles. Is this RGBA?
I guess we need to discuss this with Dmitry when he's back...
Git commit 0afb45d741a411c8076272e1c6c97e941122e9b3 by Boudewijn Rempt. Committed on 22/02/2020 at 12:16. Pushed by rempt into branch 'rempt/trim_on_saving'. Add an option to save the image trimmed This removes all empty tiles from the borders of every paint device and all pixels outside the image borders. It is off by default, of course. M +1 -0 libs/image/CMakeLists.txt M +17 -0 libs/image/kis_image.cc M +9 -0 libs/image/kis_image.h A +74 -0 libs/image/processing/KisTrimProcessingVisitor.cpp [License: GPL (v2+)] A +51 -0 libs/image/processing/KisTrimProcessingVisitor.h [License: GPL (v2+)] M +5 -6 libs/ui/KisDocument.cpp M +1 -1 libs/ui/forms/wdggeneralsettings.ui M +1 -1 libs/ui/kis_config.cc M +1 -1 libs/ui/kis_layer_manager.cc https://invent.kde.org/kde/krita/commit/0afb45d741a411c8076272e1c6c97e941122e9b3
Git commit 3af515076f0bdffdf0e3f3326a28a63fc74e23f2 by Boudewijn Rempt. Committed on 02/04/2020 at 13:09. Pushed by rempt into branch 'krita/4.3'. Add an option to save the image trimmed This removes all empty tiles from the borders of every paint device and all pixels outside the image borders. It is off by default, of course. (cherry picked from commit 0afb45d741a411c8076272e1c6c97e941122e9b3) M +1 -0 libs/image/CMakeLists.txt M +17 -0 libs/image/kis_image.cc M +9 -0 libs/image/kis_image.h A +74 -0 libs/image/processing/KisTrimProcessingVisitor.cpp [License: GPL (v2+)] A +51 -0 libs/image/processing/KisTrimProcessingVisitor.h [License: GPL (v2+)] M +5 -6 libs/ui/KisDocument.cpp M +1 -1 libs/ui/forms/wdggeneralsettings.ui M +1 -1 libs/ui/kis_config.cc M +1 -1 libs/ui/kis_layer_manager.cc https://invent.kde.org/kde/krita/commit/3af515076f0bdffdf0e3f3326a28a63fc74e23f2
Okay, the original point of the bug report has now been implemented. The automatic trimming of images during editing which Dmitry had implemented had to be reverted because it broke undo.
See commit 63af6bb0961dcd07b89e8150c6e2644dafb0e46c Author: Dmitry Kazakov <dimula73@gmail.com> Date: Thu Apr 16 21:21:22 2020 +0300 Disable automatical purging of default pixels It breaks undo on layer's paint devices CCBUG:419372