Thanks for the awesome work!
Sorry but I have some problem trying this.
I’m on krita 4.2.9 on my old Win7 laptop.After enabling the plugin, one of the cpu core raised its usage to above 80% without doing anything, and the CPU got very hot (from 65 to 80C)
And when I disabled all slider, the CPU usage dropped and the temp goes down.
Slider ON-------------------------------------Slider OFF
I was checking it and it is true on my end too, I am really sorry about it.
I did a couple of tests of what might be the cause of it but all the culprits but they came out clean. The only thing I can Imagine is the circular loop between the widgets. Like if you start scrubbing one of the sliders it will lower the processing power by half and that is why I think it “might” be that, because once you commit to a change pigmento closes doors so it does not feed back to itself.
It is what allows you to connect everything together and not just have information flow in one direction. Allowing you to use the slider and change the numbers and then change the numbers and have it change the slider back on any channel back and forth. Closing the flow would mean the widget would never be clickable and everything would not work making a dead UI.
The Sucky thing about this possibility is that to even test it I need to remake the whole plugin. And I am not even sure if there is a alternative to the method i used. It took me a while to actually find a way to do it like this.
I do not have any alternatives as of now but I will keep it in mind to see if I can find something to change this behavior.
Hi, thanks for making this amazing plugin! I am used to using HSV color sliders as I transitioned from photoshop and am so happy to discover this.
I have tried it and found that dragging on the sliders causes lag. It does not lag when shifting in increments using shift/ctrl. The selector follows the drag path up to a certain speed, and would continue traveling the exact path after I stopped.
A small UI issue is somehow my sliders are missing the arrow buttons.
Could you make it save the activated channels/panels too? Not sure if this is included in the save/load last session settings but it always resets to show only RGB sliders when I start Krita.
Would second this suggestion for better discoverability, Cheers =D
I dont want to be mean or depressive but you seem to be using a linux machine.
I tested it on a Linux machine the other day and I found out everything goes really slow. Maybe it is related to the behavior @Lesqwe56 was talking about and that has a bigger toll on Linux? I am not sure. But what I did there already for now is placed everything on separate threads so your mouse still moves as light as possible… I am sorry.
Your missing special characters on your OS. that characters that should be there are:
⏴ and ⏵
To try and fix the CPU thing I might consider making a lighter version of pigmento with just the essential. Perhaps it would work better on Linux too and i could test a lighter way to make it work overall. However I would not bet my money that it will be possible without some kind of weird compromise. like numbers are no longer editable and become read only.
Strangely on my end it looks a bit more like this.
That would be rather doable. Later today I should have that done or tomorrow I think.
I tried it a few weeks ago on my linux setup and had the same problem with lag.
As soon as I open the pigment docker I can hear my fans speeding up, and then when I close it they go quiet.
Sorry I didn’t mention it before - probably would have been helpful… 
I haven’t tried a more recent version.
Yea, I’m on linux and also experienced the same cpu issue as mentioned.
Still, it wont stop me from using this!!
I’ve fixed the arrows by installing the symbola font.
And thought of another suggestion, a toggle for percentage display like the specific color selector.
Appreciate your work, Cheers =D
Thanks for the fast response😀
I think an editable slider is more intuitive than just read-only numbers.
There’s a GIF in Krita 4.3.0 Release Note (In “Color Handling” section) shows the color selector dialogue have both RGB/HSV numbers. However it has no slider, and pressing ↑ and ↓ or just put the number to adjust only one value is quite counter-intuitive to me.
Cheers! =)
I did not do a toggle because I would have to kinda cheat on the math. if is a really stupid issue of placing 3 on the place of 2 and then 2 on the place of 3 again. or you hold the variable hostage to “make it look good” or the conversion shifts ever so slightly. Took me so long to discover how QColor messed this up so royally.
My approach was not as to “toggle” but make it working in that color space range from the get go like a slegehammer DX! Might not be the best but it works!
Changing Color Space Range:
Internally Pigmento always works in 0-1 until it has to output it somewhere. When it pulls the values from somewhere it is after a transform so it changes it back to 0-1. So like the values are pure constantly while you change. That is why you adjust the values by hand on HSV and then you see it shifting a bit so it is actually on the right spot for the color you choose on its RGB equivalent.
However I do not recommend changing any of it because you loose colors in the process if your not in RGB. My weird hack was to make a percentile ruler over the sliders and in between them so you can see where the percentages are. You can press CTRL too while moving the slider to make it fall on round values like 10%, 20%, 30%, 40%, 50%…
Update: Loads Last Session setup of Channels, TIP, TTS, MIX and Panels
yes
I was taking a look at it again and it does look cool.
I had the arrows too on the first versions too that I made but since you can use the Up (+1) and Down (-1) arrow keys and PgUp (+10) and PgDwn (-10) I thought they were ignorable, because I wanted to make the UI scale really tiny and miniature arrows where not usable on the numbers box. That is why I made massive arrows on the sides of the sliders that would scale more elegantly. But you can use the same shortcuts on the new HSV controls too.
HSV has 2 floating points. So they do agree on that. Nice.
I see.
I had totally no idea that it was a percentile ruler, I thought why does the UI have some weird notches on it haha.
Thanks for the quick update, feature working as intended.
I made a lighter version sketch of Pigment.O to test the source of lag in Linux systems.
this is only a Temporary Version.
https://github.com/EyeOdin/Pigment.O-Lite
if changes work and it becomes lighter I will change the main repository with this.
I made the connections a differently and that was what I was testing now.
I made this repo for myself so I can swap to linux easier but I thought i might say anyway since I am not a native Linux user and someone might have a different experience than mine and for sure more educated.
Hi, I’ve tested the lite version on my system. CPU usage reduced, I can now slide it around without lag.
This is the CPU usage for the original, which raises usage of 1 of the CPU to 100% when sliders are displayed in the docker.
Here’s the lite version in comparison, first half minute is CPU usage without any interaction, followed by dragging the sliders which causes it to increase but not 100%.
I noticed the lite version have point clicking disabled, instead only move in increments of 10 towards the point.
I also found a minor bug when adjusting using HSV which is present in both versions. I think it has to do with HSV to RGB conversion as it always round down any decimal for RGB. When adjusting Value, Saturation will increase slightly. Hue will shift up or down very slightly and tend to shift towards 120, 240 or 360 if not on 0, 60, 120, 180, 240, 300 or 360.
that is good good. I am on the right track then.
My thoughts up till now is that my problem was mainly how I organized my modules. Today I will be working on the looks.
that is natural because they are not the same widget.
pigmento has a custom made widget while lite has a standard slider.
I think what your noticing there is just the “auto correct” loop.
I made it unintentionally but it makes sense. I know the loop is a bit stressful to look at but I assure the color math conversion is correct. HSV is built upon RGB color space and that shift is just pigmento adjusting you to the correct index of the color you choose.
you can test color conversion with this if you want to take a look:
Understood.
I apologize in advance for being over-concerned about it and I’m probably nitpicking at this point, but the difference with Pigment.O and Colorizer.org is how they round off decimals. For example, if the value of Red is 0.9, Pigment.O will correct it to 0. Colorizer.org will correct it to 1, which is closer to the decimal value. Colorizer.org rounds down to 0 if decimal value lesser than 0.5 and rounds up to 1 if value equal of more than 0.5. Really minor detail, It is just what I think of as more “correct”.
Regardless, looking forward to the next update. Cheers =D
if your so interested in that just lower the decimal display on the value display on the UI file on pigmento and you will have the same exact behavior. That round of the result is given by the number display and not by the color conversion itself. because the color conversion code is the same I did not invent RGB nor HSV.
in your example you choose 0.9 right? well that means you haven’t selected 1 yet so you applyed 0 right? when Pigmento checks the color on Krita, the color is Zero. So it adjusts itself to Zero. So you get Zero. As I said before a “auto-correct” loop and the correct color index selected.
Math wise that makes sense what you say, but normal RGB is “Integer” and not a “Float”.
If you do that roundness what you get is the color check slowly shifting until it reaches zero as time passes on.
I see, thanks for the explanation and being patient with my curiosity.
Update: Reduced Idle CPU usage
I still haven’t finished Pigment.O Lite to become the New Pigment.O.
But I think I found the main culprit of the lag. I literally just deleted just 2 lines of code on the old version and the difference should be quite noticiable.
I will keep tweaking Lite it to improve performance.
The 100% CPU usage on idle issue has been solved for my side as well, but the slider lag on linux still persists.
