Hello all,
This is my first post here.
I'm very new at using Krita, but I am evaluating as a replacement for photoshop for our Matte Painting workflow.
The biggest points in favor of Krita so far are Linux availability and OCIO color management.
The points against are: re-learning a software and performance.

I have a couple of questions, and possibly will have more as I proceed with the testing. For convenience I will post them all in this thread.

Question 1: are there specific settings to optimize performance? Our matte painter who was test driving Krita found some brushes to be lagging behind. He's on a 64GB of RAM machine with an Nvidia Quadro P4000. He does not have a "swap" drive setup so it may have gone to his system drive which is a spindle. I'm going to test out with an SSD swap drive. His RAM is not getting fully used though.

Question 2: I can use OCIO for display easily, however I haven't found a way to specify color settings per layer?
Use Case: Loading a Log Plate as layer 1, an ACES plate as layer 2, and some sRGB element from the web as layer 3, how do I convert them all to the same linear working space? I'm currently loading some EXRs that are ACEScg and others that are Linear sRGB (sRGB that has been linearized), but I can't find the way to apply the OCIO color transform on it like I would do in Nuke.

Thanks, that's all for now.

erwanl wrote:Question 1: are there specific settings to optimize performance? Our matte painter who was test driving Krita found some brushes to be lagging behind. He's on a 64GB of RAM machine with an Nvidia Quadro P4000. He does not have a "swap" drive setup so it may have gone to his system drive which is a spindle. I'm going to test out with an SSD swap drive. His RAM is not getting fully used though.

In general: https://docs.krita.org/Performance_Settings . See also https://docs.krita.org/KritaFAQ#Krita_is_slow . It will always be possible to create a brush that feels slow, though we're always busy trying to improve performance. What type and size of image are you testing with?

erwanl wrote:Question 2: I can use OCIO for display easily, however I haven't found a way to specify color settings per layer?
Use Case: Loading a Log Plate as layer 1, an ACES plate as layer 2, and some sRGB element from the web as layer 3, how do I convert them all to the same linear working space? I'm currently loading some EXRs that are ACEScg and others that are Linear sRGB (sRGB that has been linearized), but I can't find the way to apply the OCIO color transform on it like I would do in Nuke.

Krita can have heterogenous images, i.e., images where layers have different color spaces and channel depths. But we currently handle the OCIO display settings as pure display settings, i.e. the OCIO color transform is done on the final projection, not per layer. If this is a requirement, we'd have to discuss this together and see how we can get this implemented.

boudewijn wrote:In general: https://docs.krita.org/Performance_Settings . See also https://docs.krita.org/KritaFAQ#Krita_is_slow . It will always be possible to create a brush that feels slow, though we're always busy trying to improve performance. What type and size of image are you testing with?

I'm testing 4K 16bit linear images (imported from EXR). I have recently switched from Fedora OS to CentOS and the performance seems to have improved a bit, but I'll need to get the Matte painter who was doing the heavy testing to give it a try on this machine, I am not sure what he was doing to make it slow down. I personally mostly experience slow downs trying to switch between 2 open files. (2 different 4K EXRs)

boudewijn wrote:Krita can have heterogenous images, i.e., images where layers have different color spaces and channel depths. But we currently handle the OCIO display settings as pure display settings, i.e. the OCIO color transform is done on the final projection, not per layer. If this is a requirement, we'd have to discuss this together and see how we can get this implemented.

It probably would be, as we need to make sure the different elements we assemble are all brought to the same working space, probably ACEScg in our case, or possibly Linear sRGB (we still have a few packages in the pipeline that do not support ACES, so these use Linear sRGB)

So it seems that the performance hit is only happening on fast broad strokes, but not if the stroke is limited in area.
I'm guessing it has to do with the internal pool? If I have a lot of RAM available, will making the pool bigger help with these broad strokes? From the help I seem to understand that making it too big may be counter productive for the smaller strokes?

I am jumping in a bit, but not sure how helpful I will be. I am assuming you have the "Instant Preview" checkbox on from the View main menu option. That creates different levels of detail of the canvas when painting. That has a good speed up when working with larger canvases.

