It’s not surprising that this much RAM is being used.
(And with this small a fraction of the available space being used, you should not expect lag due to that. Not unless the memory of all your other active programs, including your operating system, combined exceed 15 GB. Or somewhere between 50% and 100% of your physical RAM - I don’t know what rule of thumb people use for this percentage nowadays.)
If you create a new document using the “Custom Document” option and enter the resolution you used, then the small blob of text above the “Create” buttom which ends with “A single paint layer will thus take up 265.5 MiB of RAM.”
Each paint layer is its own raster image. At the resolution of 7016 by 9920, that makes it a nearly 70 megapixel raster image. Every pixel needs 4 bytes, minimum, to store color information. So it’s no surprise that the memory used is many megabytes. A little extra memory (less than a layer’s worth?) will necessarily be used because Krita has to allocate more memory to do any work with that color data.
How much space a paint layer uses in active RAM depends on its resolution and color depth. (Color depth is normally 8 bits per channel but can be extended to 16 or 32 bits.)
As far as I know, DPI should have no effect on memory use or performance. It just tells the program how to convert lengths in pixels to lengths in inches. The contents of a paint layer do not matter. A blank layer takes just as much space as a solid black layer or a really noisy layer.
The reason why the amount of memory required is so much larger than how much would be required by a JPEG of the same resolution is because JPEGs make use of serious lossy compression.
The compression algorithms used in PNGs and JPEGs can take advantage of patterns in an image, like blobs of similar colors or smooth gradients. (Thus for compressed images, the contents of the image do matter. A file with a good compression ratio will decompress to a relatively simple image. On the other hand, it will almost never be possible to encode an image of random noise with a good compression ratio without losing detail.)
But compression is mainly employed when saving, loading, or transferring a file. When the image is actually loaded by a browser, image editor, or image viewer, however, the same amount of RAM will need to be be avaialable to contain the raw pixel data. (A decompression algorithm just converts a dense encoding of an image into a usable, general format. Which in the case of images is like a bitmap.)
If you edit audio or video, you will see the exact same pattern of the amount of space required to store the original recording versus the size of the final exported file size. That’s why MP3 files are smaller than WAV files.
Compressing and decompressing data is usually a time-intensive task. And strong compression algorithms tend to require a lot of extra working memory in order to find a dense encoding of whatever that data is. So when you edit files in Krita or any other raster image editor, you will be working with an uncompressed version of that image.
It would be counterproductive for Krita to try to employ compression to save RAM while live editing is being done. Even a tiny change to the image would force the software to decompress and recompress stored information.
– Possible cause –
If you’re seeing periodic pauses, then your problem may be the autosave feature. Whether Krita developers employ compression for autosaves the same way they do normal saves, or not, it may still result in annoying interruptions. Even for flash storage, saving files that are many megabytes large takes a significant amount of time.
The autosave interval can be configured as low as one minute, which can be seriously irritating with high resolution files. The interval can be changed or autosave can be disabled in the “File Handling” section of the “General” configuration options.
– Other potential problems –
Consistent lag isn’t as easy to diagnosis. But the amount of memory used is still not likely to be a problem here. This list is not exhaustive.
Pointer input lag may be the problem rather than any application level errors.
Performance while drawing depends heavily on what brush settings are being used. Complex brushes can be slow at larger brush sizes. “Basic” and “pixel” brush presets should be fast at any size.
There is a frames-per-second limiting configuration setting under the “Performance” category. I haven’t experimented with it, but I assume accidentally setting it as low as a single digit would be rather noticeable.
– Note 1 –
Krita also supports vector layers. Vector image formats are an alternative to raster formats. Raster formats store which colors to draw at each and any individual pixel. Vector formats store shape information, particularly instructions on how to draw outlines and how to fill those shapes. Vector images can be rendered using any scaling value without noticeable blocky pixel artifacts. Their file size depends only on the complexity of the drawing instructions.
Editing vector formats is very different from “normal” drawing in practice. And modifying them also requires the computer to redraw (really, recompute pixel color values) any time you make an edit. The stored file size of vector formats does depend on the complexity of the drawing, rather than the nominal size of the image.
Krita supports mixing layer types. Vector layers and fill layers can require a lot less disk space, but they can be relatively slow to update and re-render in complex projects.
– Note 2 –
Krita DOES however use lossless compression when saving .kra files. That sometimes means your Krita project will may be saved on disk using significantly less space than the amount of RAM required to open the project.
(More aggressive “lossy” compression is not used, because people generally don’t want to lose any of their work.)
Not all raster data is suited for compression, so it would be normal to have your .kra project take up disk space at the same order of magnitude as the amount of RAM required to load and edit the project.
It is not unrealistic for projects with high resolutions to take up more than a gigabyte of disk space. You may want to use a separate high capacity drive for archival purposes. Or just use lower resolutions for some projects.
Regardless, Krita is capable of exporting normal JPEG images when you are ready to publish. The exported image will be flattened and lossily compressed at whatever quality level you choose. And this exported image will have a normal file size. (Just use “Export”. Not “Save As”.)
The exported file is stand-alone, so it can be uploaded anywhere and the original project file can safely be relocated to the archival drive.
– Note 3 –
Although I am a programmer, I am not a Krita developer and am not affiliated with the project at all. My personal experience with Krita measured in hours is also low. I can’t debug or troubleshoot most of the countless ways something could go wrong with software, operating systems, drivers, hardware, etc.
Hope that what I can explain is informative.