This forum has been archived. All content is frozen. Please use KDE Discuss instead.

Brush Designer should _multiply_ 'active color' value?

Tags: None
(comma "," separated)
j5v
Registered Member
Posts
4
Karma
0
The brush designer has a Value modifier, which adds between -100 to +100, with "50% as active colour"

Proposing that this should instead multiply, between 0 and (say) 300%, with 100% as the active colour.

Currently, a problem arises when painting in 32-bit float mode, with a brush that attempts to darken the active color. When painting with a dark colour, having value 0.2, and the modifier subtracts 0.4, the result is black, but internally it is stored as -0.2. Subsequent painting on top of this might be ineffective, because it has to climb through the negative values to be able to break above 'black'.

The proposed 'multiply' method also allows the Value modifier to make sense for a range of active colours; as it stands, adding makes sense only for the active colour (value) is was designed for. Also, multiplying fits well with the perceptual modifications one would make to a color, and to the desired effect one would use Value modifications for (shadowing, lighting as a proportion of the active color)
User avatar
TheraHedwig
KDE Developer
Posts
1794
Karma
10
OS
While this makes sense in the floating point spaces, it doesn't within the integer modes. We'll need to come up with something a bit more sensible. We cannot afford to randomly change things as this would break a ton of people's brushpacks.

Value in this case is explicitely HSV value.
j5v
Registered Member
Posts
4
Karma
0
Thanks for pointing out the two biggest obstacles to its adoption.
Yes, I'd assumed that this could not directly replace the existing 'add' function, and that it would need careful consideration to not break existing brush definitions.

It's possible as a separate property (a sibling of Value; perhaps Lighting), to integrate consistently into the Brush Designer UI. Its relationship (ordering: multiply then add, or add then multiply) with Value would need to be decided.

Agree, its use with integers would be difficult, even if assisted with a noise function - the artefacts might be unacceptable. I can see now why addition was considered in the first place.


Bookmarks



Who is online

Registered users: abc72656, Bing [Bot], daret, Google [Bot], lockheed, Sogou [Bot], Yahoo [Bot]