Bug 392241 - Using colorpicker on colorize preview (faded) color picks the faded color instead of the original stroke color
Summary: Using colorpicker on colorize preview (faded) color picks the faded color ins...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Tools/Colorize (show other bugs)
Version: 4.0
Platform: Other Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-23 16:25 UTC by cyaoeu
Modified: 2018-04-07 13:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
Colorize colorpicker problem (49.24 KB, image/jpeg)
2018-03-23 16:25 UTC, cyaoeu
Details

Note You need to log in before you can comment on or make changes to this bug.
Description cyaoeu 2018-03-23 16:25:06 UTC
Created attachment 111583 [details]
Colorize colorpicker problem

Not sure if could be called a bug since it's the normal colorpicker behavior, but it's a bit annoying when you want to colorize stuff if you're used to color picking. 

What happens is you draw a bunch of strokes, update colorize, then colorpick in a colorize created preview area. If you do that you end up with a different color than the one you painted the first stroke with (for example if you picked red and color pick the preview area you end up with a pink color).

Maybe you're supposed to either 1. colorpick the original stroke which is a bit annoying since strokes are usually small or 2. use the key strokes palette which is all the way to the side away from where you're actually painting. I think the workflow of actually picking colors from the image is faster and better.

So the fix for this would be to: if you are in colorize edit key strokes mode, when colorpicking on an area that is not a real stroke, change the result to the original non faded color (the one that shows when edit key strokes is disabled). 

Attachment shows 4 squares, top left and right are red and blue, then the resulting colorize areas (in preview mode) were picked and used in the bottom left and right squares. Ideally these should end up being the same colors.
Comment 1 Halla Rempt 2018-04-02 13:41:18 UTC
I guess that if a colorize mask is present, we should pick from the original paint device, not the projection.
Comment 2 Dmitry Kazakov 2018-04-05 12:52:39 UTC
Git commit eebaf3891d4514c30987de4593ae85d0205ba3be by Dmitry Kazakov.
Committed on 05/04/2018 at 12:52.
Pushed by dkazakov into branch 'master'.

Make color pick tools pick from a special device

(which is coloring device for colorize masks)

It means that from now on, "Pick from layer" color picker mode will pick
from the filled area, not from the key strokes
CC:kimageshop@kde.org

M  +5    -0    libs/image/kis_base_node.cpp
M  +7    -0    libs/image/kis_base_node.h
M  +7    -0    libs/image/lazybrush/kis_colorize_mask.cpp
M  +2    -0    libs/image/lazybrush/kis_colorize_mask.h
M  +1    -1    libs/ui/tool/kis_tool_paint.cc
M  +2    -2    plugins/tools/basictools/kis_tool_colorpicker.cc

https://commits.kde.org/krita/eebaf3891d4514c30987de4593ae85d0205ba3be
Comment 3 Dmitry Kazakov 2018-04-07 13:45:50 UTC
Git commit 0a4a1f88cc2be3d7a395b9cd3d1eab6f1d5a42e6 by Dmitry Kazakov.
Committed on 07/04/2018 at 13:28.
Pushed by dkazakov into branch 'krita/4.0'.

Make color pick tools pick from a special device

(which is coloring device for colorize masks)

It means that from now on, "Pick from layer" color picker mode will pick
from the filled area, not from the key strokes
CC:kimageshop@kde.org

M  +5    -0    libs/image/kis_base_node.cpp
M  +7    -0    libs/image/kis_base_node.h
M  +7    -0    libs/image/lazybrush/kis_colorize_mask.cpp
M  +2    -0    libs/image/lazybrush/kis_colorize_mask.h
M  +1    -1    libs/ui/tool/kis_tool_paint.cc
M  +2    -2    plugins/tools/basictools/kis_tool_colorpicker.cc

https://commits.kde.org/krita/0a4a1f88cc2be3d7a395b9cd3d1eab6f1d5a42e6