[krita] [Bug 463925] New: The newly saved gradient map preset colours are wrong, they turn darker

2023-01-06 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=463925

Bug ID: 463925
   Summary: The newly saved gradient map preset colours are wrong,
they turn darker
Classification: Applications
   Product: krita
   Version: 5.1.3
  Platform: Appimage
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: Filters
  Assignee: krita-bugs-n...@kde.org
  Reporter: m...@konayachi.com
  Target Milestone: ---

SUMMARY
I encounter a weird behavior on the gradient map feature.
After I make a new gradient map set, when I’m about to save it as a new preset
- the newly saved preset has different colours than the original gradient map I
intended to save.
It turns darker out of nowhere, and the colours are wrong too.

See the video demonstration here: https://www.youtube.com/watch?v=D72HdbVKhEU

STEPS TO REPRODUCE
1. Create a drawing like usual.
2. Create a filter mask on a layer with drawing.
3. Choose Gradient Map, and play around with the colour slider bar to choose
the desired colour.
4. Try to save the created gradient map set to a new preset by typing the
desired name and then press the + button.

OBSERVED RESULT
There are two results, and they don't always reproduce the same way.
Result A: a newly saved gradient map preset appears on the list. The colour
looks different from the intended colours on the slider bar (it turns darker).
Upon clicking on that new preset, the colour on the canvas changed to the wrong
colour.
Result B: a newly saved gradient map preset appears on the list. The colour
looks the same from the intended colours on the slider bar. Upon clicking on
that new preset, the colour on the canvas also changed to the wrong colour.

EXPECTED RESULT
The newly saved preset should represents the same colours as intended.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux Mint 21, appimage

ADDITIONAL INFORMATION
Yesterday I made 6 gradient map filter mask layers for different purposes. I
tried to save each of them as separate presets, and this issues happened on all
of them. The newly saved presets have the colours wrong from intended, makes it
useless to create presets.
Today I revisited this file, 5 out of 6 saved presets (which displayed wrong
colours, and gave wrong colours) now give the correct colours although they
still have wrong colours display. On the last 1, the issue persists. I can also
reproduce this multiple times, where the saved preset has darker colours. (as
shown in the video)

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

[krita] [Bug 463842] New: Gradient Map (from Filter Mask) window is too small upon reopening after creation

2023-01-04 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=463842

Bug ID: 463842
   Summary: Gradient Map (from Filter Mask) window is too small
upon reopening after creation
Classification: Applications
   Product: krita
   Version: 5.1.3
  Platform: Appimage
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: * Unknown
  Assignee: krita-bugs-n...@kde.org
  Reporter: m...@konayachi.com
  Target Milestone: ---

Created attachment 155027
  --> https://bugs.kde.org/attachment.cgi?id=155027&action=edit
Current behavior vs the ideal behavior of filter mask window.

SUMMARY
Each time I reopen gradient map (filter mask layer), the window is too small
that I'm unable to access some menus on the lower side of the interface. Having
to resize the filter mask window each time I want to adjust one colour stop on
a gradient map slows my workflow by a lot.
See image attachment for comparison between the current state vs the ideal
state.

STEPS TO REPRODUCE
1. Draw normally
2. Create a filter mask from a raster layer
3. Select gradient map, click OK (window will close)
4. Reopen filter mask with F3 (shortcut)
5. It opens gradient map menu with a small window that doesn't display
everything (as seen on attachment)
6. Resize window, click OK (window will close)
7. Repeat step 4 and so on

OBSERVED RESULT
It opens gradient map window menu with a small window that doesn't display all
of the interfaces (as seen on attachment, left side)

EXPECTED RESULT
It opens gradient map window menu with a window that displays all interfaces
(as seen on attachment, right side)

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: Linux Mint 21; appimage

ADDITIONAL INFORMATION
It would be ideal if Krita is able to save the window size that we set on this
(because there are some workflows where I would constantly open this filter
mask layer to adjust small thing every now and then) so that we don't have to
resize it every single time.
This can be reset upon restarting Krita as a way to refresh the state in case
of some breaking interfaces due to the resize.

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

[krita] [Bug 451771] Krita crash when applying layer style (possible corrupted resourcecache.sqlite)

2022-03-30 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=451771

--- Comment #2 from Konayachi  ---
Hello Dmitry,

I did step 1 and 2b as you explained, and now Layer Style is completely greyed
out. I cannot click on it, nor access it from a shortcut shows anything. I used
the Krita nightly version 5d2860885a.
I retested the same on my Krita 5.0.2 and now instead of crashing, it is
completely greyed out as well.

Also, I experienced another strange behavior as I wrote in bug 452056, it may
or may not be related. Perhaps you can have a look from your side?

Thank you for your attention, looking forward to hearing back from you :)

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

[krita] [Bug 452056] New: When opening a file, activated layer styles may not be the same than the ones saved

2022-03-29 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=452056

Bug ID: 452056
   Summary: When opening a file, activated layer styles may not be
the same than the ones saved
   Product: krita
   Version: nightly build (please specify the git hash!)
  Platform: Other
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: layer styles
  Assignee: krita-bugs-n...@kde.org
  Reporter: m...@konayachi.com
  Target Milestone: ---

Created attachment 147830
  --> https://bugs.kde.org/attachment.cgi?id=147830&action=edit
Reproduction steps

