![]() Registered Member ![]()
|
Hey all,
I've just come across Krita and it looks very interesting, but I've ran into a glitch that makes it rather unusable at the moment. There wasn't much I could find about it on the forum, so I'm asking it here. When painting I get these white, vertical striping patterns in the paint, especially with the 'blobby' type brushes, that cover a large area. The stripes appear to scatter, and move around when I paint over them, some disappear when I move the window or twiddle with the OpenGL settings. So I'm guessing it's a driver issue, but on my older system it seems to work fine and that's an Nvidia too. It happens whether or not I enable OpenGL in Krita, independent of mode, both with mouse and stylus. Here's a screenshot: http://imgur.com/6rsQFU9 Currently I'm on a i7 running Windows 8, with a Geforce GTX 7800Ti, driver version 344.65 (latest). That's the one with the striping glitches. The older one is a QuadCore running Windows 8, GTS 8800, driver 331.65. Is there a way to get it working? |
![]() KDE Developer ![]()
|
Hrm... That really looks like a driver issue -- if they disappear when fiddling with the window, it isn't the actual image that's broken. You can verify that by saving and reloading an image when you get these artefacts. I should check which driver is currently on my win7 system and see whether I can reproduce when I upgrade the driver, I haven't done that for some time. There's no way of knowing what Nivida has changed between 331.65 and 344.65...
|
![]() Registered Member ![]()
|
Thanks Boudewijn,
I've checked some more, it doesn't really go away when I twiddle the OpenGL settings, it just looked that way. It's basically in every brush I tried so far and it shows in every export format, including the native format. Could it otherwise be related to a dual monitor maybe? I've got a cintiq with a normal monitor, while the older pc has only the one monitor on it. |
![]() KDE Developer ![]()
|
I really doubt it has anything to do with a dual monitor setup. Does it make a difference which colorspace and channel depth you use? That said... I've never seen corruption like this as anything other than a display issue -- if painting would be broken like this, we'd have heard of it before!
|
![]() Registered Member ![]()
|
Well... starting in 16bit or 32bit floating, RGB color and with the built in sRGB profile seems to do the trick.
No more artifacting, nice!! ![]() Many thanks. |
![]() KDE Developer ![]()
|
That is extremely curious, though -- if at all, I'd not be too surprised at artefacts in 16/32 float rgb with opengl disabled, because I remember spending a day or two, three fixing the artefacts caused by converting from float rgb to 8 bit integer rgb for display.
|
![]() Registered Member ![]()
|
Well, I've been twiddling with almost all brushes now mostly in 16bit, some in 32, OpenGL enabled, including some downloaded sets. There's no artefacting, except in the brush preview screen of the brush manager.
So... I'm clueless but happy to be painting ![]() |
![]() KDE Developer ![]()
|
Well, we are clueless but happy as well.
Do note that 16bit and higher takes us quite a bit of hard-drive space compared to 8bit. The gradients will be smoother and colour corrections will be more precise due to the high bit depth, but seeing the full file-size of such files can come as a shock at first. (For a png file of mine the difference was between 1.8 mb in 8 bit and 20 mb in 16bit, to give you an idea.) |
Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]