Hi,

So while we have an old topic about an anime quick tool that mentions lazy-brush, I felt like a new topic specific to LazyBrush made most sense.

I've been eagerly waiting for this tool, I'm so excited to finally see it in Krita!

Some general questions / feedback (relevant images below):

1. I might just be missing it but I don't see any shortcut for the LazyBrush. Is that planned?
2. Ditto to #1 on a shortcut for creating a "colorize mask"
3. Is there any way to have lazybrush color an object and still keep the background transparency? I thought it was a bug at first
4. (I know boudewijn doesn't like it when we compare Krita to other software packages but I'm more asking this from a useability standpoint and not having any other frame of reference! Is it a bug or intended capability?) I was looking at videos of the TVPaint implementation and noticed you could draw a line through your object and it was colored appropriately. You didn't have to be exact. Is this just a first pass at the implementation or does it work as intended?
5. The 3.0.1.90 beta build post talked about it being the first "slow" implementation but then talked about here on out things mainly being bug fixes. Just curious - are there plans to improve speed before official 3.0.1 release? This isn't a "bug fix" which is why I asked.. same with implementing the "auto update" capability (which I'm assumed is turned off due to performance)
6. Can anyone explain the general code flow for the lazybrush? I did a quick look at master (on github) this morning and was confused. My unfamiliarity with the Krita code base is probably not helping but was just curious what each class did/managed.
7. Likewise, why is the Boykov Kolmogorov max flow algorithm patched? What was changed?

#3 Image:

(the lines are on a transparent background...but when using lazybrush I get all red, inside and out)


(what I expected?)


#4 Image:

(line goes through the object...at least in TVPaint's version you could be less precise and draw through like this, maybe this is related to #3?)


(but the final result)




Lastly - thank you to the developers for this capability. Very happy to start using this

As noone seems to be answering this...
1. Probably? We haven't decided on anything here yet.
2. Did you notice that if you touch the layer with the colorize tool, it'll automatically make a mask? Is it then necessary to have a shortcut for it?
3. Yes, you can mark a single color in the palette as transparent. But you need to mark the background, because the algorithm requires it.
4. This is something dmitry wants to look into still. Speed is more important right now.
5. Well, we have a strict-ish update schedule where we have two weeks for feature work, and 4 weeks for bugfixing and all feature work is being done in branches. This is necessary because bugs do happen.
6. No idea. You are better off reading the commits related to it: https://phabricator.kde.org/search/quer ... ju90dp9/#R
7. To make it slightly speedier.

The algorithm right now only understands how to handle two areas at a time, which is what makes it so slow. Dmitry wants to look into using an algorithm that can handle multiple cuts at a time, but I couldn't tell you which where how what or why those papers are.

Thanks TheraHedwig for the response.

TheraHedwig wrote:1. Probably? We haven't decided on anything here yet.

Oh ok, was just curious. It's not that big of a deal to me (I can just click on the tool) but the other tools have shortcuts so I didn't know if it was an oversight.

TheraHedwig wrote:2. Did you notice that if you touch the layer with the colorize tool, it'll automatically make a mask? Is it then necessary to have a shortcut for it?

I did see that! I just thought it was important to have a shortcut for it, I think if we're going to have one then #1 probably makes the most sense.

TheraHedwig wrote:3. Yes, you can mark a single color in the palette as transparent. But you need to mark the background, because the algorithm requires it.

Ahh ok, that makes sense. I'll do that from now on, thank you

TheraHedwig wrote:4. This is something dmitry wants to look into still. Speed is more important right now.

Agree, speed is definitely the best thing to work on at the moment. But glad it's under consideration.

TheraHedwig wrote:5. Well, we have a strict-ish update schedule where we have two weeks for feature work, and 4 weeks for bugfixing and all feature work is being done in branches. This is necessary because bugs do happen.

Ah that's fine! Sorry, hope I didn't come off as bothersome. It just wasn't clear to me what the approach was going to be. Thanks for clearing it up.

TheraHedwig wrote:6. No idea. You are better off reading the commits related to it: https://phabricator.kde.org/search/quer ... ju90dp9/#R

Thanks! I have trouble getting around phabricator. I'll try spending some more time with the code.

TheraHedwig wrote:7. To make it slightly speedier.

Sorry, I did find this answer after I posted this, forgot to edit. If you optimize the algorithm, do you think you'll open a pull request back to boost (I think that's where the algorithm originated).

TheraHedwig wrote:The algorithm right now only understands how to handle two areas at a time, which is what makes it so slow. Dmitry wants to look into using an algorithm that can handle multiple cuts at a time, but I couldn't tell you which where how what or why those papers are.

Interesting! It's fun to get some insight into Krita's development and for the artist in me it's exciting to get an idea of what you have planned for Kirta.

Thanks again for all your responses, really appreciate it.