![]() Registered Member ![]()
|
Hi I haven't found this issue posted and I don't know how to explain it without a long description.
I'm trying to create a limited gamut palette by:
2.) painting them opaquely onto a grid on the canvas (single active layer 85% grey), 3.) adding a new colour (+ button in palette docker) to a new palette that I've created 4.) selecting the colour swatch button from the now active "Krita" pop-up (ID[textbox]/Name[textbox]/Colour[colorswatch button]/Spot[checkbox]) 5.) selecting the eyedropper tool from the now active "Colors" pop-up 6.) picking the colour from the canvas and selecting the "OK" button on the "Colors" pop-up 7.) selecting the "OK" button on the "Krita" pop-up ...and sometimes 8.) updating the new palette in the palette docker by switching back and forth between my new palette and any existing one (a workaround to the palette not always updating on the fly) When I select a colour in the "Colors" pop-up, it changes the swatch in the "Colors" pop-up correctly and changes the RGB or hex values to the appropriate colour that I've selected, however selecting the "OK" button results in a vaguely similar but entirely different colour on the colorswatch button when returning to the "Krita" pop-up. This is not a problem with the eyedropper alone, but also occurs when manually entering a hex code or RGB values in the "Colors" pop-up. The colour that results afterward appears to be consistently the same colour, but not the colour desired. In other words, the resulting colour prepared for the palette is precise but inaccurate. Here's a couple of examples: R76, G84, B105 (hex:4C5469) in "Colors" always becomes R58, G65, B86 (hex:3A4156) in "Krita" R184, G112, B102 (hex:B87052) always becomes R168, G91, B63 (hex:A85B3F) whether selected by hex, RGB or eyedropper between steps 6 and 7. If I select the (now incorrectly coloured) colour swatch button on the "Krita" pop-up to return to the "Colors" pop-up, I see the adjusted RGB/HEX values. Therefore the chosen values will not be able to be saved to the palette by selecting "OK" in the "krita" pop-up because step 6 cannot be completed. I can't really anticipate the pattern to the changes in value (the first example is an approx. 7% Red 7.4% Green 7.4% Blue decrease in value, the second example is an approx. 6% Red 8% Green 15% Blue decrease). I have enormous difficulties making palettes because of the breakdown between the "colors" pop-up and the "Krita" pop-up. Colours are dramatically altered (eg. desaturated greys become pastel blues). I have not been able to create an accurate palette since I began using Krita about a year ago. I have no idea how to make an accurate palette despite what appears to be the ability to enter hex/RGB. Help! This is very frustrating. I'm pulling my face off trying to make a palette that doesn't shift into something completely off. There must be something quite obvious here for other people who are better versed in digital color. What am I doing wrong? Is there another way to create a palette accurately? |
![]() Registered Member ![]()
|
I found a palette making solution to achieve the desired results, but an overall problem remains with the "digital color mixer" docker:
Solution:
2.) paint the chosen colour onto the grid 3.) repeat 1 and 2 to complete your gamut 4.) glaze mix the colours using an approximate % via brush opacity 5.) using the eyedropper tool (not editing the palette colour swatches)to select the mixed colours, add to your palette This will return 100% accurate and 100% precise colours on your palette. Problem: I'm fairly convinced that the "Colors" pop-up (above post) is not even a Krita pop-up. It appears to be a OSX dialogue that Krita doesn't communicate with well. Aside from the title, it's the exact same pop-up that is used to change the OSX desktop background colour. The real issue here is that the "Colors" pop-up is the only way to input new colours into the "digital color mixer docker"(DCMD). It continues to have the exact same inconsistency with the colour swatch buttons in the DCMD that it has in the "Krita" pop-up (see above). The RGB values suffer the exact same inconsistencies with 100% replicability. This means that the only reliable colours that you can use in the DCMD on OSX are the default colours. All other colours will be inaccurate (but precisely inaccurate) due to the miscommunication between the "Colors" pop-up and Krita. This makes the DCMD pretty problematic in OSX. Conclusion: While I've found a workaround to achieve desired results with the palette docker, the problem with overall colour selection continues to plague me. I'd guess that this might be some sort of system configuration problem in my OS. Or could this be an issue with OSX and Krita? I know very little about computers, but I hope this helps anyone who has encountered a similar problem. If you're using OSX and Krita, the DCMD and various other colour swatch buttons might give you a massive headache. |
![]() Registered Member ![]()
|
You seem to have done a good and thorough investigation of the problem which would be very useful. The next stage is to file a formal bug report at https://bugs.kde.org/
(Sign up and login are required but you can use exactly the same details as your forum account here if you want to.) If you read a few bug reports you'll get an idea of the format and general presentation conventions. You can give a link to this forum topic and summarise it in the bug report to save copying all the details from here. |
![]() Registered Member ![]()
|
Thanks for the link, ahabgreybeard. I will do so when I get an opportunity.
|
Registered users: Baidu [Spider], Bing [Bot], Google [Bot]