Problem with failing presets in Krita 5: My findings and how to replicate. 🖌

Develop Artists Feedback & Testing
1

I first encountered this issue while using the Krita 5 Beta, and continued to with recent Plus versions.

Last month I resumed work on my bundle project, and I made a new preset using an animated .gih brushtip. I made that from scanned textured dabs; the aim was to make a lightness texturing brush for painting ground textures. The filesize of that unoptimised brush tip was very large at 42MB. The preset worked as expected, but when I went to use it again in a following session I found I couldn’t activate it.

Since then I’ve replicated the problem many times, and done many tests to eliminate possibilities and narrow down what the issue could be. After the last round of tests on Sunday I seem to have pinpointed the issue to using GIMP format brushes (.gbr and .gih) with a file size exceeding 6MB.

Info for replicating the problem:

  • Using Krita 5 Beta or Plus:

  • Create a large brushtip and save as a .gbr or .gih (.png seems to be okay. I haven’t tested other formats).

  • Both single or animated tips should cause a failed* preset if the file size of the tip exceeds 6MB (tested down to 6.1MB).

  • Below the 6MB threshold should work (tested up to 5.9MB).

  • The problem is present for tips with or without lightness information.

  • Confirmed with pixel engine and colour smudge engine.

  • Creating a masked pixel engine preset using brush tips with a combined size exceeding 6MB will also fail (can be the same tip).

*The failed preset will work correctly as you make it, but once saved as a new preset you wont be able to switch to it. The icon is added to presets and will highlight when selected but the previously selected preset will remain active.

Note: If switching to it from the base preset you used, you would need to reinitialise that - otherwise it will retain the characteristics of the newly saved preset and appear as if it’s working.

The preset will show up in the resource folder. I tried importing some failed presets into a default installation, but got a message saying the files couldn’t be loaded as resources.

All my tests were done on Linux.

So that’s a summary of my findings so far. I’ll @ some devs and seasoned brush makers so you’re aware of it and in case anyone want to try replicating the problem. I’ve already reported my findings to @Tiar as I went.

I’m not familiar with making bug reports and haven’t done one for this (Tiar did ask me to though)!

@halla @dkazakov @Voronwe13 @RamonM @Deevad @Rakurri @wojtryb @fizzyflower

6 Likes
2

Good to know, thanks for sharing the information. :+1:

1 Like
3

Thanks for the info. My 2 cents. I try to use not too much bigger brush tips 300px max. it affects the performance. I prefer .png image vs .gbr because in windows 10 is not visible in thumbnail. And I don’t perceive any advantage. But maybe other user can explain this better.
For animated tips, I use around 300 px max.

1 Like
4

@Mythmaker Your description of the problem is detailed, structured and easy to understand. That’s about 95 % of a good formal bug report :slight_smile:

If you’ve never made a formal bug report before, the place does look like a scary forest full of weird trees but it’s not difficult to get used to and it soon becomes familiar to you.
Maybe you could go on an adventure and have a try at making a bug report?

If you get things wrong, you can add further comments to state corrections etc.

4 Likes
5

Most of my tips are .gbr because I usually create brushes using the +clipboard dialogue in Krita - that saves in .gbr format.

I don’t know what the technical difference is between the formats so I’d also be interested if anyone knows!

Thumbnails don’t show for .gbr in Linux Mint either - not sure if Kubuntu has that covered?

I find the size-performance issue a bit strange because my expectation is as you describe - that larger tips will be slower; but I often don’t notice that in testing. I just did a test using that massive 42MB tip, and it seemed to behave the same as the 1/4 size version. Maybe I’m not pushing it enough with the spacing or document size. :man_shrugging:

I worry a bit about pixelation or loss of clarity if I shrink things too much, but I definitely care about performance - my own rig struggles enough as it is!

I did start to look into it a few days ago, but haven’t attempted it yet. :yum:

6

No, no thumbnails also on Plasma/Kubuntu for .gbr.

I think the only advantage of .gbr was a possibility to save inside some spacing setting and default brush size. That’s probably why it was favored in the design long ago. The compatibility with Gimp brush being the icing on the cake (at a time where Gimp had a larger brush community). This saving/loading of settings in the .gbr is probably obsolete in modern Krita. I’m not sure.

if I had a word to say about what could be a better option, I would probably ask for .png as a default . For the advantage of having a preview thumbnail in file explorer and for the good ratio of lossless quality and compression ( because .gbr quickly weight a lot, they feel like .bmp).

1 Like
7

That sounds sensible to me - especially as .png doesn’t seem to have the file size problem.

8

I don’t know if this has been resolved. I am still using modified versions of my own .gih brushes from a few years ago and still, every time at the start of every session I have to select the relevant .gih brushtip - it is still not saved with a new preset. Beside that little issue, the preset with .gih tips works like a charm - no performance issues. So my solution for years already is simply to set up a preset with a tip that does save properly - but with the engine settings as intended for the imported .gih tip. Then just select the correct .gih tip, readjust the Lightness Map adjustments and work happily for the rest of the session.

Perhaps there is an obvious solution and I would be interested to learn it.