[krita] [Bug 342105] [HUION] Cannot right click with the Pen of Huion H610 Pro

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=342105

Rastaban26  changed:

   What|Removed |Added

 CC||regulus2...@gmail.com

--- Comment #32 from Rastaban26  ---
I'm also experiencing this problem with the release version of Krita 3.0. 
Using Huion 610.

Also middle mouse button (used from the stylus) is not working.

Proposed workarounds are working fine for me.

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361682] New: Internal error: sanityCheckAllJobsAreCancellable()

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361682

Bug ID: 361682
   Summary: Internal error: sanityCheckAllJobsAreCancellable()
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
   URL: http://sta.sh/022r0rwd9cfe
OS: MS Windows
Status: UNCONFIRMED
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

Settings: 
- openGL - enabled
- instand preview - enabled

Conditions:
- canvas 5000 x 3000
- using big, textured brushes

Situation description:
Was doing just some random painting (tablet with a pressure), testing out the
responsiveness of instant preview and color picking while brush ware processed.
After some time, at a random moment I've received an internal error:

ASSERT krita(): "sanityCheckAllJobsAreCancellable()" in file
C:\kritadev\krita\libs\image\kis_stroke.cpp, line 151  (please check the photo)

Ignoring the error was not possible. Had to kill the process.


Reproducible: Didn't try




CPU: Intel i5-3210M @2.50 GHz 
Memory: 8 GB System: 
Windows 7 64b 
GPU: NVIDIA GeForce GT 630M 
Tablet: Wacom Bamboo

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361147] Request: Gamut masking for painting

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361147

Rastaban26  changed:

   What|Removed |Added

  Component|Color models|color selectors

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361147] Request: Gamut masking for painting

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361147

Rastaban26  changed:

   What|Removed |Added

Summary|Gamut masking for painting  |Request: Gamut masking for
   ||painting

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361148] Request: Color update in artistic color selector

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361148

Rastaban26  changed:

   What|Removed |Added

Summary|Artistic color selector not |Request: Color update in
   |updating|artistic color selector

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361149] New: Request: Move tool for frame range

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361149

Bug ID: 361149
   Summary: Request: Move tool for frame range
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Animation
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

I would like to request a feature of move tool that would move the content of
all selected frames in animation mode (this also applied to on-canvas selection
of all selected frames). This feature would solve a problem of repositioning a
desired part of animation.

Reproducible: Always

Steps to Reproduce:
How I would like it to work:

1. Create an animation (several frames length)
2. Select half of the frames
3. Move your selection around the canvas

Actual Results:  
Currently only one frame is being moved

Expected Results:  
I think it would be a good if all selected frames could move - which would
result in repositioning the half of the animation (in this particular example)

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361148] New: Artistic color selector not updating

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361148

Bug ID: 361148
   Summary: Artistic color selector not updating
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: color selectors
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

It's probably a feature, not a bug :) (so this entry is more a
suggestion/request rather than a bug report) It was always like that in Krita
and it's quite reasonable way artistic color selector should work, because of
the limited pallette.

However I would like to suggest changing the way it works so that it could at
least switch to the closest selected color.

Reproducible: Always

Steps to Reproduce:
1. Pick a color in artistic color selector and paint something.
2. Pick another color in artistic color selector and paint something.
3. Pick one of painted colors from the canvas.

Actual Results:  
The color chosen in artistic color selector is not changing.

Expected Results:  
Seuggestion/request: Switch color in artistic color selector to the one being
the closest to the one that has been picked (basic the color distance
measurements on the color model in artistic color selector)

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 361147] New: Gamut masking for painting

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=361147

Bug ID: 361147
   Summary: Gamut masking for painting
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: wishlist
  Priority: NOR
 Component: Color models
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

I would like to request a feature called gamut masking. It's basically a tool
that helps to limit the palette during painting. The idea is  described by
James Gurney (artist who made that approach popular in his book):
http://gurneyjourney.blogspot.com/2011/09/part-1-gamut-masking-method.html
http://gurneyjourney.blogspot.com/2011/09/part-2-gamut-masking-method.html
http://gurneyjourney.blogspot.com/2011/09/part-3-gamut-masking-method.html

