Bug 413534 - Usability issues in Krita's Colorize Mask
Summary: Usability issues in Krita's Colorize Mask
Status: REPORTED
Alias: None
Product: krita
Classification: Applications
Component: Usability (show other bugs)
Version: 4.2.7.1
Platform: Other Linux
: NOR wishlist
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-10-28 02:45 UTC by Tyson Tan
Modified: 2019-10-28 13:08 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
GIMP 2.10 Smart Colorization (92.36 KB, image/gif)
2019-10-28 02:48 UTC, Tyson Tan
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tyson Tan 2019-10-28 02:45:05 UTC
This a report I prepared on behalf of the color manga artists in CJK region. There are many issues in Krita's Colorize Mask's current UI that harm its usability in actual production:

1) The awkward toolbox icon placement of Colorize Mask Editing Tool
Suggestion: Put it side-by-side with the Freehand Brush Tool. Makes up for easier switching.

2) Annoying switching between Freehand Brush Tool and Colorize Mask Editing Tool.
Suggestion: Combine them as one Freehand Brush Tool, but make Tool Options shows options for Colorize Mask Editing Tool when a Colorize Mask is the active layer.

3) Limit to Layer Bounds is disabled by default.
Suggestion: Enable it by default. One less thing to click when we try to speed things up. And that leads to --

4) Limit to layer bounds is useless unless the layer is cropped.
Suggestion: Teach people in our documentation about how to crop a layer. And that leads to --

5) Transparency must be manually assigned to a color.
Suggestion: Assign all unmarked area as transparency. This will greatly improve learning curve and usability, eliminating confusions like "why is the whole layer being filled while I only gave color to one properly closed area?" or "how the do I do transparent"

6) Update must be done manually
Suggestion: Automatically update the layer after each stroke. This will enable the user to teach themselves to use this tool. And that leads too --

7) It's too slow.
Suggestion: Some optimization must be implemented before it can become really useful in production use. We can calculate the edges of each color and remember them in subsequent color changes. Set some rules like "a line is crossed" or "a new color is added to a populated area" to trigger the recalculation. This will effectively make it possible to do quick color preview, which is arguably this tool's primary usage.

Basically, Issue (1) ~ (6) can be summarized as "too many clicks before anything happens". While all of them can be summarized as "too slow to use". 

Personally, before the community's complain to me, I never found any use of coloring automation until I realize a general color manga artists need to produce 15 ~ 20 colored pages per month, each page has 5 ~7 panels, each panel has a bunch of stuff. Most of them cannot afford a assistant, so any speed up is valued. The slowdowns I mentioned add up and prevent them to adopt Krita for its lack of efficiency.
Comment 1 Tyson Tan 2019-10-28 02:48:02 UTC
Created attachment 123531 [details]
GIMP 2.10 Smart Colorization

The community also reports that GIMP 2.10's Smart Colorization is exactly what they are looking for: https://girinstud.io/news/2019/02/smart-colorization-in-gimp/

Maybe we can learn something from them. The point is really: "one stroke and it's done instantly".
Comment 2 Tyson Tan 2019-10-28 06:54:29 UTC
One forgotten suggestion:

8) For a Colorize Mask, add a "Convert and Split" option to Layer docker's context menu. This option converts the result of the Colorize Mask into a paint layer, and split each color into individual layers with proper inherited-alpha. This will greatly speed up the shading process that follows.
Comment 3 wolthera 2019-10-28 10:21:21 UTC
Setting this to wishlist. Looking at your points, I cannot personally see any value in any of them, it rather seems to me people are just angry the tool isn't a different tool instead of trying to learn it.

