Minimal file siz

I noticed that normally even without much color or any real artwork on the canvas, the file size that is indicated at the bottom is often almost above 500 MB. Is this a normal behaviour. Please see the screensho

t attached.
Today, I was making a caricature with few layers. My machine started struggling. Paper size A3 and 350 dpi. The size was around 1.7 Gb. The with is still not half way. Is this normal? I am running a powerful machine Dell XPS with 16 gb ram. I was wondering how the professional artists are managing the lag. Is this the same for everyone?

I’ve just made an A3, 350 dpi (4960 x 3508) RBGB/A 8-bit integer image with four paint layers and I filled each paint layer with random coloured plasma.
The RAM meter said it was 386MB.
It Saves to a 144MB .kra file and reopens to give 362MB RAM usage.

What happens if you Save your caricature, Quit and then open it again?

Same here like @AhabGreybeard OK. alomst but.
You are using Windows or Linux?

Windows OS … if you see the screenshot there are a few strokes that’s it and you will see the file size at the bottom.

Just I tried again, but your pixel size shows that you created a A3 with 600 dpi. This is exactly the pixel size. In that case I have te same big numbers, almost 400 Mib
Cheers
Alex

Here’s a simple explanation of image sizes in memory:

Thank you @alexsabo and @boud - So what is the ideal size to work with. I know it depends on what I need to do with the final product. I am asking this because I noticed that it was almost like crashing (but didn’t) even with the specs I have on my machine.Probably I am doing something wrong as I am not even 20% done with my work.
While I am seeing so many artists out there complete a scene with character and environment without any struggle.

@sany are no bad or good or ideal size. Always depends on what you wanna do, or what you asking for to do. If I have to do a illustration with A3 size, for me it is just fine the 300 dpi. I did not see any problems with my final books.
Cheers
Alex

1 Like

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.

^ CC0

1 Like

Hello and welcome to the forum :slight_smile:

Actually, no. Krita uses a 512 x 512 tiling arrangement over a layer and a blank tile takes only a small amount of RAM. This can be observed by doing simple experiments with multiple layers and adding increasing amounts of painted content to each layer. The difference can be quite significant for large images.
Also, if you want a solid black layer then you can use a Fill Layer which has very small RAM requirements.

Your post was informative and I suggest that you explore krita more because it has lots of cool stuff in it :slight_smile:

@182045520183 that was very detailed and I appreciate your patience in explaining. After reading your above note, I guess the lag I experienced could be to do with the backup or autosave it creates. I noticed every time I started editing it opens the same file as a new tab alongside the original. @boud may know better why this behavior is like this. Even if it wants to create another copy, can it not simply close the original file as both files are sitting there while I am working on the new copy. I am not sure why the other copy has to stay open and also I do not know how memory is affected.
I will try to maybe adjust the autosave timing!? In photoshop and other programs when we open an already created .psd file we just continue with that file, but here it just creates a copy along side.