[mockup] Sketch to blue (for inking)

Hey, here is a simple mockup for a feature I’m discussed with @dkazakov , @tiar and @wolthera on IRC a month ago. @dkazakov mailed me in PM to get more info about it. I thought then opening a thread here would be better to share with other users and also collect all information and my showcase my mockup for a proposal. Comments, enhancements of the mockups, ideas are welcome!

1) Context: after a simple sketch:

User scribble a sketch on a paint layer (or on many paint-layers for character, backgrounds, props, etc… all within a group). I imagine the sketch to be in 90% of the time a drawing/painting of dark values over a background in bright value (aka: grays/blacks on white/bright background):

2) The problem:

To start cleaning the sketch and ink better lines on a new paint-layer on the top of the artwork, it’s convenient to turn our sketch into a bright color. This way, the sketch is more “in background” and it’s easier for the artist to focus on the new set of darker lines while still being guided by the sketch.

3) Workarounds:

So far; Krita proposes this set of solutions as a workarounds, with PROS and CONS and all of them feeling more or less DIY. If you are familiar with Krita, skip reading this part. (Note: I wrote this list to prevent the “have you tried xxxxxxx” type of endless debates):

  1. Sketch with the right color from start: the more obvious maybe and it immitate the traditional comic artist using a blue pen since decades.
    • PROS: Good perfomance, easy to setup (just pick a color).
    • CONS: Not flexible, require anticipation and sketch always using a too bright color (hard to maintain a digital sketchbook like that and not convenient to share sketches with audience. A mid-grey or black color is easier and more pleasant (at least for me) to produce sketches.)
  2. Color channel, more precisely: turning off a color channel of RGB in propriety + reducing layer opacity
    • PROS: Good perfomance, easy to setup, easy to turn off/on, was my fav and I made tutorial on Youtube about it.
    • CONS: Non customisable color: limited to a blue/violet or too cyan/green, needs workaround in case of groups because the compositing over pure alpha can invert the result (pure yellow), reducing/rising opacity manually for more click to turn off/on.
  3. Fill Color layer, drawing on it.
    • PROS: Customisable color.
    • CONS: Performances of drawing is not butter smooth, transform tools and other filters are limited on non-paint layer, it requires to be setup before sketching and it doesn’t work for groups.
  4. Use Filter Layer(HSV color or Curves) or Filter effect(color)
    • PROS: Very flexible and customisable.
    • CONS: Performances are too laggy to paint/draw on setup like that.
  5. Screen paint-layer(my fav): Adding a paint layer between the sketch and inking with the blending mode “screen” filled with bright blue.
    • PROS: Good performances, custom color and perfect effect, ability to turn visibility off/on via the layer stack, the layer can be itself a ColorFill layer to not impact the weight of the *.kra file.
    • CONS: Not easy to discover, require DIY/thinking/memory to reproduce the rigg and many click, adds a new layer in the stack: dangerous (because of a Krita bug where turning the visibility off a layer then pressing Ctrl+S doesn’t save the new visibility of the layer stack).

4) Proposal:

A right-click on the layer, going to “the toggle lock/vibility” submenu, and activate a dedicated option to turn a paint-layer (or a group) into being rendered with a target color. (note: the prefered color can be setup in the settings)


…then usage:

Let me know all what you think about it and if a proposal like that would satisfy other artists/usages. Thanks!


@Deevad thanks! also how do you think it should work technically? Should it be more like:

  • a layer with Color blending mode filled with that color,
  • a layer with Screen blending mode,
  • adding HSV filter with “Colorize” mode turned on and the hue, lightness etc. set to look like that color?
    You said you like the Screen workaround the most but it doesn’t mean it gives the most ideal results imaginable :slight_smile:

That’s a very interesting question @tiar. Thank you.
I thought “screen” blending mode might be perfect in all use case until I produced this test:

  • All “Color” (HSL/HSY/HSI) blending mode fails because they keeps the dark values (could be fixed with lowering opacity surely).
  • “Screen” creates the room for inking (and brighten a lot) but fails at keeping monochrom all already colored sources: color sketches and 3D rendering (and photos for sure too).

