I have been trying to test out the limits of how far I could push my android tablet with 12 gb ram while using Krita, and I had a painting file with give or take 100 layers (which only 1/4ths of these layers were visible at any given time) and Krita handled all fantastically!
Then I decided to play around with different softwares such as CSP, so I converted this file to PSD and added somewhere around another 105 layers (only 10 of them being filter correction layers so nothing fancy like vectors etc.) And I imported this updated version to Krita as PSD.
First of all I heard how terrible psd was for sharing but it takes an experience to truly understand. It took ages to import and to my suprise it was around 7.4 gibs of Ram usage with this. I saved this psd document as kra document within Krita and it opened much much faster but still used 7.4 gibs of Ram.
So, I exported folders with masses of layers into only 5 more transparent background layers and then added only these 5 more layers on top of my original Kra file (without all those 100 other layers) and it now takes around 4.3 gibs of Ram.
(I must note that 7.4-ish gbs of ram CLIP file was using at most somewhere around 4 to 5 gbs of ram within CSP which I understand from smoothness and a relatively vague external app which shows percentage used)
My questions are:
A- Is psd supposed to utilize more ram within Krita or is it that these conversion processes that bulks up the file? Or maybe psd to clip to psd to kra conversion was just meaningless, idk.
B- For future reference, how would you advise to share files in between softwares to not have this sort of a mess
C- I wonder if its how Krita handles layers (especially the hidden ones) that bumps up the ram usage?
Sorry for the loooong post but I just wanted to learn if there’s a better way to handle all these and if Krita is utilizing ram too much in certain cases such as this. Of course I dont need 200 layers at once, not at all, but as I said it was a test for both my device and for my use case of Krita on Android.
EDIT: Edited parts of this question for clarity in certain areas
If the apps allow it, I would try ORA or TIFF as interchange format. Unfortunately, ORA is not so widely supported, but TIFF is an old and robust format, it is also widely used in the printing industry because of its interchangeability and other advantages, BUT TIFF files are HUGE. In my eyes, it is a far better suited format than PSD, but that is my opinion.
But as always, usually it is best if you can do a job in one app, and then you should use that app’s format because it supports all the features the app offers. This is true for Krita, CSP, PS and others.
But sometimes you have to decide on a format that all the applications you use have in common.
I had heard about tiff but never tried it, perhaps I should see if that changes memory usage (or if its irrelevant to the format and processes but just how Krita utilizes the layers.
I agree with using native file formats, but I am definitely taking a look at tiff too, just in case I might need it in the future
So as far as Krita is concerned it will not unload a layer if it is not visible. So basically 100 invisible layers will take the same amount of memory like 100 visible layers. What changes is the memory used for projections but that is not as much in comparison. You can not simply unload a layer just because it’s not visible anymore, some operations still apply to invisible layers, like when the canvas gets resized or something, it would also make the program fell sluggish when a layer has to be loaded into memory and back every time you toggle the visibility. It already is an issue when you have lots of filters because these actually have to recalculate every time.
PSD files are not really compatible with KRA files, they support different features and there is always an overhead. Krita wont operate on the PSD directly, when you work on it it’s a KRA file as far as Krita cares but for saving and loading the file gets converted back and forth every time.
You can actually easily calculate how much layers a project can have at maximum, when you create a new file, while still in the file creation dialog, at the bottom there is a text telling you how much memory a single layer will take. Now you can take your device memory, subtract what other processes will need, and then divide the remainder by the number Krita shows in that dialog for a layer, then you get the number of layers you can have before you run out of memory. It’s not exact because Krita also needs some memory for projections and stuff but a good approximation. Adding layers randomly isn’t the best test because Krita is optimized in a way that when they don’t have any content or just a single color, they will use very little memory.
Thank you for this explanation! This makes a lot of sense, just to note these are not empty 200 layers but I just kept all the dump layers and built on top (like sketches to thumbnails to color comps and other tests), so it’s 200 full layers and only a few filter layers (which might be bumping up the ram usage since invisible layers are actually under that filter layer too!)
So, from this I am guessing either .clip format or how csp filters, or how layers in general work, its taking less ram and its not the conversion of file formats that’s causing it? It’s around 500 mbs less ram on the same file apparently
Edit: Used a better program to see how much ram difference there was
Thanks for the warning about the size and suggestion of tiff format!
I tried to test how much bigger the file size would be for future reference but my device can’t handle both this 7.5gb ram file and trying to export a tif file apparently I’ll keep this format in mind but I think trying to stay in the same software and related file format is the better thing to do for this time.
Things I have seen people do is just export every layer to PNG made groups folders, and filters grayscale PNGs and then reassemble the whole thing in PS. I vaguely remember that someone posted a python script for this on the forum once.
I’ll keep this format in mind but I think trying to stay in the same software and related file format is the better thing to do for this time.