![]() Registered Member ![]()
|
Hi Everyone
I have been using Krita for few months and I love it. But I am working on a project that requires a large size image to be printed at 36inches . At 10800 x 10800 pixle 300 dpi my computer crashes. I tried 9000 x 9000 @ 300 dpi but everything is unbearably slow ( from using the brushes to saving the file). Can krita handle large files or is there a limite to the size I can use? I have krita 2.8 on ubuntu 14.04 64bit. Many Thanks to the Creators of Krita.. Great program. |
![]() KDE Developer ![]()
|
There are two parts to this: the first is memory usage. That's simple enough to calculate: krita uses width * height * channels * channel depth per layer, except when you have masks, then it uses at least 2 times that amount. DPI is irrelevant. So, for a 20 layer image, no groups, no masks, of 10800 x 10800 pixels, 8 bit RGB, expected memory consumption is about 9 GB. Add to that the consumption of video ram: if you enable opengl, the final, rendered image will have to be stored in video ram for display, if you have opengl disabled, we have a representation of the final image in normal ram. This also excludes undo data.
Next, there's the virtual memory usage. If you run out of real memory, Krita will start swapping to disk. So you can create images that bigger than your real memory. But if you zoom so all of the pixels are visible, and try to paint a big diagonal stripe over the image on, say, the second layer from the bottom, then Krita will have to access nearly all of the contents of all the layers to create the final rendered image. That means that everything has to be loaded from the swap into memory, from memory into the cache, and then swapped out again. There are certain parameters you can set in the config file to determine when swapping should kick in and how much memory Krita should leave for the rest of your OS and applications. This much is common to pretty much all open source raster-based graphics application. Of course, the next thing everyone tells us, is "Photoshop can do it! You must do what they do!" That's not easy. Photoshop is closed source, so we cannot check _what_ they are doing. It's also not something that's discussed in academic literature, so we have to figure it out ourselves. It looks like Photoshop actually works on a scaled-down image. So, if you work at 25% zoom, Photoshop will use a cached, scaled down image at 25% to actually work on. That's only 2700x2700 pixels. It'll first apply your action on that image, then in the background apply the same action on the other cache levels -- 50%, 75%, 100%. That means your action is applied 4 times... Of course, this breaks down when you're using retina displays, which is why people complain that the Surface Pro 3 isn't fast enough for Photoshop. It's got a 2160 x 1440, which means you're much likely to work at close-to-100% zoom level, which means the level-of-detail cache-level trick is less likely to kick in, the application has to do more work, and gets slower... Good news is that we've got a proof-of-concept for this kind of optimization: http://www.youtube.com/watch?v=1J9s7dNuSe4 Bad news is that it won't be finished for 2.9, and to get it finished, we'll need more funding. Which means that right now, you need to check the amount of RAM your system provides, and calculate how big you can make your images before you run into extreme slowness or worse. |
![]() Registered Member ![]()
|
Thank you Boudewijn for detailed ansawer.
I did thought memory was the issue so I added 6gb to the 2gb I have, did not work. But now that I know memory is the issue I will add more. I actually went out to buy a new computer with i5, thinking something is wrong with my computer. But it was the same on the new computer with windows on it, it had 4gb ram. Thank you very much for the help. |
![]() Registered Member ![]()
|
@boudewijn , Can we have the memory & file-size info shown in the status bar like we get the files size info in gimp.
that will in a way help to keep the resource usage in check. I mean it will help us keep the file usage below our systems resources and avoiding making krita non responsive by using more resource than we have . I don't know how much work it will include, i am just making a request. |
![]() Registered Member ![]()
|
Is it normal that krita uses all the RAM when it is running? Nothing opened on the computer but Krita.
I work on 5000pix size canvas. But I deleted all the layers and left one (white blank page), to see if the memory will go down. But it dosen't untill I close krita and it goes back to 2gb. The system monitor shows this when only Krita is running. Memory: 14.8 gib (95%) of 15.6 gib Swap: 3.0 gib (19%) of 15.9 gib CPU history: CPU1 12.% CPU2 8% CPU3 23.1% CPU4 11.5% I don't know much about computers, but I don't bleive there is anything wrong with my computer, I just got it new. Do I just have to add more ram? Thank you. |
![]() KDE Developer ![]()
|
That's normal -- the amount of memory Krita allocates can be fine-tuned with some settings. But Krita pools memory for re-use, which means that Krita's memory footprint won't shrink while it's running.
|
![]() Registered Member ![]()
|
Hi, here the same problem.
I have been using Photoshop for years for my job. I'm a digital painter and I need to work in 12000 x 12000 pixels for printing. I work just with 8 bit/Channel, not so much. I would like to work with Krita, I love it, but when I open a canvas (0f 12000) I can't paint without a terrible delay, the stroke goes behind the wacom. I am working with the most simple brush for testing, and there is no way, I can't. I have an I7, 24 GB RAM, Raedon RX470 (8 GB) SSD, etc... Krita 3.1.4 ![]() |
![]() KDE Developer ![]()
|
Can you test 3.2.1? Because we did do some things that are speed-ups for some(also, we fixed bugs
![]() Other than that, which brushes are you using? Do the brushes that start with "quick" also give lag? Because then it might be best if you customise a handful of brushes by for example going to f5 and turning down the precision and turning up the spacing. This will lead to brushes that aren't qualitatively as good on very small sizes, but they will be a lot faster on bigger sizes. Other things to check for is the usual suspects: Toggling openGL in the settings(if this makes a difference, then there's something weird with your graphics drivers), toggling instant preview, making sure Krita isn't swapping by giving it enough memory in the performance settings, etc. |
![]() Registered Member ![]()
|
Hi TheraHedwig.
I am using OpenGL, Instant preview, and Krita 3.2.1 (I have just installed) No way, I can't use a "Quick" because I need Opacity, I use a brush only with size, opacity and Auto for spacing. But when I try to paint with a 1000x1000 brush, all frozens. I know my job is very heavy for a painting program, and that it's not the case of the most users. I will wait untill the solution in future versions. Thanks ![]() |
![]() Registered Member ![]()
|
Auto spacing make it lags a lot at big sizes. This feature makes spacing smaller when brush is big (I'm not sure what good effect it does but it's clearly slow down brushes). I guess you use hard\soft round brush? These can work pretty fine with about 0.10-0.12 spacing (no auto). On my PC hard round is almost instant even on 1000px, without Instant preview.
Last edited by radian on Wed Aug 30, 2017 8:49 pm, edited 1 time in total.
|
![]() KDE Developer ![]()
|
If Rad's suggestion makes no difference
1. Double check you're not using the stablizer and 2. make a video please. |
![]() Registered Member ![]()
|
Thanks, I have applied all the improvements you had said and in appearence it surprisingly seems to go fast, but it renders the strokes later and spend an terrible amount of time.
I feel sad because I am bored of photoshop. I can't work so slow. I will periodically review for updates. Thanks a lot to you ![]() |
![]() KDE Developer ![]()
|
We asked you to make a video showing the problem: without that, we cannot help further.
|
![]() KDE Developer ![]()
|
To add onto what boud said: We wanted to try and figure out if it is a bug. If it is a bug, we could try and fix it. Now however, it will probably get resolved by coincidence if at all.
|
![]() Registered Member ![]()
|
Thanks for your kind interest.
I have done a little video about the problem. It's a 12.000 x 12.000 canvas with one layer, a "pixel" brush, just square, with 0.4 of spacing. https://vimeo.com/231856761 The lag is not a video problem is the program. I would like to work with Krita seriously. |
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot], Yahoo [Bot]