[krita] [Bug 465013] New: PSDs do not load properly and show a blank canvas with several lines.
https://bugs.kde.org/show_bug.cgi?id=465013 Bug ID: 465013 Summary: PSDs do not load properly and show a blank canvas with several lines. Classification: Applications Product: krita Version: 5.1.5 Platform: Android OS: Android 13.x Status: REPORTED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: wontoon...@gmail.com Target Milestone: --- SUMMARY When opening a PSD file in Krita 5.1.5 on Android 13, the PSD will not load properly. Happens on a Samsung Galaxy Tab S8 Ultra. Also tried it on my phone (Samsung Galaxy Note 10+) with 5.1.3 still installed (!) and on Krita 5.1.5 on deaktop (Flatpak), both of which still open properly. STEPS TO REPRODUCE 1. Choose a PSD file and attempt to open it in Krita (5.1.5, Android 13). 2. Cry. OBSERVED RESULT You will see the file have its proper dimensions but see a white canvas with a few lines. Thumbnail works just fine in the dropdown menu. EXPECTED RESULT The file to load as normal. SOFTWARE/OS VERSIONS Krita 5.1.5 for Android (Samsung Galaxy Tab, Android 13) ADDITIONAL INFORMATION For now my workaround is to just convert PSDs to KRA on another platform and import it into Android. PSD import did work fine for all versions before 5.1.5; not exactly sure if it's 5.1.5 on the tablet or in general. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442676] Color selector will not update if green and blue values are the same if using color picker
https://bugs.kde.org/show_bug.cgi?id=442676 --- Comment #7 from Wontoon --- (In reply to Tiar from comment #6) > @Wontoon please check Krita 5.0 beta 1 too? First you need to backup your > configuration and resources, here's the info how: > https://krita-artists.org/t/help-krita-improve-with-structured-beta-testing- > of-the-new-resource-system-in-krita-5-0/28779#before-you-start-how-to-back- > up-things-5 Heya! My apologies for the late response; got overwhelmed by a few things. But, I did take the time to test to see if the bug is in the recent nightly build of Krita 5.0.0-beta1 (git 0ff34e9) on Windows, and I can happily confirm that the bug is NOT present in that build, at least. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442676] Color selector will not update if green and blue values are the same if using color picker
https://bugs.kde.org/show_bug.cgi?id=442676 --- Comment #3 from Wontoon --- (In reply to Halla Rempt from comment #1) > Sorry, but even with the test file, I cannot reproduce this. I have checked > both the dedicated color picker tool as well as the ctrl-click color picker > of the freehand tool. I enabled the Specific Color Selector so I could see > the numbers of the colors, and they all changed properly. Odd. I can consistently reproduce the bug on my end, even as I'm typing this comment in version 4.4.8. If need be I can find some screen recording software and show the bug in action. Also going to raise the possibility of it being an OS-related bug, if you're not using Windows. I've had Krita just break when selecting colors after a Windows Update, but the devs pushed out an update shortly after and fixed it. Plus I did get pushed a Windows Update a couple of days ago, hence the possibility. :Oc -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 442676] New: Color selector will not update if green and blue values are the same if using color picker
https://bugs.kde.org/show_bug.cgi?id=442676 Bug ID: 442676 Summary: Color selector will not update if green and blue values are the same if using color picker Product: krita Version: 4.4.8 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Color Selectors Assignee: krita-bugs-n...@kde.org Reporter: wontoon...@gmail.com Target Milestone: --- Created attachment 141692 --> https://bugs.kde.org/attachment.cgi?id=141692=edit A *.kra file with colors laid out so you can see the bug for yourself. SUMMARY When using the color picker on a specific range of colors, the color selector will remain on its previous hue. An example problem color that will trigger this bug is (208, 26, 26); my testing seems to show that the bug appears if the green and blue values are the same, but not if the green and blue values are the same. Note that I use HSV, but the bug seems to be present within the other ones (HSL, etc). STEPS TO REPRODUCE 1. Place the color on the canvas, with the green and blue values being the same. 2. Select the color from any other color that does . 3. Profit. OBSERVED RESULT What happens is that the hue will shift on the outer ring, but not in the square (and it treats it as the previous hue, so the bug is not visual). Note that I'm using the configuration where you have the ring and the square inside of it, second one in the grid of options that lets you choose the style (values darken toward the bottom half). The bug is visible throughout all settings, however. EXPECTED RESULT The hue should also change in the color selector; in my case, from any color to the red hue. SOFTWARE/OS VERSIONS Windows: Windows 10 macOS: N/A Linux/KDE Plasma: N/A (available in About System) KDE Plasma Version: -- KDE Frameworks Version: -- Qt Version: -- ADDITIONAL INFORMATION Attached a file with the colors in question. Use the color selector to pick a "good color" and then select a "problem color". -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 410324] Delay in brushes and color picker when canvas RAM use is around 450MB and higher.
https://bugs.kde.org/show_bug.cgi?id=410324 Wontoon changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |NOT A BUG --- Comment #3 from Wontoon --- Double-checked by going back to 4.2.1, and it definitely is there. As I've never encountered this before I am going to take a wild guess and say that the setting was not enabled when I updated to the version when it was introduced, but when I updated but when I upgraded to 4.2.3 the setting defaulted back to "on". Either that or I somehow managed to completely dodge it with my more recent images up until now...somehow. Either way, I'll mark this as "not a bug"/"I dun goofed" thanks for your time and I appreciate what you do! -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 410324] Delay in brushes and color picker when canvas RAM use is around 450MB and higher.
https://bugs.kde.org/show_bug.cgi?id=410324 --- Comment #1 from Wontoon --- Update: Turning off Instant Preview seems to remove the delay from the canvas strokes. ...huh, is Instant Preview doing the opposite of what it is supposed to be doing in this case? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 410324] New: Delay in brushes and color picker when canvas RAM use is around 450MB and higher.
https://bugs.kde.org/show_bug.cgi?id=410324 Bug ID: 410324 Summary: Delay in brushes and color picker when canvas RAM use is around 450MB and higher. Product: krita Version: 4.2.3 Platform: MS Windows OS: MS Windows Status: REPORTED Severity: major Priority: NOR Component: OpenGL Canvas Assignee: krita-bugs-n...@kde.org Reporter: wontoon...@gmail.com Target Milestone: --- SUMMARY When the RAM usage of a canvas starts exceeding around 450 MB of use, brushes larger than 100 pixels will begin to have a delay before the stroke appears on the canvas for the first stroke in a series of strokes (once you wait for a couple of seconds after a series of stroke, the delay appears again). The color picker will also consistently have a very noticeable ~2 second delay before it selects the color. STEPS TO REPRODUCE 1. Create a new canvas. 2. Draw on it however you like. Add many layers and increase the size of the canvas, your goal is to use a decently high amount of RAM; 450+ will be your goal. 3. Set your brush size to 100+ px (It's oddly specific, as anything less works as normal). 4. You will begin to see the delay in your strokes and in the color picker. OBSERVED RESULT A delay in strokes in Krita with brushes larger than 100 px and the color picker. EXPECTED RESULT No delay with strokes. SOFTWARE/OS VERSIONS Windows: Windows 10 KDE Frameworks Version: 5 Qt Version: 5.12.4 ADDITIONAL INFORMATION Hardware CPU: Core i7 4770k RAM: 16 GB GPU: GTX 1050 Ti Tablet: Cintiq Pro 16 Canvas info (when I first observed the bug): 4400 x 2600, 8-bit color integer depth, sRGB-elle-V2-srgbtrc.icc color space (default one) Additional Notes: The delay is completely absent when you zoom into the canvas. The delay does not exist in previous versions of Krita that I've used (but I have not used 4.2.2 and upgraded from 4.2.1 to 4.2.3). The delay also seems to be fairly consistent in length in between a test image of 450 MB and one I am working on for someone that is 1008 MB. I tried several steps to resolve my issue (which all didn't), including changing the canvas rendering mode, restarting the system, closing other applications, updating Windows, and restarting the entire computer. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399638] Noticeable lag when drawing
https://bugs.kde.org/show_bug.cgi?id=399638 --- Comment #4 from Wontoon --- So an update to the issue: After closing Firefox because it was being unstable (the whole system was lagging like crazy and I figured that was the cause, and I was right when I closed Firefox), the issue... somehow resolved itself. Reopened it to confirm if Firefox was the issue, but I could not seem to replicate the lag. Huh. (This is even more confusing since I immediately encountered the lag after the restart and it persisted until now. Firefox is still going, and the lag is still absent...) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399638] Noticeable lag when drawing
https://bugs.kde.org/show_bug.cgi?id=399638 --- Comment #3 from Wontoon --- (Sorry for the delay, was worn out from work I didn't even check my messages!) I don't remember ever enabling it (I am assuming "Basic" is the default setting?), but the "Brush Smoothing" is set to "Basic". Setting it to "none" showed some(?) improvement, but the sporadic lag is definitely still there (just not as harsh). I've also noticed that, if your pen is away from the tablet for a while and you try to make a stroke, the first stroke will not appear. Subsequent strokes will appear, though! It is definitely consistent with that, too. I also double-checked the Surface 4 and the Brush Smoothing setting is set to "Basic" as well, and as expected the sporadic lag does not exist on there. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 399638] New: Noticeable lag when drawing
https://bugs.kde.org/show_bug.cgi?id=399638 Bug ID: 399638 Summary: Noticeable lag when drawing Product: krita Version: 4.1.3 Platform: Other OS: MS Windows Status: REPORTED Severity: normal Priority: NOR Component: tablet support Assignee: krita-bugs-n...@kde.org Reporter: wontoon...@gmail.com Target Milestone: --- SUMMARY After the October 2018 update on Windows 10, when drawing with a Cintiq Pro 16 tablet (this may extend to all Wacom tablets; unsure) there is a noticeable delay (around 1 ~ 1.5 seconds) between when the the pen is on the canvas and the stroke appears on the canvas. This appears in both Krita 4.1.1 and 4.1.3, and both tablet input APIs. This seems to be somewhat sporadic, but it definitely happens very, very often. On the Surface 4 Pro, this problem does not exist (I have tested 4.0, got the Cintiq Pro shortly after-- and 4.1.3. I expected 4.1.3 to have the same issue but it is not there, making me conclude that this is possibly isolated to Wacom tablets). STEPS TO REPRODUCE 1. Run Krita after the October 2018 update for Windows 10. 2. Make a line. It may take a few lines. 3. (Optional) Curse at Microsoft at the top of your lungs. OBSERVED RESULT Lag in strokes appearing on screen. EXPECTED RESULT Smooth drawing. SOFTWARE VERSIONS (available in About System) 4.1.1, 4.1.3 KDE Plasma Version: N/A KDE Frameworks Version: N/A Qt Version: 5.9.3 ADDITIONAL INFORMATION OS Information Build ABI: x86_64-little_endian-llp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: winnt Kernel Version: 10.0.17134 Pretty Productname: Windows 10 (10.0) Product Type: windows Product Version: 10 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 366765] Exporting a PSD file onto a network drive causes application hang
https://bugs.kde.org/show_bug.cgi?id=366765 --- Comment #4 from Wontoon <wontoon...@gmail.com> --- So, here are those test results! hardware: Surface 4 Pro (Core i5/4 GB Ram/128 GB SSD) image: edgarref.kra size: 15.4 MB (6100 x 2500) export start: 10:25 AM PDT ...10:31 AM: still exporting... export end: 10:33 AM Result: Holy cow, an 8 minute export time!? The kra save barely goes over 10 seconds. Opening the psd did not take long. image: feeskypokefat.kra size: 17.8 MB (3400 x 2600) export start: 10:56 AM ...11:09 AM: still going... export end: 11:12 AM As a control, I will export on the Desktop as well. This is saving to another laptop on the network; I expect a slower time since it's a laptop with a mechanical drive: hardware: Core i7 4770k 3.5 ghz, 16gb DDR3 RAM, 128 GB SSD (not used, but instead the hard drive is a Western Digital Black 1 TB mechanical drive, SATA) Additional note: I started this while the other export was happening. The CPU itself hardly was being used so I figure the impact would be minimal. edgarref.kra export start: 10:59 AM 11:09 AM...still going export end: 11:12 AM Based upon the above results, it appears that it is indeed not an application hang, but merely a -MASSIVE- performance decrease when a PSD file (and only a PSD file) has to be exported over the network. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 366765] Exporting a PSD file onto a network drive causes application hang
https://bugs.kde.org/show_bug.cgi?id=366765 --- Comment #3 from Wontoon <wontoon...@gmail.com> --- It's my main art folder on my desktop, actually. I am not using a Homegroup (since there was another one on the network already, thus preventing me from making one...oh, WIndows) so I just used the "Properties -> Sharing -> Share" option. Could edit and save images just fine but when I try to export PSD that's when the issue arises. (Well whaddaya know. Just as I was finishing commenting this, I just did one more test with a simple image, a 1600x1200 image with a couple scribbles on it just to confirm the bug with absolute certainty. It hung for a good long minute and I was going to close Krita but it -actually succeeded-. Opens and closes just fine. I am going to run a couple of tests with a couple of images that I know where the issue surfaced. I'll be back with the results.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 366765] New: Exporting a PSD file onto a network drive causes application hang
https://bugs.kde.org/show_bug.cgi?id=366765 Bug ID: 366765 Summary: Exporting a PSD file onto a network drive causes application hang Product: krita Version: 3.0 Platform: MS Windows OS: MS Windows Status: UNCONFIRMED Severity: crash Priority: NOR Component: usability Assignee: krita-bugs-n...@kde.org Reporter: wontoon...@gmail.com When you export an *.PSD file to a drive on a network, Krita will hang. Reproducible: Always Steps to Reproduce: 1. Create image. Any image. Paint, draw, whatever. 2. Export the PSD file via "Export..." 3. Recoil in horror as Krita no longer responds, giving you the infinite circle of doom. Actual Results: Krita becomes unresponsive, have to terminate the program. PSD file is nor exported, and creates a corrupted PSD file. This also can be reproduced in 2.9. Expected Results: An exported PSD file, ready to go. This is done on a Windows 10 machine (surface 4 pro) with a mapped network folder. A workaround is to export the PSD file onto a local drive and copy that file to the network drive; the PSD export works completely fine when exporting to the local drive. -- You are receiving this mail because: You are watching all bug changes.