A combination of the two (screen first to brighten, then “color” on top to restrict the Hue could work. Also, a HSV filter with “colorize” and high luminosity/saturation and the right hue does the perfect transform for sure.

I’m adding here under the example file for tests. (All my pic in this thread are CC-By and encouraged for reuse/test).

1 Like

Here is three optimal test:

  • HSV filter (Colorize)
  • The overlay of “Color” blending mode grouped and reduced to 30% opacity
  • The duo of overlay “Screen” and then “Color” of the same color (note: the blue require to be less saturated for that)
1 Like

Hi, @Deevad!

From your text I see that you need that coloring only when the draft is completed, that is, you don’t need that while painting the sketch. If so, then why performance is the issue? You can easily apply a Color Overlay layer style with some opacity and it will do the trick.

When we discussed that several years ago, the layer style solution was discarded because of a bug in the style’s code that created halos around transparent stroke. But this bug has been fixed about a year ago, so it should not be a blocker anymore.

Or you want to paint in blue from the very beginning?

1 Like

Hey @dkazakov ! The sketch can be changed, scaled, adapted and painted-over/redrew at any moment. This is even more important when drawing a comic (turning to blue all sketch layer while starting to ink panel 1, then needing to redo the sketches of the panels after because they aren’t right anymore).

Tuning the sketch to blue shouldn’t be something destructive: even after turning it to blue, it’s important to keep the original sketch with all its range of black and white (eg. for publishing them in artbooks) or for later comeback in a artwork source and inspect what worked on it, or for later edit/correction by a publisher (aka: add a plant here, move the arm here, etc), for that you need to go back to the sketch everytime, and re-adapt later the inking.

It’s also super convenient to use the same inking tool (a black solid line, or dark grey textured pencil) and use it while inking to bring modification to the sketch layer in blue without having to switch drawing color or switch brush presets. (eg. adapting quickly the position of a hand, a arm while inking because the sketch wasn’t precise enough), with this layer in blue you just need to switch layer.

About “layer style” (color), I listed it in my workaround with PROS and CONS.The layer style solution is discarted mainly for performance. You can’t paint on Layer Style smoothly. It might work on a small image, but applied on a group and a 4K comic page it is transforming all stroke into a very slow, jolty and flickery situation.

About “paint in blue from the very beginning”, I listed it in my workaround with PROS and CONS too. Not a good solution.


Hi, @Deevad!

Are you sure you checked “Color Overlay” layer style recently enough? I cannot see any significant speed difference when using “Color Overlay” on a 4000x3000 image with “Ink-2 Fineliner” preset.

Either my computer is too fast for that or I just don’t see something. Or I have optimized that too much?

@dkazakov: Yes, I have a signifiant micro lag and refreshing issue on 4.3~appimage as soon as a layer with a “Color Overlay” Fx enters a subgroup in the layer stack. This lag is subtle and probably many will not feel it but I’m super sensitive to that. It puts micro time extra delay on the stroke, feeling like a delayed stabilizer while I’m using “None” as default stabilizer setting. The line quickly catch up the cursor but sometime starts with a micro lag. I also almost can see the tiles at work blinking in milliseconds and the preset doesn’t behaves the way I like and my lines are not correct in the end.

Here is a 30fps/gif capture downscaled, where the “Color Overlay” on a group “Sketch” affect even the refresh of the stroke happening on the inking layer (in parent layer group above). The first stroke had a massive lag, the one on the edge of the face too. Other had a slightly subtle “stroboscopic” effect. The “Color Overlay” was setup with #a6d4ff blue and “Screen” blending mode at 100% opacity. Of course the same effect also appears on painting on the “Sketch” group itself with the Fx.

Hello @Deevad first of all You’re doing amazing work keep it up!

Personally I use workaround number 5. But I use clipping group to make sure collor layer (set to collor) doesnt bleed to other layers.
Only way this setup would be simpler is to have “clipping layer” like in other programs. Its not such complicated setup but i understand you want custom UI solutions.

Going by the function of your idea its basically layer style with custom UI emelents. But that would suffer the same lags until layer fx performance gerts improved.
And looking from what you said reliable layer Fx would be acceptable workaround right?

OMG this lag at the begining of the stroke :weary:
My usual workflow consist of rendering on one layer (i merge all layers into one asap) i guess thats why i like to work in Krita even that Im also really sensitive to lags and performance drops.


I am sorry to say it but I have read this a good couple of times, and I really can’t understand any these as a issues that are not surpassable already. I don’t get what is the problem with planning ahead either.

As a summary on this I am quite against this on a overall scale. It does not seem to be justifiable.

if anything it should be some kind of artistic blending mode or layer modifier so it render right, and maybe some option on the preferences to choose the color so all “inked” layers have the same color? where you placed it seems REALLY incorrect for the current menu layout.

Your lag seems Very Low also on your example it does not seem to be hindering you.
was it compressed on the encoding when you made the gif?

P.S. - I am testing and I can’t feel any Increased lag… as expected.

It shouldn’t be necessary for it to be a clipping group, just a normal group should be fine because of the way Krita does groups. (By default they are not pass-through).

Layer with solid collor set to Collor need to be alpha locked to layer below in this case sketch layer or else it affects background.

1 Like

Hi, @Deevad and others!

Could you please check this testing AppImage:

It has a special filter: Filters->Colors->Fast Color Overlay. It is not configurable yet, because it is proof-of-concept. Its speed characteristics are almost the same as a clipping group, but it doesn’t occupy space at the layers docker (it can be collapsed). Just add this filter as a filter mask to your inking layer and it will colorize it into blue color (with 100% opacity, but it can be done configurable).


  1. Does the effect produced by the filter looks what you expect? Take into account that in the final version color and opacity will be configurable.

  2. Is the speed okay? The filter does not affect painting on layers above and should make painting on the layer itself a little bit slower [1]

[1] - The filter can be make even faster, though I’m not sure it is needed.

I must admit, I think that there might be a bug there, why would even a very heavy calculation layer affect drawing on a layer above it? Sure it’s heavy, but there should be a projection already calculated once and there is nothing I can see in that layer stack that would require a recalculation. So it shouldn’t cause any lag here. What do you think @dkazakov ?

I had a very long comment but unfortunately it got lost in unfortunate circumstances… I’ll try to repeat it but I hope you won’t mind if I will be a bit more straight to the point.

Generally what you are asking for in this proposal is a new type of “a non-destructive way to change how the layer looks like - with a parameter” (the parameter is color in this case). Krita already has two systems for that: (1) masks and (2) layer styles. Adding a new one only for this specific purpose doesn’t sound like a good idea.

I would suggest those three options:

  • using a mask but must be fast (that’s what @dkazakov did, he’s always so fast :P)
  • using a filter layer
  • making an easy way to set up either of those above, or even just a group with color layer etc. - the same way we have clipping mask. Group -> Quick Clipping Group is just a shortcut to create a new group, set up inherit alpha etc.

Hi, @tiar!

Sure it’s heavy, but there should be a projection already calculated once and there is nothing I can see in that layer stack that would require a recalculation. So it shouldn’t cause any lag here.

That is a layer style. The precalculated projection uses a weird algorithm of blending into the background, which has about four heavy merge operations. It is needed to ensure the styles are merged correctly in non-normal modes.

It might be that the merge process can be somehow optimized for “Normal” blending mode, but I’m not sure.

UPD: speaking truly, I don’t see any speed difference myself, but I believe that @deevad may see it on his hardware.

Im pretty sure he said it does affect him.
Im also lag sensitive and you dont have idea how it can affect your enjoyment and quality of work.
Arguing that is on the same lvl like “theres no difference between 60 and 30 fps”
You not being able to replicate issue doesnt mean he doesnt have it.

Hi, @Deevad!

Could you please test one more package? The main question I’d like to know about this package: do you see any speed difference when painting on a layer with Fast Color Overlay mask in comparison to the previous package?


Registry of packages:

  1. krita-4.4.0-alpha-f808c03-x86_64.appimage 1st package, proof-of-concept
  2. krita-4.4.0-alpha-8fed50e-x86_64.appimage “optimized” mask application, should be a little bit faster, but transparency masks are broken

Please take into account that this packages breaks application of normal masks, like Transaprency Mask. That is expected.

I am sure it does but I wanted to see how much it really does affect, because on the example given you can’t see none worth mentioning. I tested on my end to see if I could replicate it and also I can’t see it. Hence my position as it not being a problem.

Dude I am used to making 1 input frame inputs in fighting games and I am an animator too. I do all that frame data stuff. I feel difference between 4frame inputs from 60fps to 50fps. I think I can say I feel it too …

Also any input in or out costs you frames. Just because you can “see” the lag it does not mean you can even react fast enough for it to make any difference on your user experience on something static as painting and is able to finish your stroke before your even able to lift your pen up to do another stroke. Because that is what I see on the example given.

Once he lifted the key press the brush it would be done in 2-3 frames on that gif but since it is a gif I can’t check the real frame rate on it as it is ambiguous, hence the compression question for the frame rate.

He pointed out two massive lags that you can see.
As for his “stroboscopic” efect its more about how brush render than start stop. He said “feeling like a delayed stabilizer” so its about how brush lags behind cursor.

Well its more like imput delay than “lag”. Its like using non raw mouse input where cursor feels like on rubber band.

Dont count frames in 30fps video while canvas operate around 150FPS and brushes 120FPS
I had brushes that felt “delayed” while rendering over 60fps they only felt smooth while krita kicekd in over 120 fps. So idk how reliable framerates are to judge brush delay

@dkazakov: I tested the two appimage (carefully). As already mentioned on IRC, the “Fast Color Overlay” mode does only fill pixels non-alpha with a unique color. So it is far from feature complete. But you told me it was a test for performance of a way to do the composition.

animation of the filter right now over the image test

I opened my warm-up morning sketches and continued to scribble with both appimages. The two gives similar good result. I stressed the system with a 5K large picture, adding 4 paint layers of sketches in a group and applying the “filter mask” on this group: idem, both works.

the filter mask applied on sketches

What I had with the second version were mini rectangular holes glitches when the brushes were large.

two refresh glitch appearing (top right)

So, on the technical point of view; the performance here are OK. If the bluish effect could also work on my test picture I posted here [mockup] Sketch to blue (for inking) , and if the UI could be quick access/simple; that would probably cover the full case for the feature. :slight_smile:

@EyeOdin: I presume our setup might be different (monitor layout/compositor/OS/graphic-card/resolution/tablet-size). So, I believe you if you say you don’t have lag. That’s ok, thanks for testing. I also believe @dkazakov too and I know he believes my feedback because we know each other. Be sure, if I wanted to propose evil advice for pure lost-of time to the Krita project, it would have been already done over the last ten years… Now please let’s focus back on the topic and if you are not interested into this feature, think it is not something for you: I get it and that’s ok too for me.

1 Like