[krita] [Bug 488647] New: Internal error/crash when setting palette columns to 0
https://bugs.kde.org/show_bug.cgi?id=488647 Bug ID: 488647 Summary: Internal error/crash when setting palette columns to 0 Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Manjaro OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: General Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- SUMMARY Editing the palette swatch columns to 0 (which I did accidentally when it happened), will result in an error message and an unexpected quit if one of the choices is picked. STEPS TO REPRODUCE 1. Open any palette in the palette docker and click the "Edit current palette" button at the bottom. 2. Change the number of "Columns of swatches" to 0 and click OK. OBSERVED RESULT You will see the following error message. Clicking "Abort" or the "X" window close button results in the program closing/crashing/unexpectedly quitting. Choosing "Ignore" may allow you to continue. After ignoring, I did not encounter the error on the same palette, but doing it again with another palette produced the same error. """ Krita has encountered an internal error: SAFE ASSERT (krita): "columnCount >= 1" in file /builds/graphics/krita/libs/pigment/resources/KisSwatchGroup.cpp, line 104 Please report a bug to developers! Press Ignore to try to continue. Press Abort to see developers information (all unsaved data will be lost) """ EXPECTED RESULT I would expect it to either fail a bit more gracefully or simply not allow 0 as an input value. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro Linux Kernel: 6.8.12-3-MANJARO x86_64 ADDITIONAL INFORMATION Krita Version: 5.3.0-prealpha (git 7fb0cda), Qt version compiled: 5.15.7, loaded: 5.15.7. Process ID: 136519 Krita Version: 5.3.0-prealpha (git d9c69b6) Hidpi: false Qt Version (compiled): 5.15.7 Version (loaded): 5.15.7 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 6.8.12-3-MANJARO Pretty Productname: Manjaro Linux Product Type: manjaro Product Version: unknown Desktop: XFCE Appimage build: Yes -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 475819] New: Node.setVisible() doesn't refresh like manually clicking the eyeball icon on each layer does
https://bugs.kde.org/show_bug.cgi?id=475819
Bug ID: 475819
Summary: Node.setVisible() doesn't refresh like manually
clicking the eyeball icon on each layer does
Classification: Applications
Product: krita
Version: 5.2.0
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Scripting
Assignee: krita-bugs-n...@kde.org
Reporter: chirn...@hotmail.com
Target Milestone: ---
Created attachment 162416
--> https://bugs.kde.org/attachment.cgi?id=162416=edit
A .kra file with 3 groups of layers. Run the above script on it in Scripter.
SUMMARY
My plugin has a function where it loops through the layer stack and sets
setCollapsed(True) and setVisible(False) on everything, and then uses several
buttons to focus a particular group with setCollapsed(False) and
setVisible(True). This works pretty well in and of itself, but I've run into an
issue where using setVisible() in Python doesn't redraw the canvas when
switching layer groups, which means it hangs onto old data. Now, you may be
saying "use Document.refreshProjection()," which is what I was doing before.
However, this works OK on a 1024x1024 document, is fairly annoying at 2K, and
is brain meltingly slow at 4K and above (as in, from "several" to "dozens" of
minutes to rebuild depending on resolution and content), so I've stopped using
it unless absolutely necessary. Here's what actually does work to force a quick
redraw: manually toggling the eye icon on the group off and on, and strangely,
adding a deactivated clone layer with no source specified to the bottom of the
group. The second of these is what I'm currently doing as I can add the clone
layer programmatically and it does redraw the canvas fast enough to be useful,
but it's an ugly, ugly hack and adding extra layers eats into the video ram
usage. If Node.setVisible() worked like manually clicking on the eye icon, I
could potentially switch the group off and on again to redraw the canvas at a
reasonable speed.
STEPS TO REPRODUCE
1. Open attached .kra file and run below script multiple times.
2. It should toggle through the groups.
3. Going from group G1 to G2 likely won't redraw the canvas properly, and then
going from group G2 to G3 will redraw successfully every time because I added a
deactivated clone layer there to illustrate the point.
4. Going from G3 back to G1 (group with a clone layer back to a group without
one) may or may not work every time.
5. Clicking manually on the eye icon of groups G1 and G2 will also redraw the
canvas, but just running the script a few times on the same groups will not do
so.
Test code:
from krita import Krita
doc = Krita.instance().activeDocument()
root = doc.rootNode()
children = root.childNodes()
def collapseAndDeactivate():
for child in children:
child.setVisible(False)
child.setCollapsed(True)
def toggleNode():
collapseAndDeactivate()
newActive = doc.activeNode()
if newActive.name() == "G1":
newActive = doc.nodeByName("G2")
elif newActive.name() == "G2":
newActive = doc.nodeByName("G3")
elif newActive.name() == "G3":
newActive = doc.nodeByName("G1")
else:
newActive = doc.nodeByName("G1")
newActive.setVisible(True)
newActive.setCollapsed(False)
doc.setActiveNode(newActive)
collapseAndDeactivate()
toggleNode()
OBSERVED RESULT
There's clearly some extra magic going on in the clone layer and visibility
button code that I'm not able to access through Python (I tried looking at the
C++ source and also got deep into Qt but I'm not seeing anything super
relevant, or it seems relevant but doesn't actually work). I don't want to
refresh the entire document's projection, I just need whatever's currently
visible.
EXPECTED RESULT
Either Node.setVisible() forces the same canvas refresh that manually clicking
the eye icon does or there's a dedicated function that redraws just whatever is
currently visible without doing a full Document.refreshProjection(), which
isn't really usable past 1-2K.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 475456] New: Reading and writing pixelData from/to node channels doesn't work properly
https://bugs.kde.org/show_bug.cgi?id=475456
Bug ID: 475456
Summary: Reading and writing pixelData from/to node channels
doesn't work properly
Classification: Applications
Product: krita
Version: 5.2.0
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Scripting
Assignee: krita-bugs-n...@kde.org
Reporter: chirn...@hotmail.com
Target Milestone: ---
Created attachment 162210
--> https://bugs.kde.org/attachment.cgi?id=162210=edit
test krita file
5.2.0-rc1 Appimage
SUMMARY
Reading the pixelData for the RGBA channels of a node (and printing the output)
doesn't seem correct. There is a very slight something in the byte array but
it's very nearly all zeros, and copying that channel pixelData to the channel
of a new node doesn't produce anything useful. I'm able to use the full node
pixelData or projectionPixelData just fine (this is how I'm exporting maps in
my plugin currently), but reading/writing channels pixelData seems broken. It
doesn't produce any errors, it just doesn't work. I may be doing something
wrong (am I?), but I would assume copying from the channel of one node into the
channel of another node should be possible, right? For context, I'm trying to
pack three grayscale (but RGBA color space) textures into the channels of a
single node (ambient occlusion, roughness, metallic, i.e. ORM), but I haven't
gotten that far because being able to read/write channel data is the first step
and I'm blocked here.
STEPS TO REPRODUCE
Copy the following script and run it in scripter while the "pixels" layer of
the attached .kra file is selected.
from krita import Krita
from PyQt5.QtCore import QByteArray, QRect
KI = Krita.instance()
doc = KI.activeDocument()
activeNode = doc.activeNode()
root = doc.rootNode()
fullPixels = QByteArray()
rChannel = QByteArray()
gChannel = QByteArray()
bChannel = QByteArray()
aChannel = QByteArray()
xDocSize = 3
yDocSize = 1
rect = QRect(0, 0, xDocSize, yDocSize)
print("\nOriginal node pixel data")
fullPixels = activeNode.pixelData(0, 0, xDocSize, yDocSize)
print(fullPixels)
print("\n" + activeNode.channels()[2].name())
rChannel = activeNode.channels()[2].pixelData(rect)
print(rChannel)
print("\n" + activeNode.channels()[1].name())
gChannel = activeNode.channels()[1].pixelData(rect)
print(gChannel)
print("\n" + activeNode.channels()[0].name())
bChannel = activeNode.channels()[0].pixelData(rect)
print(bChannel)
print("\n" + activeNode.channels()[3].name())
aChannel = activeNode.channels()[3].pixelData(rect)
print(aChannel)
newNode = doc.createNode("channels copy (doesnt work)", 'paintlayer')
newNode.channels()[2].setPixelData(rChannel, rect)
newNode.channels()[1].setPixelData(gChannel, rect)
newNode.channels()[0].setPixelData(bChannel, rect)
newNode.channels()[3].setPixelData(aChannel, rect)
print("\nOriginal channels copied into new node channels")
print(newNode.pixelData(0, 0, xDocSize, yDocSize))
fullCopy = doc.createNode("full copy (works)", 'paintlayer')
fullCopy.setPixelData(fullPixels, 0, 0, xDocSize, yDocSize)
print("\nFull copy of original pixel data into new node")
print(fullCopy.pixelData(0, 0, xDocSize, yDocSize))
root.addChildNode(newNode, None)
root.addChildNode(fullCopy, None)
OBSERVED RESULT
1. It should be clear from the script output that the pixelData for the entire
layer seems normal and can be copied to another node properly. A new node will
be added to the stack with an exact copy of the pixels.
2. It should also be clear that doing the same thing for the individual
channels doesn't produce the desired result. The printed QByteArray output
seems wrong, and recomposing a node using the copied channel pixelData produces
an empty layer in the stack.
EXPECTED RESULT
I would expect to be able to read the pixelData of each channel in a node and
copy it to a channel in a new node, thereby reconstituting an exact copy of the
original node, or swapping channels around. I would also expect to be able to
copy the full pixelData from, say, three different nodes and pack those into
the individual channels of a new node.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 473429] New start screen in 5.2 Beta adds extra steps to docker plugins that create a new project
https://bugs.kde.org/show_bug.cgi?id=473429
--- Comment #1 from varkatope ---
(In reply to varkatope from comment #0)
> Or a section on the
> start screen that is addressable from Python, where you can register a
> widget (even just a single button would be enough to launch a new project
> creation window). Or, something like Maya's custom "shelf" where you can pin
> scripts to it, which would be part of the standard UI and therefore
> persistent (like the new document, open existing document, save, etc.
> section at the top left). I dunno, I'm just spitballing now.
Well, I managed to add a new QToolBar and QToolButton to the main window from
within my docker plugin, which would do the trick, but that took some doing
because on first load, the qwindow() doesn't exist yet and will throw an error
unless you use a Notifier for windowCreated. Then I wanted to only have it
appear on the start screen since once the Docker is loaded I can just go from
there, but then if I started a few new projects I would end up with multiple
QToolButtons in the tool bar, so I had to start and stop Notifiers for
imageCreated and imageClosed to activate and deactivate the tool bar depending
on what was open or closed, which still isn't working quite right but at least
I only have one QToolButton at any one time, and it didn't look right so I had
to use addAction instead of addWidget and then
setStyleSheet('QToolBar{border:none}') and it finally looks OK, BUT THEN I
managed to insert a tool button into the "Start" area and that presented its
own set of challenges, plus it could break at any time if y'all decide to
rename 'verticalLayout_4', for example, but at least I don't have to mess with
the other Notifiers, so that's probably what I'm going to stick with for the
moment and hope it doesn't break in future versions...
My point is that it would be cool to have some sort of helper function in
Krita's API for plugin developers that would simplify adding either a tool bar
to the qwindow() or tool button to the welcome page now that there is one (or
both!), and to inherit the style of the existing UI by default (no border if
QToolBar, or setAutoRaise(True), QSize(48,48), setToolButtonStyle(3) if
QToolButton, that sort of thing), because I'm pretty "in the weeds" on the Qt
side at the moment and it stings a bit.
Sorry for the non-"bugreportyness" of this "bug report." Do with it what you
will.
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 473429] New: New start screen in 5.2 Beta adds extra steps to docker plugins that create a new project
https://bugs.kde.org/show_bug.cgi?id=473429 Bug ID: 473429 Summary: New start screen in 5.2 Beta adds extra steps to docker plugins that create a new project Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Dockers Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- Krita 5.2.0-beta1 The new reorganized start screen (with the donation banner at the top and deactivated dockers section) has added extra steps for the docker plugin I'm writing. The plugin allows you to create a new Krita project and sets some settings like the color model, profile, bit-depth, along with creating a whole layer/filter stack. It's opinionated due to purpose: creating normal maps and other PBR maps for realtime engines. So, it won't let you even choose the CMYK model or one of the float bit depths (because the height to normal filter doesn't work with those at all), for instance. In previous Krita versions, the docker plugin would be available from the start screen and you could start a new project from there, but with the new start screen, you have to create a new image first, and only then can you create a new project from my docker plugin. This also means you now have two documents open by default: the blank one and the one you actually want to work on. Not sure what the solution is, but is there any way to add functionality to set a property on a docker that will show it on the start screen? I assume the new start screen is just looping through dockers and hiding everything, and then unhiding when a document is created, because it's possible to unhide it manually from the start screen, but that setting is not persistent. Actually, unhiding only works on startup, not if you've closed a document and end up back on the start screen. Interesting. Anyway, just adding an if check to that hiding/unhiding function for a certain visibility property on the docker would seem like a solution, right? Alternately, I guess I could create a separate extension that would be available from the Tools > Scripts menu whose sole purpose is to create a new project, but that's pretty janky and not at all discoverable, on top of asking people to install and activate two plugins... Or a section on the start screen that is addressable from Python, where you can register a widget (even just a single button would be enough to launch a new project creation window). Or, something like Maya's custom "shelf" where you can pin scripts to it, which would be part of the standard UI and therefore persistent (like the new document, open existing document, save, etc. section at the top left). I dunno, I'm just spitballing now. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 472343] Levels filter layer properties set in Python have no effect on that filter layer
https://bugs.kde.org/show_bug.cgi?id=472343 --- Comment #8 from varkatope --- (In reply to Deif Lou from comment #7) > If you have the crash in the nightly that will have my changes then it will > need a new bug report, but it will have to provide the steps to reproduce > the issue and maybe the script you use (or a simplified version that also > provokes the crash) to debug. The safe asserts appear also in the nightly > that doesn't have my changes so the issue may be other. Alright, I'll see if it crops up in the next build with your changes. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 472343] Levels filter layer properties set in Python have no effect on that filter layer
https://bugs.kde.org/show_bug.cgi?id=472343 --- Comment #6 from varkatope --- (In reply to Deif Lou from comment #4) > Hi. Can you tell when this happens? For some specific type of layer or the > like? I think that may be some unrelated bug to this and may need another > bug report. Hi again. Unfortunately I can`t really tell at what point I`m getting that error in your build. If I just start a new project and start adding layers, filers, etc. I can`t recreate it. Only when my plugin adds a bunch of stuff in quick succession, makes groups, locks layers, selects stuff by name... I don`t know. The new nightly (529349f) seems to work fine for me and I thnk that includes changes to "flake" specifically as in here: https://binary-factory.kde.org/job/Krita_Nightly_Appimage_Build/2072/changes Here are a few logs but not sure they`re super helpful. Let me know if you think I should do a separate bug report on this, though. Thanks. Your build: SESSION: 19 Jul 2023 14:48:16 -0400. Executing /tmp/.mount_krita-mmfdXP/usr/bin/krita Krita Version: 5.2.0-prealpha (git f742174), Qt version compiled: 5.15.7, loaded: 5.15.7. Process ID: 33666 -- -- -- -- -- -- -- -- 19 Jul 2023 14:48:16 -0400: Style: fusion. Available styles: Windows, Fusion 19 Jul 2023 14:48:18 -0400: Database is up to date. Version: 0.0.17, created by Krita 5.1.0, at Wed. Sep. 7 22:50:11 2022 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/normals_tools_library.asl 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/normals.tag 19 Jul 2023 14:48:18 -0400: Could not load resource layerstyles/small_recessed_grille.asl 19 Jul 2023 14:48:24 -0400: KisAppimageUpdater: update check finished. Result: 2 Exit status: 0 path: /home/myname/Desktop/Krita_levels/krita-5.2.0-prealpha-f742174ed7-x86_64.appimage output: 19 Jul 2023 14:48:31 -0400: Created image "Project Name", 1024 * 1024 pixels, 300 dpi. Color model: 16-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1 19 Jul 2023 14:48:33 -0400: SAFE ASSERT (krita): "dummy" in file /builds/graphics/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 KRITA DID NOT CLOSE CORRECTLY The new nightly (which doesn`t include your changes yet): SESSION: 19 Jul 2023 15:07:30 -0400. Executing /tmp/.mount_krita-eAhhMB/usr/bin/krita Krita Version: 5.2.0-prealpha (git 529349f), Qt version compiled: 5.15.7, loaded: 5.15.7. Process ID: 34157 -- -- -- -- -- -- -- -- 19 Jul 2023 15:07:30 -0400: Style: fusion. Available styles: Windows, Fusion 19 Jul 2023 15:07:32 -0400: Database is up to date. Version: 0.0.17, created by Krita 5.1.0, at Wed. Sep. 7 22:50:11 2022 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/normals_tools_library.asl 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/normals.tag 19 Jul 2023 15:07:32 -0400: Could not load resource layerstyles/small_recessed_grille.asl 19 Jul 2023 15:07:37 -0400: KisAppimageUpdater: update check finished. Result: 0 Exit status: 0 path: /home/myname/Downloads/krita-5.2.0-prealpha-529349f772-x86_64.appimage output: 19 Jul 2023 15:07:45 -0400: Created image "Project Name", 1024 * 1024 pixels, 300 dpi. Color model: 16-bit integer/channel RGB/Alpha (sRGB-elle-V2-srgbtrc.icc). Layers: 1 19 Jul 2023 15:07:46 -0400: SAFE ASSERT (krita): "dummy" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 19 Jul 2023 15:07:46 -0400: SAFE ASSERT (krita): "dummy" in file /home/appimage/workspace/Krita_Nightly_Appimage_Build/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 472343] Levels filter layer properties set in Python have no effect on that filter layer
https://bugs.kde.org/show_bug.cgi?id=472343 --- Comment #3 from varkatope --- (In reply to Deif Lou from comment #2) Hello Deif. That's brilliant! Thanks for such a quick fix. I wasn't expecting that but certainly do appreciate your work. I was able to set all the properties as you laid out, including the legacy ones (blackvalue, etc.), so this certainly fixes the issue on my end. I did encounter a few errors (see below) when starting my plugin with your build, which doesn't happen with the nightly I was using. The plugin creates a bunch of layers, filters, and filter layers and I encountered the same error three times during that process. Of course, this may be an "in development" situation elsewhere in the build. Reporting it here anyway, just in case. I was able to ignore them regardless. Cheers! ** Krita has encountered an internal error: SAFE ASSERT (krita): "dummy" in file /builds/graphics/krita/libs/ui/flake/kis_dummies_facade_base.cpp, line 120 Please report a bug to developers! Error: Press Ignore to try to continue. Press Abort to see developers information (all unsaved data will be lost) ** -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 472343] New: Levels filter layer properties set in Python have no effect on that filter layer
https://bugs.kde.org/show_bug.cgi?id=472343
Bug ID: 472343
Summary: Levels filter layer properties set in Python have no
effect on that filter layer
Classification: Applications
Product: krita
Version: nightly build (please specify the git hash!)
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Filter Layers
Assignee: krita-bugs-n...@kde.org
Reporter: chirn...@hotmail.com
Target Milestone: ---
"Levels" filter layer can be created and added to the stack using the Python
API but setting its properties programmatically has no effect on the filter
layer. Setting properties on other filter layers works fine. This may be a case
where it's just not implemented in the API yet, but regardless it's a roadblock
for me.
For example, I can add the filter layer manually and try to affect it through
Scripter by entering something like:
Krita.instance().activeDocument().activeNode().filter().configuration().setProperty('gammavalue',
0.452)
Krita.instance().activeDocument().refreshProjection()
I can query that value with:
print(Krita.instance().activeDocument().activeNode().filter().configuration().properties())
This will spit out something like {'gammavalue': 0.452} plus any other property
I've tried to set, but none of that has any effect on the filter layer itself.
I'm able to do similar operations with other filter layers just fine.
The reason I would need to do this is that I'm writing a plugin for working
with normal maps, and it's better to be able to work in 16-bit and only export
to 8-bit if need be. Other than missing proper dithering (which I'm faking),
this is fairly possible by setting a few properties in the png exporter (namely
Embed sRGB profile, Force convert to sRGB, and Force convert to 8
bits/channel), but the color representation will obviously be off from 16-bit >
8-bit, so the simplest way to fix that beforehand is to add a Levels filter
layer at the top of the stack and change the gamma value to 0.452. It's not a
great experience to ask a user of my plugin to change that value manually on
every project, so ideally that would be taken care of by the plugin.
Aaaand I just realized I could start up a project with the gamma corrected
sRGB-elle-V2-srgbtrc profile instead...hmmm...which might work...but then
becomes a problem if I actually want to export in 16-bit linear...so the
problem remains.
Even just being able to set the "mode" to "channels" and change "gammavalue"
would solve my issue with the Levels filter layer at the moment.
Krita
Version: 5.2.0-prealpha (git 508d078) [and previous versions]
Hidpi: false
Qt
Version (compiled): 5.15.7
Version (loaded): 5.15.7
OS Information
Build ABI: x86_64-little_endian-lp64
Build CPU: x86_64
CPU: x86_64
Kernel Type: linux
Kernel Version: 6.4.2-3-MANJARO
Pretty Productname: Manjaro Linux
Product Type: manjaro
Product Version: unknown
Desktop: XFCE
Appimage build: Yes
--
You are receiving this mail because:
You are watching all bug changes.
[krita] [Bug 467933] New: Implement dithering for gradient fills applied to vector shapes
https://bugs.kde.org/show_bug.cgi?id=467933 Bug ID: 467933 Summary: Implement dithering for gradient fills applied to vector shapes Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Appimage OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: Tools/Vector Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- Krita Version: 5.2.0-prealpha (git 4ee6458) I couldn't find a bug report/wish for this, so: When applying a gradient fill to a vector shape in the tool options, there's no toggle for applying dithering to it as well like there is when applying a gradient on a raster layer or when applying a gradient overlay on either raster or vector layers. Also, I can create vector shapes through code and change some attributes (by abusing some string manipulation in the SVG), but if dithering becomes an option when being applied to vector shapes, it would be nice to also have an easy way to toggle the dithering through code as well. I know (I think?) it's not part of the SVG spec or at least not how it's being used in Krita, but some sort of property I can set would be cool. Not to mention having API access to all those tool options, but that's a different conversation. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 467731] New: Expose key="Ofst" ASL parameter of gradient overlay layer style to editor
https://bugs.kde.org/show_bug.cgi?id=467731 Bug ID: 467731 Summary: Expose key="Ofst" ASL parameter of gradient overlay layer style to editor Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Manjaro OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- SUMMARY Version: 5.2.0-prealpha (git a39b4d5) SUMMARY There's no option to edit the following gradient overlay ASL in the layer styles editor: This doesn't really work properly with wrap-around mode, but it could still be useful within the image bounds. I can set it through code, but it would be nice for the built-in layer style editor to have as well. It would be even nicer if it also worked correctly with wrap-around mode (instead of cutting off at the single image bounds), of course. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 467729] New: Opening Layer Styles editor resets gradient overlay colors if 0. Foreground to Background is selected and document hasn't been saved/closed/reopened.
https://bugs.kde.org/show_bug.cgi?id=467729 Bug ID: 467729 Summary: Opening Layer Styles editor resets gradient overlay colors if 0. Foreground to Background is selected and document hasn't been saved/closed/reopened. Classification: Applications Product: krita Version: nightly build (please specify the git hash!) Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- 5.2.0-prealpha (git a39b4d5). This also happens in 5.1.5. SUMMARY If a gradient overlay layer style is applied to a layer using the 0. Foreground to Background gradient, later changing the current foreground or background color and then reopening the layer styles editor on the same layer will automatically update the applied gradient to whatever the current foreground and background colors are set to. This is undesired behaviour as making any change to the layer style later (after having worked on other parts of the image and having changed the selected colors since) will force you to exit the layer style editor, set the current colors properly, open the style editor, and then re-edit the applied gradient overlay once again before making additional changes (like adding another layer style or just modifying the current one). Now, it seems that when the file is saved and Krita is closed and then reopened, one notices that a static copy of the 0. Foreground to Background gradient has been created and applied, thereby avoiding this problem, which is great! However, I feel like this same behavior should be performed when the file is still in memory and being worked on (ideally when the gradient is first selected or at least when the layer style editor is closed) as right now if you keep working on the file without closing and reopening it first, the above undesired behavior is encountered. The question becomes why not create another gradient selection and edit the stops manually? But having a gradient option that automatically picks the current colors is powerful workflow-wise (and is kind of necessary for some functionality I'm building), it's just that it shouldn't change arbitrarily while one is performing other reasonable actions elsewhere. The desired behaviour does exist already, but only when the file is saved, closed, and then reopened. On a different note, several workflow-breaking bugs were fixed in layer styles recently (align with layer, not remembering other settings, etc.) so thanks to those who worked to fix these issues! STEPS TO REPRODUCE 1. Draw something and apply gradient overlay layer style to layer using the 0. Foreground to Background gradient. Make sure it's visible on the canvas. Close the layer style editor. Make sure nothing is actually selected on the canvas. 2. Change the current foreground and background colors to something drastic and visible. 3. Reopen the layer styles editor on the same layer. OBSERVED RESULT The gradient overlay on the image is automatically updated with the newly selected fore/back colors. You don't actually have to be on the gradient overlay page in the layer style editor for that to happen. EXPECTED RESULT The desired behavior of automatically creating a static copy of the gradient and applying that one until the user chooses otherwise only happens when the file is saved, closed, and reopened, but should be applied to the live working document as well (if possible), ideally right away when the 0.Foreground to Background gradient is selected, or at least when the layer style editor is closed. SOFTWARE/OS VERSIONS Manjaro Linux, all up to date. Using a nightly AppImage build. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 461801] New: Several layer styles don't tile properly when used with vector shapes in wraparound mode
https://bugs.kde.org/show_bug.cgi?id=461801 Bug ID: 461801 Summary: Several layer styles don't tile properly when used with vector shapes in wraparound mode Classification: Applications Product: krita Version: 5.1.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: layer styles Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- Created attachment 153729 --> https://bugs.kde.org/attachment.cgi?id=153729=edit Krita file that illustrates the problem. Turn on wrap-around mode to see. SUMMARY *** Not sure how fixable this is, but using most layer styles with vector shapes in wraparound mode produces artifacts at the image bounds. I guess it's not exactly an artifact and more that the layer style's effect terminates at the image bounds, but the result is that it doesn't tile properly in any case. *** STEPS TO REPRODUCE 1. Create a new square image. 2. Turn on wraparound mode. 3. Create a raster shape that extends past the edges of the original image size so that it's perfectly wrapping around. 4. Do the same with a vector shape, either to the image bounds or past it. 5. Apply the same layer style to both: This seems to manifest with outer glow, inner glow, bevel and emboss, drop shadow, possibly others. OBSERVED RESULT The vector shape with the layer style applied will exhibit artifacts at the edges of the original image bounds, whereas the raster shape will wrap around perfectly with the layer style applied. EXPECTED RESULT I would expect the two shapes to look the same when wrapping around. This does work in Photoshop, but I don't know the technical of that. PS seems to calculate the layer style differently when the object touches the image bounds. Strangely, if I drag around the raster layer (with the same layer style applied) over the vector area where the artifacts occur, then move it back to where it was and redraw the canvas manually (from script or the plugin I'm writing), the artifacts on the vector layer go away. I can even then export the image without artifacts if I do this. However, if I hide the vector layer and bring it back, the artifacts reappear. Not sure if that means it's just a rendering bug then, but it is weird that this works even temporarily. I did have some issues with more serious drawing artifacts getting baked into the image at the layer bounds, even when redrawing the canvas, but I deactivated "Use texture buffer" (I'm on Radeon mobile) and that seems to have at least fixed the "getting baked into the image" part. I still see artifacts, but redrawing the canvas or hiding/unhiding the layer now fixes that. Doesn't fix this tiling vector layer with layer styles issue, though. I also tried deactivating rendering acceleration altogether just in case, but that doesn't solve this issue (you can't use wrap around mode, but the issue is still evident at the edges). SOFTWARE/OS VERSIONS Manjaro Linux 22.0.0 all up to date XFCE 4.16 AMD Ryzen 5 2500U Device-1: AMD Raven Ridge [Radeon Vega Series / Radeon Mobile Series] driver: amdgpu v: kernel API: OpenGL v: 4.6 Mesa 22.2.1 renderer: AMD Radeon Vega 8 Graphics (raven LLVM 14.0.6 DRM 3.48 6.0.6-1-MANJARO) ADDITIONAL INFORMATION The plugin I'm writing is to streamline normal map creation (using the height to normal filter layer) for making tiling normal maps (for trim sheets and the like) for game engines and DCC programs, and ideally, I'd be able to offer a workflow that involves creating complex vector shapes using boolean operations and then applying layer styles to create effects like beveled edges and gradients, and have them tile properly across image boundaries. It all works fairly well with raster layers, and vector shapes as long as they don't extend past the image bounds, but I'd like to also be able to use vectors in a tiling way since cutting up raster layers is more destructive/less editable. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456194] Align with Layer checkbox in Gradient Overlay deactivates itself when Layer Style is accessed again
https://bugs.kde.org/show_bug.cgi?id=456194 varkatope changed: What|Removed |Added Component|Filter Layers |layer styles --- Comment #1 from varkatope --- Mistakenly reported this under Filter Layers, but it's a layer style bug. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 456194] New: Align with Layer checkbox in Gradient Overlay deactivates itself when Layer Style is accessed again
https://bugs.kde.org/show_bug.cgi?id=456194 Bug ID: 456194 Summary: Align with Layer checkbox in Gradient Overlay deactivates itself when Layer Style is accessed again Product: krita Version: 5.0.6 Platform: Other OS: Microsoft Windows Status: REPORTED Severity: normal Priority: NOR Component: Filter Layers Assignee: krita-bugs-n...@kde.org Reporter: chirn...@hotmail.com Target Milestone: --- Created attachment 150312 --> https://bugs.kde.org/attachment.cgi?id=150312=edit Minimum reproduction .kra with one broken layer and one working layer SUMMARY Align with Layer checkbox in Gradient Overlay layer style unchecks itself and deactivates the option when Layer Styles is accessed again, and SOMETIMES (I know programmers love this word), this leads to the checkbox not being checkable again. STEPS TO REPRODUCE 1. Create new project and add either a paint or vector layer. 2. Draw a shape. 3. Add a layer style to this layer and check Gradient overlay. Make sure a gradient is visible on the shape by adjusting scale and opacity. 4. Check Align with Layer and hit OK. 5. Move the shape around with the Move tool. The gradient should follow the shape. 6. Access the Layer Style properties again and go to Gradient Overlay (it would also be nice if the window opened back up on the last style you had open, by the way). OBSERVED RESULT Align with Layer should now be unchecked. Usually it can be checked again, but sometimes it stops being checkable, either after loading the file again, or just randomly after performing some other actions, not sure. In which case the gradient is also no longer tied to the shape and moving the shape no longer moves the layer style. The uncheckable problem seems kind of random, but the Align with Layer definitely deactivates itself every time. EXPECTED RESULT The Align with Layer checkbox should stay checked, and should also not stop being checkable. SOFTWARE/OS VERSIONS Windows: 10 Home, 21H2 (up to date) ADDITIONAL INFORMATION Using 5.0.6 on Windows, but also tried the 5.1.0 beta also on Windows, and 5.0.8 on Manjaro Linux. 5.1.0 did fix a crash I was having with the layer styles, but the above problem remains. -- You are receiving this mail because: You are watching all bug changes.
