| Summary: | Bad initial numbers when entering Pallete color RGB values | ||
|---|---|---|---|
| Product: | [Applications] krita | Reporter: | tylerecouture |
| Component: | Dockers | Assignee: | Krita Bugs <krita-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | tamtamy.tymona, tomtomtomreportingin |
| Priority: | NOR | ||
| Version First Reported In: | 4.4.1 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | gif showing bug | ||
I can reproduce bad channel value ranges, so I'm confirming. You do get valid channel ranges if you open the color selector in the Brushes and Stuff toolbar before you reproduce these steps. However, the channel value range stop making sense again if you create another document with a different bit-depth and add a palette color there, as it will use the channel ranges from the 8-bit document again. The reason for this is that Krita doesn't save the bit depth when saving the last used color in preferences (kritarc). See KoColor::toXML and KoColor::fromXML. Also see how kritarc saves the colors: LastBackGroundColor=<!DOCTYPE LastBackGroundColor>\n<LastBackGroundColor>\n <RGB space="sRGB-elle-V2-srgbtrc.icc" g="0.219607844948769" b="0.219607844948769" r="0.219607844948769"/>\n</LastBackGroundColor>\n LastForeGroundColor=<!DOCTYPE LastForeGroundColor>\n<LastForeGroundColor>\n <RGB space="sRGB-elle-V2-srgbtrc.icc" g="0.439215689897537" b="0" r="0.847058832645416"/>\n</LastForeGroundColor>\n So it saves the color space and the profile, but then just assumes that the color is in U16, I think (since that's the default). It kinda works but when you open the palette docker and adds a new swatch, it detects that the current KoColor is in U16 and shows the color correctly. Interestingly, the DualColorButton kinda forces the image bit depth (and possibly the color space as well). In my opinion it would be good to fix the root issue. I don't have an opinion what should happen if the KoColor was actually U16 from the previous image. I think maybe it should be preserved, if the user uses multiple color spaces and depths, they probably know what they're doing. For the fixing the root issue, it's probably not difficult but I would like to get @Wolthera's opinion first. I'm not sure if it was intentional or not. I wasn't able to reproduce it at first in either 5.2.6 or the 5.3 pre-alpha. After verifying that I can indeed reproduce it in 4.4.1, however, the faulty initial values showed up in the later Krita versions as well. I think someone from the development team will have to confirm whether it can be marked as resolved or not. |
Created attachment 133762 [details] gif showing bug SUMMARY When trying to add a new color to the palette, the Channel values are all set at 65535. When I enter a value between 0-255 and then click out, the color is always black (the values appear to be out of 65535 instead of 255). If I enter the same values a second time, I get the color as expected. STEPS TO REPRODUCE 0. Create a new document with default sRGB-elle-V2 and 8-bit Depth 1. Click + to add a color to a palette in the Palette docker 2. Click the "Color" to open the color picker 3. See 65535 in all RGB 4. Try to change them to 100, 100, 0 and get black 5. Click away - all values change to 0 5. Try entering the values again, 100, 100, 0 and it works, you get a yellow color. See attached gif OBSERVED RESULT Initial scale is 65535 Switches scales the second time you enter values EXPECTED RESULT expect a scale of 255 Don't switch scales SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 20.04 ADDITIONAL INFORMATION I remember reporting this bug for an older version of Krita a year or two ago but couldn't find the report.