[gwenview] [Bug 417830] if using graphic tablet stylus on gwenview is can't move on image window with zoom or 100%
https://bugs.kde.org/show_bug.cgi?id=417830 iszotic changed: What|Removed |Added CC||iszo...@gmail.com --- Comment #1 from iszotic --- It also doesn't work for grabbing the handles when you crop an image -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407921] LUT management with defined OCIO doesn't work on Linux
https://bugs.kde.org/show_bug.cgi?id=407921 --- Comment #4 from iszotic --- (In reply to wolthera from comment #3) > boud, can I ask you to doublecheck you're running Krita with LC_ALL=C ? OCIO > has a huge issue with locale stuff. > > https://docs.krita.org/en/reference_manual/dockers/lut_management.html > > Because it works here on 220be8f with all of the ocio configs I have here. >_<, it was that and changing the image's color profile works too... in linux >krita could show a warning in console when OCIO is used, just saying -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407921] LUT management with defined OCIO doesn't work on Linux
https://bugs.kde.org/show_bug.cgi?id=407921 --- Comment #1 from iszotic --- Doing more testing, converting to different color profiles icc doesn't work either in linux, :( only on windows... -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407921] New: LUT management with defined OCIO doesn't work on Linux
https://bugs.kde.org/show_bug.cgi?id=407921 Bug ID: 407921 Summary: LUT management with defined OCIO doesn't work on Linux Product: krita Version: 4.2.0-beta Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: HDR Assignee: krita-bugs-n...@kde.org Reporter: iszo...@gmail.com Target Milestone: --- SUMMARY Blender OCIO doesn't work with Linux, I tried with Windows 10 and it's working as expected, when you change the settings in linux it throws this error in the console Error The specified transform file '/home/voltam/Downloads/blender-2.79b-linux-glibc219-x86_64/2.79/datafiles/colormanagement/luts/srgb_inv.spi1d' could not be loaded. Invalid 'From' Tag sending event 3 to object qt_scrollarea_viewport I tried with blender 2.80's OCIO file and the same happens STEPS TO REPRODUCE 1. Open an OpenEXR file made with blender 2. Enable OpenColorIO, set color engine to OCIO, set the configuration to blender's OCIO, in blender's installation folder. 3. To get a standard color, set input ColorSpace to Linear, Display device to sRGB, view to default and look to none, this works in windows but in linux not. OBSERVED RESULT A defined OCIO is not working in linux EXPECTED RESULT Change the color from linear gamma to corrected gamma (without setting the gamma in the LUT docker) in linux. Krita Version: 4.2.0-beta Languages: en_US Hidpi: true Qt Version (compiled): 5.9.5 Version (loaded): 5.9.5 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-50-generic Pretty Productname: Ubuntu 18.04.2 LTS Product Type: ubuntu Product Version: 18.04 Hardware Information GPU Acceleration: auto Memory: 32164 Mb Number of Cores: 16 Swap Location: /tmp OpenGL Info Vendor: "X.Org" Renderer: "Radeon RX Vega (VEGA10, DRM 3.31.0, 4.15.0-50-generic, LLVM 9.0.0)" Version: "4.5 (Compatibility Profile) Mesa 19.1.0-devel - padoka PPA" Shading language: "4.50" Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format:QSurfaceFormat(version 4.5, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Version: 4.5 Supports deprecated functions true is OpenGL ES: false QPA OpenGL Detection Info supportsDesktopGL: true supportsOpenGLES: true isQtPreferOpenGLES: false == log == Supported renderers: QFlags(0x2|0x4) Surface format preference list: * QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGL) * QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGLES) Probing format... QSurfaceFormat::RenderableType(OpenGL) Found format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) QSurfaceFormat::RenderableType(OpenGL) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407850] Open EXR 16-bit float images conflicts with gamma correction of 8-bit integer png images
https://bugs.kde.org/show_bug.cgi?id=407850 iszotic changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from iszotic --- (In reply to Boudewijn Rempt from comment #5) > What you're doing is mixing two different colorspaces in one image, so you > will need to either generate proper linear gamma exr files (so you don't > need to fake a 2.2 gamma with the lut docker, or you will need to convert > the PNG images to linear gamma before importing them. > > Krita 4.2 is actually more correct here than Krita 4.1 was. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407850] Open EXR 16-bit float images conflicts with gamma correction of 8-bit integer png images
https://bugs.kde.org/show_bug.cgi?id=407850 --- Comment #3 from iszotic --- The steps: 1) Open an OpenEXR image 2) It's pretty dark because it uses linear Gamma, then go to lut manager, use OpenColorIO, then color engine OCIO(enviroment), now set a standard gamma value of 2.2 3) Open a PNG file 4) PNG layer it's too white A workaround is to use the color adjustment curves on the PNG layers or set lut manager to a value of gamma 1.0 but then the OpenEXR layers get too dark and the PNG layers fine. PD: 4.17 doesn't have this issue. The OpenEXR layers are created in blender, with blender set with the default color manager instead of filmic and this used to show the same colors in blender and krita, now they don't, but I'm not concerned about using the lut manager but about PNG images that load with different lighting -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407850] Open EXR 16-bit float images conflicts with gamma correction of 8-bit integer png images
https://bugs.kde.org/show_bug.cgi?id=407850 --- Comment #1 from iszotic --- PD: This is the bug where is discussed the lut manager bug 406939, srry -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 407850] New: Open EXR 16-bit float images conflicts with gamma correction of 8-bit integer png images
https://bugs.kde.org/show_bug.cgi?id=407850 Bug ID: 407850 Summary: Open EXR 16-bit float images conflicts with gamma correction of 8-bit integer png images Product: krita Version: 4.2.0-alpha Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: iszo...@gmail.com Target Milestone: --- SUMMARY Recently float images are loaded with linear gamma because the gamma has to be handled with the lut manager,bug 288725, but now if you try to use integer images with float images they have mismatched gamma, because png are not loaded with linear gamma too OBSERVED RESULT when the float images have a usual 2.2 gamma value in the lut manager then png,jpg images are too white Krita Version: 4.2.0-beta Languages: en_US Hidpi: true Qt Version (compiled): 5.9.5 Version (loaded): 5.9.5 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-50-generic Pretty Productname: Ubuntu 18.04.2 LTS Product Type: ubuntu Product Version: 18.04 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 405161] New: pass-through layer groups crash with the transform tool
https://bugs.kde.org/show_bug.cgi?id=405161 Bug ID: 405161 Summary: pass-through layer groups crash with the transform tool Product: krita Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Layer Stack Assignee: krita-bugs-n...@kde.org Reporter: iszo...@gmail.com Target Milestone: --- VERSION 4.2.0-pre-alpha PACKAGE 2:4.1.0-0~201902231548~ubuntu18.04.1 SUMMARY pass-through layer groups crash applying a transform with the transform tool, if pass-through is not enabled then it doesn't crash. STEPS TO REPRODUCE 1. Create Krita document 2. Create a layer and then group it, then tick the pass-through option of the group layer 3. Select the transform tool 4. Select the group layer in the layer docker 5. Do a transform with the tool 6. Crash OBSERVED RESULT Crash before moving the group layer with pass through EXPECTED RESULT to transform the layer(or layers) inside the group, and not crash SOFTWARE/OS VERSIONS Windows: MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 403906] New: Tools > Scripts > Export Layers Plugin is broken by a change in a function
https://bugs.kde.org/show_bug.cgi?id=403906 Bug ID: 403906 Summary: Tools > Scripts > Export Layers Plugin is broken by a change in a function Product: krita Version: 4.1.7 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Scripting Assignee: krita-bugs-n...@kde.org Reporter: iszo...@gmail.com Target Milestone: --- >From krita lime ppa 2:4.1.0-0~201902011749~ubuntu18.04.1 2:4.1.7-1~bionic SUMMARY There was a change (apparently) in the Node.save() function that breaks the "Export Layers" built-in plugin. Line 172 of it has: node.save(layerFileName, self.xResSpinBox.value(), self.yResSpinBox.value()) but if you check the documentation the Node.save() function has a fourth argument "const InfoObject & exportConfiguration" so as expected the plugin throws a "Not enough arguments" error STEPS TO REPRODUCE 1. Open krita file 2. Tools > Scripts > Export Layers 3. Error Window OBSERVED RESULT The plugin throws a "not enough arguments" error EXPECTED RESULT save the layers Krita Version: 4.2.0-pre-alpha Qt Version (compiled): 5.9.5 Version (loaded): 5.9.5 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.15.0-29-generic Pretty Productname: Ubuntu 18.04.1 LTS Product Type: ubuntu Product Version: 18.04 OpenGL Info Vendor: ATI Technologies Inc. Renderer: "AMD Radeon (TM) RX 480 Graphics" Version: "3.0.13536 Compatibility Profile Context 18.30.2.15" Shading language: 4.50 Requested format: QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) Current format:QSurfaceFormat(version 3.0, options QFlags(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, profile QSurfaceFormat::OpenGLContextProfile(NoProfile)) Version: 3.0 Supports deprecated functions true is OpenGL ES: false Hardware Information Memory: 31 Gb Cores: 16 Swap: /tmp -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389478] Transform tool edition on group layer ignores transform mask on children layers
https://bugs.kde.org/show_bug.cgi?id=389478 --- Comment #3 from iszotic <iszo...@gmail.com> --- (In reply to wolthera from comment #2) > So... the report is instead: > > "The operations in the layer->transform don't trigger transform mask > recalculations"? > > Because otherwise we can also just close this? Yes that's the report now, do I have to make another report? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 383112] Crash randomly when using the transform tool and select an other tool.
https://bugs.kde.org/show_bug.cgi?id=383112 --- Comment #6 from iszotic <iszo...@gmail.com> --- Created attachment 110140 --> https://bugs.kde.org/attachment.cgi?id=110140=edit possible backtrace to the transform tool random crashes possible backtrace to the transform tool random crashes. no matter if you press enter, or change tool -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 383112] Crash randomly when using the transform tool and select an other tool.
https://bugs.kde.org/show_bug.cgi?id=383112 iszotic <iszo...@gmail.com> changed: What|Removed |Added CC||iszo...@gmail.com --- Comment #5 from iszotic <iszo...@gmail.com> --- I have a backtrace, maybe it could help, I attached it In my case is so random when it crashes, it could take almost one hour of constant use of the transform tool, or it can happen just about 10 min, and it doesn't matter the complexity of the scene. It's pretty annoying my system, 3.3.3 also has the issue Krita Version: 4.0.0-beta1 OS Information Build ABI: x86_64-little_endian-lp64 Build CPU: x86_64 CPU: x86_64 Kernel Type: linux Kernel Version: 4.10.0-42-generic Pretty Productname: Ubuntu 16.04.3 LTS Product Type: ubuntu Product Version: 16.04 OpenGL Info Vendor: ATI Technologies Inc. Renderer: "AMD Radeon (TM) RX 480 Graphics" Version: "3.0.13505 Compatibility Profile Context 17.50.2.13" Shading language: 4.50 Requested format: QSurfaceFormat(version 3.0, options QFlags(0x4), depthBufferSize 24, redBufferSize -1, greenBufferSize -1, blueBufferSize -1, alphaBufferSize -1, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 0, profile 2) Current format:QSurfaceFormat(version 3.0, options QFlags(0x4), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior 2, swapInterval 0, profile 0) Version: 3.0 Supports deprecated functions true is OpenGL ES: false -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389478] Transform tool edition on group layer ignores transform mask on children layers
https://bugs.kde.org/show_bug.cgi?id=389478 --- Comment #1 from iszotic <iszo...@gmail.com> --- >_< sorry devs, I realize now that this is how transform tool should work >because it works on selections, not layers. And transform masks only do a >specific transform over a layer so it cannot have zones with different >transforms. but still, un-interactive layer operations (rotation, scale) don't >recalculate the transform masks. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 389478] New: Transform tool edition on group layer ignores transform mask on children layers
https://bugs.kde.org/show_bug.cgi?id=389478 Bug ID: 389478 Summary: Transform tool edition on group layer ignores transform mask on children layers Product: krita Version: 3.3.3 Platform: Kubuntu Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Tools/Transform Assignee: krita-bugs-n...@kde.org Reporter: iszo...@gmail.com Target Milestone: --- I'm trying to paint symmetric objects but the editions made with transform tool don't get carried on to the mirror part of the symmetric object. So I tried with a mirrored layer, but then when I try to move the layer and its mirrored clone simultaneously the mirror mask transform in the clone just breaks with tranform tool. Steps 1) new document 2) create layer1, paint something 3) create clone1 of layer1, attach transform mask, make a flip, and translate to make a symmetric object 4) create group1 with layer1 and clone1 5) apply a tool transform on group1 6) the child transform mask on clone1 now has the transform made over the group ignoring their previous mask transform. Workaround1 Move tool doesn't ignore the transform in child transform masks and recalculates correctly the child transform masks. Workaround2 Locking the transform mask in child layers only works with masks with translation. masks with scaling(and flipping) or rotations break the group transformation made. Workaround tried (fails) Attach a second transform mask unlocked on child layers Tick/Untick the work recursively button -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 384605] Only the first EXR layer, from single or multilayer exr file gets transparency
https://bugs.kde.org/show_bug.cgi?id=384605 --- Comment #1 from iszotic <iszo...@gmail.com> --- (In reply to iszotic from comment #0) > Workaround > > Export the alpha channel in a separate file (or layer in multilayer EXR) and > convert the layer into a transparency layer for subsequent layers. The > problem is that this conversion is slow. Workaround 2 (faster than converting alpha layers) Open each layer and then copy and paste into one big project. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 384605] New: Only the first EXR layer, from single or multilayer exr file gets transparency
https://bugs.kde.org/show_bug.cgi?id=384605
Bug ID: 384605
Summary: Only the first EXR layer, from single or multilayer
exr file gets transparency
Product: krita
Version: 3.2.1
Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: File formats
Assignee: krita-bugs-n...@kde.org
Reporter: iszo...@gmail.com
Target Milestone: ---
Hi
Transparency only works if you open the EXR file. Later if you try to add the
second EXR file or later ones then the layers will not get transparency, at
all. I tried slitting the alpha with no success, and the console only trows
this message.
dev "RGB/Alpha (16-bit float/channel)" ("RGBA","F16" ) image "RGB/Alpha (16-bit
float/channel)" ("RGBA","F16" ) cfg false
I have tried drag and drop and importing from the layer menu
(And the transparency for the layers opened in the EXR file don't work right
out of the box neither, you have to search for the right color profile, in my
case sRGB built-in, then it works, but that it's part of this bug
https://bugs.kde.org/show_bug.cgi?id=352837 )
I also tried normalizing the alpha channel specifically for krita, setting
values of 0.001 for zero alpha pixels, in case the conversion from zero-alpha
to some alpha was broken. Also want to mention that the EXR files come from
blender 2.79
Workaround
Export the alpha channel in a separate file (or layer in multilayer EXR) and
convert the layer into a transparency layer for subsequent layers. The problem
is that this conversion is slow.
--
You are receiving this mail because:
You are watching all bug changes.
