Very high resolution images

I need to edit/paint image file (a height map for 3D) that is roughly 20000x20000 pixels with 32bit depth.
So i tested if this is possible in Krita.

Creating a document - no problem. Empty canvas after saving as .kra takes around 7GB, and opened in Krita around 30GB of RAM. Both sizes are quite big but I can handle them.

However making a single stroke with a RGBa brush (with the size of around 3000px) have eaten all of my 128GB of RAM and 60GB of swap until I decided to terminate the process.
Interestingly enough the viewport, the canvas and the brush were quite responsive (relatively) during painting a stroke. The RAM usage problem is happening after releasing a brush.

My performance config (I have Krita swap path directory configured):


What is most interesting is that even thou the swap is set and configured Krita is not swapping everything. After exceeding the defined memory values the RAM is not freed and Krita swap folder remains empty.

So I guess my questions are:

  1. Is the RAM/swap thing a bug?
  2. Can Krita be configured to handle that kind of workloads?

I haven’t worked in this high resolution before, but I have worked in 3840 x 6274 and the rgba brushes are slow there above a certain size. You could test out the latest 5.0 krita pre-alpha nightly build: Krita Desktop | Krita

Do you really need to be working with such high resolutions? Are you texturing skin or something? Even still wouldn’t 10K x 10k pixels be enough?

1 Like

The question about RAM usage has been discussed before:

It’s very puzzling.

1 Like

I have only 24 Gb RAM, but…

I’ve just tried a 20 000x 20 000 pixels new document with 8 bits per channel = 1.2 Gb size
Painting with it added 200 Mb, and stayed stabilized around this number what ever the number of strokes, but I did heard the graphic card kicking in…
Adding a layer added around 900 Mb
Paint on that new layer stabilized the image at around 2.4 GB, did add many more strokes, it stay around 2.4 GB.
Then I added a new layer again and paint on it, image was around a stabilized 3.6 Gb, the fans of the graphic card started to sound like an helicopter taking off.

Then I did change the mode to floating 32 bits per channel…
No need to tell that I knew the answer => kill Krita, and it was hard to kill it as the terminal took time to open and it was even harder to write in it, so I restarted the computer the hard way.

Once restarted, I just created a new image 20000x20000 in 32 bits floating point, after 10 minutes, I restarted the computer the hard way

Yep that’s normal, you are using 4 channels → R-G-B-A at … a whooping 32 bit floating point on a hudge image and a huge brush.

At 32 bits floating point, we are speaking about something which can represent 4.3 billion/milliard values per channel

A 16 bits which can already represent 65536 values per channel might be a better choice for the size you are drawing but the most important is for the performance of your computer.

In the end, I found that Krita is fairly responsive with the poor performance of my computer, the brush was smooth to use on that 20 000x 20 000 pixels image

More about Bit Depth - RawPedia

2 Likes

Thanks! Will definitely do.

Yes.

Well, no. The image size is not some arbitrary size that I picked because I wanted to go big. The size is dictated by render dimensions and the model in Blender that determines the size of the texture. If I go below ~20k the displacement made with the image is going to be pixelated in the final rendered 3d scene.

That wont do unfortunately. Height/displacement maps used in 3D should be 32 bit. I belive Krita have the ability to export 32bit .EXR files which I wanted to test.

Yeah, that was pleasant surprise.

That’s weird

On my side, a 20000x20000px document size, 32bit/float per channel, takes 6.00GB
Doing some strokes eat memory, but not all memory after one stroke…

Only thing I notice is a latency when drawing…

Grum999

Doing a flood fill on layer, after opening document:

Looking memory usage for process, it’s more than indicated by Krita

But a precise memory measurement is difficult, because even if Krita release some memory area, system doesn’t always free released area (already some topics about these case and why, in forum)

But with 64GB RAM I’m currently able to work on a such document.

@silex on which os your workstation is running? Windows/MacOs/Linux?

Grum999

Same here.

I also did the experiment with a 3000 pixel brush, like the OP mentioned, that’s where my PC is starting to reach its limits but like @Grum999 the strokes are put on the canvas. Even if it needs some time, but I do not have to kill Krita.

Michelist

Edit: On the other hand 7 strokes of a 3000 pixel brush and the canvas is full. Can’t he just use the bucket? :thinking:

Can you test with 3000px RBGa brush, like the rock one for example?
I can paint with smaller brushes much easier, and indeed the lag is quite heavy.

This is my main concern.

Sorry I didn’t mention it before. Linux Debian testing 64bit. Krita version 4.4.3

I don’t paint 7 strokes in a row with the same brush?

=============

