Bug 437430

Summary: Wrong displaying of colors with big valued components in 32 bits
Product: [Applications] krita Reporter: Deif Lou <ginoba>
Component: GeneralAssignee: Krita Bugs <krita-bugs-null>
Status: CONFIRMED ---    
Severity: normal CC: ahab.greybeard, halla, tamtamy.tymona
Priority: NOR    
Version: git master (please specify the git hash!)   
Target Milestone: ---   
Platform: Manjaro   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Deif Lou 2021-05-20 20:12:20 UTC 
SUMMARY
In 32 bits, when a layer has colors with big values, they are displayed wrong when canvas acceleration is used. When canvas acceleration is disabled it seems to work ok.

STEPS TO REPRODUCE
1. Open Krita and activate canvas acceleration in the settings
2. Create a 32 bits image
3. Set some component of the foreground color to a really big value, for example rgb(9999999562023526247432192,00, 0.0, 0.0)
4. Paint

OBSERVED RESULT
If values for the color components above some really big number are used, they are displayed wrong, as if some kind of overflowing was happening. If one disables the canvas acceleration those colos change and look apparently right.

EXPECTED RESULT
The colors with big values should look right. For example a color rgb(9999999562023526247432192,00, 0.0, 0.0) should look red, but looks black with a blue border.

SOFTWARE/OS VERSIONS
Operating System: Manjaro Linux
KDE Plasma Version: 5.21.4
KDE Frameworks Version: 5.81.0
Qt Version: 5.15.2
Comment 1 Tiar 2021-08-19 20:36:19 UTC 
Can you maybe make an attach an image like that? Preferably with a screenshot with how it looks and possibly also how it should look (if it's not obvious).
Comment 2 Deif Lou 2021-08-21 15:10:41 UTC 
Hi. I made a video back then: https://www.dropbox.com/s/wb7l6xqxyof5220/2021-05-06%2011-28-16.mp4?dl=0
There it can be seen that the colors painted on the canvas are not the same as the ones selected. And that disabling canvas acceleration shows the right colors (although there seem to be stioll some white artifacts, I don't know if that's normal due to the high values).
Comment 3 Tiar 2021-08-22 22:35:02 UTC 
Does it also happen if you use a new layer, not the background layer?
Comment 4 Deif Lou 2021-08-23 19:44:17 UTC 
Yes, it also happens when painting on a new layer. And it produces also artifacts on the semitransparent areas, even if you are painting with a "good" color on the layer below.
I think this is related to opengl rendering. Maybe some overflow related issue. The colors in the layer seem to be ok because if you disable canvas acceleration they look fine.
I tried to find the issue in the code back then but got lost.
Comment 5 Ahab Greybeard 2021-08-30 09:48:40 UTC 
I see this happening in the 4.4.8 appimage on Debian 10 - but not in the 5.0.0-beta1 or the Aug 29 5.1.0-prealpha appimages.

There may be a 'critical number' at which this happens.
e.g. with 19000006784332389679104.00 it happens but with 15000006784332389679104.00 it does not happen and I can go from one to the other with repeated effect.

However, that can vary each time I try it (by reducing to zero, painting and then entering a new very large number).

Note: 5.0.0-beta1 onwards won't accept a large number pasted in. It highlights it in red and then forces it to 1.0 but you can type a large number in and it will be accepted.
With 4.4.8, you can paste or type a large number in and it will be accepted.