The brushes you use will also affect performance pretty greatly. The spacing property especially can have a dramatic effect on the speed and responsiveness. There is also a "quick brush" engine for working on large canvases with large brushes. the brushes have a limited feature set, but they are probably the most responsive in your situation.

There is also some work being done now with making the performance better with multi-threading brush dabs, but that might be a little while before that is ready for production.

Thanks Scott.
I am not entirely sure about the "Instant Preview" mode, I'll read the docs about it.
I did get better performance going from High Quality sampling to Bicubic for the canvas, but that disables the instant preview mode.

How much is the GPU affecting performance? I noticed it's not a P4000 I was testing on but a K4000 which is older.

Right now the GPU controls the canvas zooming and canvas rotation. It doesn't affect the brush painting very much right now.

Your main optimizations are probably going to come from tweaking the brush settings in the brush editor. Mostly the spacing property

Just to piggy-back this with my own two-bits, optimal brush performance for me has been a balance of several considerations. Memory settings, auto-save being on or off, brush options such as spacing and so forth and the use of Instant Preview mode (Shift+L is the default I think). Instant Preview is a fun one as it does essentially a lower-rez version of your brush stroke and then process the true result after the fact. It does make things very quick when painting, but if your brush is complex and you're working on a high rez canvas while zoomed out, Krita may lock up a moment as it's playing catchup with some of your wild brushing.

If you're just at the blockout stage, you may want to try the Quick Brush engine out. It's a no-frills system without fancy features like opacity controls but it's greased lightning for performance.

Thank you for the answers.

We are currently staying with photoshop for the time being, but closely following Krita's development.

So far here are some of the points that our Matte painters have noticed and are making them not wanting to switch:
-Levels adjustments take a few seconds to render when moving slider, vs instantly in PS (same file)
-Levels adjustments do not seem to have per channel controls (for R,G,B separately).
-Colour Adjustments (curves tool) doesn't have an undo function to undo while editing the curve, forcing you to cancel the whole function or re-adjust manually.
-No Radial or Zoom blur?
-Bug when trying to transform a layer and the data extends too far off the canvas, with transform being canceled and error message: Image too big.
-Moving large (7k) reference photo in file very slow.

Thanks for letting us know the feature gaps. I imagine these are prioritized based on importance.

1-3. We haven't had many requests for levels and curves improvements, so we don't really have people working on that specifically right now. Those seem like nice improvements though and maybe we can take a look at it later.

4. For our filters...we rely heavily on the G'MIC library so there isn't a ton that is in the first part of the Filter menu. You can access the filters you are looking for via Filters > Start GMIC-Qt. G'MIC is a another open source project that just focuses on doing filters and image transformations. Radial and zoom blur are among the labyrinth of filters that exist in that.

5. Interesting bug. I will have to take a look at that.

6. The Move tool is designed more for pixel perfect moving stuff, so it doesn't work that well for larger images. People usually move with the transform tool in general. I just moved with a 6,000 x 4,000 image and it moves pretty instantly.

Sorry Krita didn't make the cut for now. We are working really hard to make it better every week.

Thank you Scott for the feedback.
It's hard to convince people with lots of experience in a specific software and established workflows that they need to re-learn a new software.
For the OCIO and Linux Support it makes a lot of sense Pipeline Wise, but we can't switch if the artists are not on board.
We'll keep a very close eye on the development of Krita.

I'm new to Krita, and a long time Photoshop user.

There are some things about Krita that I'm having a problem with, things I can do in Photoshop that I can't do in Krita.

1) Edit channels. I can't seem to delete channels, or paint on individual channels.

2) Alpha channels. Krita's mask functioning is very different from Photoshop. I can't edit the alpha channel directly, and can't add more that one.

I ran across several things that I couldn't do easily. I found myself saying "why won't it let me do that?" quite often.

One thing I do like about Krita better than Photoshop is the brushes. Krita is geared for painting, not photo editing, so the painting functions are better.

Thanks.