Btw. This feature has been implemented in MyPaint:
https://github.com/mypaint/mypaint/wiki/v1.2-HCY-Wheel-and-Gamut-Mask-Editor

Reproducible: Didn't try

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360764] New: G'mic interactive colorize integrated with Krita is much slower than stand-alone G'mic

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360764

Bug ID: 360764
   Summary: G'mic interactive colorize integrated with Krita is
much slower than stand-alone G'mic
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: minor
  Priority: NOR
 Component: G'Mic for Krita
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

When using standalone G'mic from command line the preview (and final
processing) of colorization works much faster than when I work on the same
image in Krita (integrated g'mic).
For stand alone G'mic I'm using comand:
gmic input.png -x_colorize 1,1024,1 -split c,2 -o[-1] output.png
input.png is here: http://sta.sh/03evnbtvq9p

I'm aware that Krita can do a lot of more processing around the actual
colorization. However, I thought it would be a good idea to let you guys know
about this just in case.


Reproducible: Always

Steps to Reproduce:
1. Colorize image in Krita (G'mic interactive colorization)
2.  Colorize image in stand-alone G'mic
3. Compare performance and times

Actual Results:  
On my hardware using G'mic integrated with Krita colorizing an image works 2-3
times slower

Expected Results:  
Not sure if it's possible to achieve the same time. Please consider this only
as an info.

CPU: Intel i5-3210M @2.50 GHz 
Memory: 8 GB 
System: Windows 7 64b 
GPU: NVIDIA GeForce GT 630M 
Tablet: Wacom Bamboo

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360760] New: Picking color from canvas during instant preview processing chooses wrong color

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360760

Bug ID: 360760
   Summary: Picking color from canvas during instant preview
processing chooses wrong color
   Product: krita
   Version: 3.0 Alpha
  Platform: MS Windows
OS: MS Windows
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: general
  Assignee: krita-bugs-n...@kde.org
  Reporter: regulus2...@gmail.com

It seems that picking color from canvas (ctrl+click/tap) is not working
correctly while brush strokes are being processed. First of all, the little
preview of selected color is showing black all the time (even if I drag the
color picker across the whole canvas). Second, there is no effect of color
picking, since I'm stuck with my initial color until instant preview finishes
it works of transferring the pixel data to the full size image. After it has
finished, everything works fine. 

It is possible to pick a color during processing but one needs to do it through
a color selector.

Reproducible: Always

Steps to Reproduce:
1. Force long time instant preview processing (large canvas, with large brush
size + some scribbles)
2. While  instant preview is processing pick a color from canvas (ctrl+mouse 
click or ctrl+pen tap)


Actual Results:  
Result 1: Selected color is not being displayed correctly in color picking
preview (while performing a drag)
Result 2: Color is not picked until instant preview finishes it's work

Expected Results:  
1. The preview of selected color ( while performing a drag) should display the
correct color that is under the cursor.
2. The color selection should have an effect during the preview.

Potential solution suggestion: Pick colors from the additional small canvas
that is being used to display instant preview. It wont be 100% accurate colors
but at least there will be some responsiveness. Also correct and accurate
colors are not needed during instant preview work (when we view the smaller
size image), some approximation of final color will do just fine.

CPU: Intel i5-3210M @2.50 GHz 
Memory: 8 GB 
System: Windows 7 64b
GPU: NVIDIA GeForce GT 630M 
Tablet: Wacom Bamboo

-- 
You are receiving this mail because:
You are watching all bug changes.

[krita] [Bug 360686] Changing brush size before instant preview puts real strokes on canvas drastically affects final result

[Rastaban26 via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=360686

--- Comment #2 from Rastaban26  ---
(In reply to Boudewijn Rempt from comment #1)
> Hi, thanks for your report. I haven't been able to reproduce (my system
> might just be too fast for this to happen), but I'll ask around if others
> have seen it happen.

Hello,
I can try to record a video demonstrating this behavior if that would be
helpful :)

-- 
You are receiving this mail because:
You are watching all bug changes.