1. The toolbox organizes by tool type. Colorize mask fills.
2. You do not need to swtiching between the colorize mask and the freehand brush tool ever, the reason we allow switching between tools is because we want to allow the use of the geometric tools.
3. While this speeds up the colorize mask, it also increases the chance people think the mask is bugged.
4. This is a problem of the artist not having any idea what they're doing. Krita by default crops the layer already, the problem is that the artist in question made a stroke that isn't part of the image. They should clean up their work first.
5. This is literally not possible the way the algorithm works.
6. Update must be done manually because the mask is slow.
7. The colorize mask is already as optimized as possible. Optimizing is not a magic trick you can apply, it takes actual thought and effort. If you know someone who knows how to optimize a watershed algorithm, they are welcome to try and optimize Krita's.
8. is literally the only one that makes vague sense, and even then I am skeptical whether it is wise within the programs logic.

If people want the gimp implementation within the next year, they should get someone to program it.
Comment 4 Dmitry Kazakov 2019-10-28 10:48:30 UTC
> 1) The awkward toolbox icon placement...
If we implement 2), then we can remove the button as well 

> 2) Annoying switching between Freehand Brush Tool and Colorize Mask Editing Tool. Suggestion: Combine them as one Freehand Brush Tool

It is technically possible to implement. The only reason for a separate tool was  custom tool options widget. Though merging the tools will demand quite a bit of work, because the code will be quite complicated. 

> 3) Limit to Layer Bounds is disabled by default.

That is disputable. Wolthera's concern should be somehow resolved.

> 4) Limit to layer bounds is useless unless the layer is cropped.

I have no opinion on this.

> 5) Transparency must be manually assigned to a color.

What I can do is to create a fake transparency stroke around the image. It will make background be transparent. *But* it does not guarantee that *unmarked closed* areas will be transparent. They will be either transparent or of nearest neighbour's color. Is such behavior acceptable? 

> 6) Update must be done manually

Wolthera is right, that is intentional because of slowness.

> 7) It's too slow.

Well, I have some ideas how to optimize it, but all of them need quite a lot of work.

> 8) For a Colorize Mask, add a "Convert and Split" option

It was originally planned, but I had no time to implement that.
Comment 5 Tyson Tan 2019-10-28 13:08:40 UTC
Thanks for the replies. While admittedly the current implementation of our Colorize Mask is perfectly functional and not bugged, its UI design is difficult to understand and requires too much back and forth. Maybe it's just me but I never managed to understand its usage even after reading the documentation many times.

(1) and (2) The switching back and forth between Freehand Brush and Colorize Mask Editing Tool is required by the need to toggle the settings of Colorize Mask in Tool Options docker. If we have only one Brush Tool that displays Tool Options by Layer type, there is no such need and a new user would have much easier time understanding the tool.

(3) (4) (6) are simply the product of the tool being too slow. That option wouldn't be there otherwise. The waiting time is overbearing for a A4 300ppi image on a Core i7-8700. We have every reason to teach users that this option is their only way to a comfortable Colorize Mask. I knew Krita layers don't take up full image size unless what, but human is not robot, we can't ensure zero mistake. Tools for human-use benefits from a design that takes human error into account. In this case, cropping is the easiest way to clean up the image, and it requires the least explanation. Not to mention that Krita tend to produce unpredictable glitch pixels all the time doing certain color calculations -- like Transformation, perhaps? It's not always the artist's fault that the layer slowly creeps over of its initial boundary.

(5) is where it gets so anti-intuition and the documentation lost me. I had already suspected an algorithm limitation before this so that's fine. If it's not amendable, we can improve our documentation so that the part where we make a particular color transparent has a dedicated figure or animation.

What I reported here is the collective opinion from professional color manga artists who depend on this tool to do their job, given that, I'd consider their words to have a certain degree of truth, not to be written off completely so lightly. Personally I too agree with them after trying the tool out.

I do understand the limitation of algorithm and your time. This is not a request but to communicate and suggestion of possible improvement. Sorry for posting reports that really is a wishlist but I was unable to find uninterrupted time for IRC discussion. If there is anything particular in my wording that is unpleasant, please let me know and I will improve that as well.

Thank you for your time! :)