Glad to hear that! I wouldn’t trust krita to 100% correctly open psd files though, there is quite a lot of things not properly supported. Simple files without fancy functions should be fine.
I’m not sure when I could work on the thing again so it will be more like “help to properly finish feature and fix problems”.
I finally made another merge request. Honestly it was long and painful process so I have no idea if it really work as it should.
As far as I understand it krita use svg icons only for form, color depends on theme. Maybe there is a way to set color just for this one thing I don’t know about it. I barely know anything about krita code at all, all my changes is trial and tons of errors.
This is amazing! I was requesting this feature for so long for Krita and I’m so glad that you updated the build!
It’s very useful already and I really hope this feature will find its way to the main build, this would be huge!
For potential improvements to the behavior, I think it would be cool if we could also clip a group to a group.
I decided to update Radiant-art clipping mod. It was great for start, but i found a few issues and gitches during strokes, and made several changes for features that I always felt missing in Krita.
The full list and description you can find inside the build archive. It contains builds for Win 64, Linux and Android arm64-v8a , diffs and some tips for building ||if you want to check it yourself (there is mistake in win build tips, run build from the _build directory, not b_krita)
I corrected some glitches and dirty strokes occured with certain layers order, groups, groups pass through mode, overcomposition (extra projections update for the same layer) and for layers with effects, existed in the base Radian-art commit.
I have fixed as many glitches and dirt rectangles as i could find and test but I’m not sure everything working fine now. Please test cases what you can imagine, maybe something is still missing. For current limitations and issues read please full description doc.
Glitches are not fixed fully, there is something wrong how the app renders job rects during the stroke process. I tried adding barriers before actual rendering, but this actually doesn’t worked well (it seems render requires barriers too). However, giltches that became PERSISTENT after a stroke should be fixed now (there where many scenarios when dirty rectangles remained visible after a stroke).
Inherit Alpha should work as usual and should work with base+clips stacks too.
Added clipping for filter layers and pattern (fill) layers. Sad, but clipped filter layers are slower compared to ususal Krita workflow. Layer styles - sadly, but working only for base+clipped layer stack now. I just skip styles for clipped layers now; need to better understand composition rules for them. I’ll look on it later. For now you can add a style to base layer and this will be applied to base layer + its clips.
Added redbar indication, as described in posts eralier. It should copy CSP logic for indication of clipped layers, included name shift for clipped layers and greyout for toggled clipped layers. Modified logic for addition new layers, auto clipping for new layers between base and already clipped, and more. (forgot to change clip buttons positions from Radiant build to more consistent, sorry)
Disabled “drag-to-order” layer reordering for the visibiliy and selection collumns in the layers docker. I had realy bad experience in Krita when trying to click on layer name to switch on it, then try to click to toggling visbility or selection - and it stared to move layer order then instead of toggling it. I decided to disable any drag to order event from these columns completely! Toggles are for toggling.
Added “drag-to-toggle” event for layer visibility column. This is because i have really strong habit from IS and CSP, that I just can’t get rid of it in principle. Same behavior from CSP/IS - just press and drag cursor to toggle many layers with one gesutre. Should work for kinetic scrolling setting both disabled and enabled too (no scrolling over toggle cols, same as the previous change).
Added delayed stroke stabilizer. It is working with NONE and BASIC Krita stab. I still haven’t gotten used to the default Krita weighted and simple stabs, completely are differently from how IS/CSP do: Krita stops stroke immidiately and has very strange stabilisation logic.
So here I tried to copy behaviour of IS/CSP stabs and i think it work almost similar now. It uses simple delayed stabilizer (similar to smoothing in MyPaint brushes or Dynamic brush, but without mass inertia model), with stroke tapering after releasing pen pressure (hovering pen continues to draw a stroke with smoothly fading last pressure value to zero).
The delayed stroke feature after releasing pen pressure is similar to IS Haraiso or Harai ( [はらい] ) or CSP “Taper” function of stabilizator.
Description for the option in IS:[はらい]……値を大きくすると、タブレットからペンを離したあとも線が徐々に細くなりながらペンについてきます。
Description for the option in CSP: “Taper Changes the length by which a line is continued when drawn by gradually decreasing the pen pressure.”
When the value is large, the line follows the pen by becoming thinner even after the pen is released from the tablet as if it were drawn with a calligraphy brush with long tip.
For me this feature create much more natural feel from drawing at low values, giving a sure that “yes, my stroke stops exact where i want!”, that always was missed for me using default stab, and my palm feels much better with it. And of course gives me control for cool options of drawing sorts of calligraphy scribbles and dirty texts.
Taper, Pressure fadings, and stab rates by the cursor speed are customisable, default values for me looks like “5 0.2 5 5 5”. You can set stab value for low and high speeds as described in their tooltips.
Also, added stroke combining similar to CSP/IS - a few strokes will be combined into one history entry. You can set wait time for a new stroke. Very useful for excessive hatching work. I found Krita’s history combine is not very handy in this scenario.
Added View Mirror Button and Event for vertical axis. Krita has already mirror methods for both axes (Point KisCoordinatesConverter::mirror(QPointF center, bool mirrorXAxis, bool mirrorYAxis)), but for uknown reasons they implemented only Horizontal Mirror for view. (Krita has a canvas mirror operation, but it slow and actually mirror canvas pixel map, with writing to a project file and history, this is not ideal).
So i just added the button and event for overview, toolbar, hotkey, you can mirror view now vertically and horizintally as you wish!
Also added additional view control buttons to the Overview docker - rotate, reset rotate, reset view to fit, reset zoom to 100%, zoom out, zoom in. Really missed them compared to IS and CSP, especially for the Android build or display tablets without touch screen. I know they can be set in the toolbar, but that place could be used for other buttons, and Mirror View Button looked very lonely there.
Windows build can show warning window during startup about overwriting krita settings, but this safe, it should not break common settings for your usual krita.
Linux build for some reasons opens saved files with canvas shifted to random place and mirrored, not looking yet but maybe this is occurs only runnig in VM.
For other limitations or known issues look please in differences description file.
Awesome work and contribution, tested it on windows and everything works well so far. Thank you for also including already built versions of your mod, as someone who doesn’t know how to properly build an app on windows (i think linux is easier but i’m not using linux atm) it would have been a hassle to do it, also i know you put instructions there too, so thank you so much for all your hard work on this contribution! If i ever come across a bug i’ll let you know!
Maybe i will try to make merge request for overview and stabs, but for clipping - i think it is impossible, too hacky thing without any chance to be merged.
Fixed dirty rectangles for brushes with “Masking” enabled. Same issue about projection update and stroke jobs concurention, but it seems to be fixed by barrier jobs scheduler for projection updates of masked painter for brashes (i suppose it could occur even in master branch but not often, Radian’s clipping approach just make it more frequent).
Setup fixed position for clipping button icons in layers docker.
This!!! Krita’s stabilizer just feels weird to use. I have to use LazyNezumi instead for a more intuitive feeling. I’m hoping official Krita will adopt this feature, even more so than the layer clipping.
Hi, so I found something strange, it’s not a bug or something like that but rather, a somewhat “incompatibility” with a plugin called Pigment.o
For some reason, your modified version makes the color wheel lag when selecting colors (moving the circle that has the current color around to pick another color inside the color wheel). I tried to confirm if this was my pc or regular behavior and i found out that this only happens with your version, regular krita and the version of radian have no issues with this plugin. I tried turning off your changes to pen stabilization but that didn’t change anything. I would love to give some more help but i’m not a coder so i have no clue on how to help more with this issue and i’m not sure if you want to fix it, since it’s not like it makes the plugin unusable, but i just wanted to let you know just in case you can give it a look, it may be an easy fix or maybe it’s not. Thank you either way for your contribution!
Hmm, it looks like something in Krita 5.3 has been changed, no special reations to my changes. I’m observing slow performance (not only wheel, any type is slow) of Pigment.o for any 5.3.0 nightly build i have before ae1a4b69
krita-x64-5.3.0-prealpha-ae1a4b69 works well (dec 09 2024) (some experiments for ai)
krita-x64-5.3.0-prealpha-cdac9c31 already slow (dec 19 2024) (brunch for fastsketch experiments)
last common commit was f1b8cf54 from 5 dec 2024, and last common commit with master for cdac9c31 was 50e1899b 16 dec 2024, so something between 5 and 16 dec was changed. Many sus commits actually there. Maybe it relates to 6c294f58 for example (something about tracking user events and python exactly).
I’ll investigate, but it looks like the author of Pigment.o will have to update the plugin to the release of Krita 5.3. At least it has now the option to disable instant color load to krita color dock, this speeds up slightly the color selection as i see.
Thank you so much for taking your time to look into this issue, it totally went through my head to check the different versions, as i don’t use the nightly builds of original krita i didn’t thought about it. I’m afraid that pigment.o is not gonna get updates since it hasn’t received one in more than a year and the author made it open source, if still you decide to take a look to maybe implement a fix, you’ll deserve heaven brother!! Hahaha. Thank you anyways for all the work you’re putting on all these modifications!
Author definitely should to rewrite logic of how Pigment.o interacts with Krita 5.3, it should not spam input events which this commit related, i guess.
This is actually a critical change, may affect for any other plugins for Krita. In one side it is important change, because previous builds could miss old user inputs from user plugins, with this change it execute full input and api calls queues from scripts. But the bad side is performance, if author didn’t make special efforts to manage queues order and didn’t limit rate of api calls.
I can try to make switch in settings, but it seems it will require to restart Krita to apply effect.
I’ll try to reach the pigment.o author to see if he can do something about it, thanks for describing the problem, i will also send him what you said here, might make his job easier. Thanks again for all your hard work!
Hi, I’m using windows. Please make a build so i can test it, pigment.o author doesn’t want to do anything to fix the plugin and basically said we are spreading misinformation lol
Here is. Described change is disabled by KRITA_DISABLE_SYNC_EVENTS env variable, it is already set in kirta_no_sync shortcut, you can run it by clicking on it.
There is also initial changes for blur filter brush. All we know krita blur brush is acutally smudge brush, and not actual blur. Krita has blur filter brush, yes, but this brush is not working normally. But this is actually exact what we have in other apps - IS/CSP/SAI/PS/whatever - but without a few things. It makes blur, but without autoscaling blur kernel to brush size (~20% to actual brush size for CSP or IS for example). And it has no stroke accumulation, so when you try to move filter blur brush in Krita it doesnt blur further till you stop stroke and start again. This is not how blur brush working on another apps.
So i added stroke accumulation (need to test it with clipping) and autoscale blur kernel to brush size (default scale set to 20% by default same to IS/CSP blur brush as see from many tries and compares). There are 2 new checkbox for enabling blur accumulation and autoscaling (works for blur and gaussian blur filters only now).
Blur filter brush is still slow, and it is sad. 2012 32bit IS is tens faster and run 500px blur brush easy while modern 64 bit Krita stumbles hard on 100px blur kernel. I thinking about mipmap down-upsampling blur or FIR appox aproach for blur algorythms to accelerate it, so this is a very very early change.
Yep, you definitely fixed it with this build, now pigment.o works as intended, tho it’s a shame the author doesn’t want to make a proper fix, whatever… I couldn’t find the checkboxes you mentioned for the blur accumulation, tho it might be my own fault. If there’s anything i can help you, please send me a private message so we don’t bother people here with our responses anymore hahaha, thank you either way for all you’re doing, i hope one day it will be merged with default krita
Here is video, it is Filter Blur Brush.
But it is useless of couse with so slow performance. Need to accelerate default krita blur filtering or make separated bluring for blur brush, thinking how…