OK, I was able to get some results. I waited after making a paint stroke with 3500px RGBa brush (the rock one) to see what happens.
After releasing the brush - RAM on the left, CPU on the right:


After 8min the paint stroke is apparently done and RAM and most of the swap is freed (the leftover is 14GB of system swap):

So the delay is ~8min and RAM usage for the stroke alone is ~150GB.
I’m OK with this being the current software limit, but if there is a possibility of improving RGBa brush speed with big tip sizes or RAM usage that would be great. Meanwhile I’ll stick to regular brushes for that kind of jobs as they do not have that much delay and are not using that much RAM.

Overall I’m quite impressed by Krita’s ability to handle images that size. Before the test I was pretty sure it will crash long before I’ll be able to paint.

1 Like

If you haven’t already, you should also think about how many undo steps you need. The lower you set the limit, the less memory will be hogged by undos.

1 Like

I’m currently in the train and will be away from my workstation for a week… use of my laptop is not possible for such a test :sweat_smile:

But I’ll try to test after vacations.

Here some informations:

If you have some technical knowledge about C/C++ programming, the most important information is at the end of the post, concerning how the C free() function manage released memory…

Made my test on Krita 5 pre-alpha, but I’m not sure that about this point there’s so much differences.

Usually, brush size is limited by default to 1000px because greater values might be unusable in terms of performance. Not for all brush engines, but some brush engine are very complex.
Probably the RGBA brush engine is not the most simple :slight_smile:

Don’t remember if @Voronwe13 or @dkazakov implemented the brush engine and can gave you better answer, but I’m not sure if it’s possible to improve RGBA brushes speed/memory impact… :thinking:

Also note that I’m not sure developers have workstation like yours (or even like mine) and that could be difficult for them to test software in such conditions :sweat_smile:

Grum999

2 Likes

Hi, @silex!

Just wanted to let you know that work with such image in openGL mode you need about 9GiB of GPU (!!!) memory only to store the image itself. When doing the stroke Krita will also request additional up-to-9-gigs memory to pass data to the GPU. This additional memory will not be included into the limit you set in the settings. Therefore I would really recommend to set Krita’s memory limit to lower value and keep at least 40 gigs free.

However making a single stroke with a RGBa brush (with the size of around 3000px) have eaten all of my 128GB of RAM and 60GB of swap until I decided to terminate the process.

It might be that your GPU driver started to swap out the openGL texture data, which usually puts operating system on her knees.

1 Like

Hi, @Grum999 and @silex and @PixLab!

Could you tell how much GPU RAM you had on the system you tested this testcase? The point is, with such huge images, GPU’s RAM becomes bottle neck, not the CPU’s one.

For working with really large images, it might be interesting to check out vips and nip2: libvips, GitHub - libvips/nip2: A spreadsheet-like GUI for libvips.

Hi

On my workstation, I’ve a GeForce GTX 1060 3GB

Grum999

@Rebecca that is very good advice! Thanks!

Unfortunately I don’t. But maybe in some distant future.

I know that the problem about large images is kind of niche one, so I don’t expect it. I’ll be happy to test things from time to time and if there is any improvement that’s great. If not, I will find a workaround.

Hi @dkazakov! That is not a problem, I have Radeon VII with 16GB of VRAM.

That is very useful information! Thank you very much.

I had problems with AMD drivers for Linux before. I’m using official AMD drivers version 20.40 for Ubuntu 20.04. I need them for OpenCL GPU rendering. And I can’t install newer because they dont work with Blender (at least on my setup).

Just for curiosity:

Someone asked if it is necessary to work with such a high resolution (in this case: 20 000 x 20 000 pixels)

Advertising has requested A1 size illustrations.
Something like: 7016 × 9933 pixels (300 ppi). It’s not as big as the case above, but for me it’s already a counterproductive size :confused:

I have already been asked to illustrate a wine bottle label. The illustration should be in A1 size :grinning_face_with_smiling_eyes:

The illustration should look like an engraving (made with pen and ink). In this case, the ideal would be to work in vector.

2 Likes

Sounds like a cask-size Bottle! :wine_glass: Cheers!

Michelist

1 Like

That’s true :rofl:

Cheers!

I can also attest to this. I have made Illustrations with 25k resolution. Some were for big billboards (with a client who didn’t listen about keeping it 150 dpi instead of 300 dpi) and some were for wall mural prints. Here is a screenshot of such file. I have removed the name and zoomed in to not show entire image because it is still under NDA :frowning:

In advertising illustrations there are often such requirements, and more often the clients will be very rigid in compromising anything in the requirements they have stated.

However, Krita was able to handle such big dimensions, I have not tried the new RGBA brushes on such big canvas through.

1 Like