SUMMARY
Activated Layer Style is not saved as is, after closing the file and reloading
it again, the Layer Style is either deactivated or activated (different from
the state when it was saved).


STEPS TO REPRODUCE
After saving the file with these certain states of LS (Layer Style) as
explained in the matrix below, close the file, then reload the file again.

The LS states matrix:
|  case 1  |  case 2  |
Group A |  LS on   |  LS off  |
↳ Layer 1   |  LS off  |  LS on   |
↳ Layer 2   |  LS off  |  LS on   |

(See attached video for the demo)


OBSERVED RESULT
case 1
outcome = Group A LS changed from on to off, Layer 1 and Layer 2 LS remain off
LS are *deactivated* on both the group and the layers inside the group itself.

case 2
outcome = Group A LS changed from off to on, Layer 1 and Layer 2 LS remain on
LS are *activated* on both the group and the layers inside the group itself.


EXPECTED RESULT
Applied LS is activated on either on each layer, or on the group only.
Layers need to be inside the group.


SOFTWARE/OS VERSIONS

Device: Linux Mint 20.3 xfce
KDE Plasma Version: N/A
KDE Frameworks Version: N/A 
Qt Version: Unknown
Krita version: 5d2860885a (Also happens in 5.0.2)

ADDITIONAL INFORMATION
I only noticed this bug after I experienced the crash that is explained in bug
451771 (https://bugs.kde.org/show_bug.cgi?id=451771) but I am not sure whether
this bug existed before that.

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

[krita] [Bug 451771] New: Krita crash when applying layer style (possible corrupted resourcecache.sqlite)

2022-03-21 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=451771

Bug ID: 451771
   Summary: Krita crash when applying layer style (possible
corrupted resourcecache.sqlite)
   Product: krita
   Version: 5.0.2
  Platform: Appimage
OS: Linux
Status: REPORTED
  Severity: normal
  Priority: NOR
 Component: layer styles
  Assignee: krita-bugs-n...@kde.org
  Reporter: kona.yachiya...@gmail.com
  Target Milestone: ---

SUMMARY

After 5+ hours of use without issues, I tried to apply a stroke style to text
and krita crashed.
Crash repeated every time I tried to apply stroke again.
Deleting resourcecache.sqlite stopped the crashing but I lost favorites and
tags

CRASH DATA
I can't provide crash information because the how to provided
(https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports)
does not explain how to get for the crash data from an AppImage.


STEPS TO REPRODUCE
1. Draw and be unlucky
2. Open layer style
3. Add stroke

OBSERVED RESULT
1. Freeze for 3-5 secs
2. Crash

EXPECTED RESULT
Stroke is applied

SOFTWARE/OS VERSIONS

Device: Linux Mint 20.3 xfce
KDE Plasma Version: N/A
KDE Frameworks Version: N/A 
Qt Version: Unknown

ADDITIONAL INFORMATION

So, today I was drawing on Krita whole morning. I use lots of Layer Style -»
Stroke a lot in my piece. Out of nowhere, suddenly Krita crashed when I'm about
to add Stroke to a layer. I've been adding Stroke to layers prior to that, and
all was normal and smooth without problem.

Since then, Krita always crashes each time I try to add Stroke to a layer. I
thought, perhaps the file was corrupted, so I tried on a new file - it still
crashed. Now Krita also crashed even when I was just opening the Layer Style -»
Stroke window without ticking the box.


WORKAROUND

I found out that deleting the `resourcecache.sqlite` while krita is not running
allowed me to try again and get it working. Maybe corrupted cache?

CONSEQUENCES OF WORKAROUND

However, I lose a lot of data including my favorite brushes list being
completely empty. Custom tags are also gone.

If there's a way to extract that information from the old settings I have
backed up and apply to the fixed database, please share. I would like my
favorites and tags back without having to recreate them.

I don't know what personal or copyrighted information is in my .local/krita
directory, so I rather not share the files publicly, however, I'm willing to
share those files with some of krita devs through direct sharing.

Thank you for the attention.

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

[krita] [Bug 429326] Recorder docker doesn't account for canvas size changes during drawing session.

2021-12-27 Thread Konayachi
https://bugs.kde.org/show_bug.cgi?id=429326

Konayachi  changed:

   What|Removed |Added

 CC||kona.yachiya...@gmail.com

--- Comment #6 from Konayachi  ---
(In reply to Dmitrii Utkin from comment #3)
> This could be solved by adding ",setsar=1" after "scale=$WIDTH:$HEIGHT",
> but.. frames become stretched. We can add black padding to keep ratio by
> adding
> "force_original_aspect_ratio=decrease,pad=$WIDTH:$HEIGHT:(ow-iw)/2:(oh-ih)/
> 2" but probably it doesn't look so good?
> 
> Also some filters and encoders like gif doesn't work with variable input
> image size it either causes ffmpeg to crash or just skip everything until
> the target ratio is reached.
> 
> You can try how it works, just edit MP4 x264 profile like this:
> 
> 
> -framerate $IN_FPS
> -i "$INPUT_DIR%07d.jpg"
> -vf
> "scale=$WIDTH:$HEIGHT:force_original_aspect_ratio=decrease,pad=$WIDTH:
> $HEIGHT:(ow-iw)/2:(oh-ih)/2,setsar=1"
> -c:v libx264
> -r $OUT_FPS
> -pix_fmt yuv420p
> 
> 
> 
> If it's ok, I will update profiles accordingly.

This workaround worked for me!

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