First step for GSoC: the Painterly Color Mixer.

[Bart Coppens]

On Friday 01 June 2007 20:51, Emanuele Tamponi wrote:
> First step: the Color Mixer.
Ok, so I think I don't quite understand your vision on the Color Mixer. First, 
I'll say what _I_ was thinking about it, then I'll say how it doesn't fit 
with what you're saying, and then you can say I just misunderstood you ;-)

Ok, so for a color mixer, I thought we'd just do the following. We have a 
seperate paint device, the mixer. This works just like a regular paintdev on 
which you can paint. My idea was that you'd just use it with bidi paintops. 
So you paint on it: the current color mixes with the one on the mixer, and 
the mixed color transfers back to the brush color (with the possibility 
to 'dip' the brush into 'clean water', so as to clean it).

This has as a big disadvantage that it only works with painterly paintops. It 
has a big advantage that it is almost trivial to write a backend, once you 
have a working bidi paintop. Another advantage is that it should completely 
match with how the user will be able to paint on the actual painting, just 
like a painter will expect to have his 'real' mixer to not start drawing 
differently than when he uses a canvas to mix.

What I understand from your mail is that you just want to mix the colors in a 
more 'abstract' way to actually mix just colors, not using a direct 
correlation between the painterly colorspace using a painterly brush that is 
being used for the actual painting, and the result of the mixing.
This has indeed as the big advantage that it also works for 'regular' 
colorspaces. On the other hand, I think you'll lose the information on how a 
brush can 'smear', etc. But you also mention that you will use wetness, so 
I'm a bit confused that I misunderstand this all. Is what I think you mean 
indeed what you mean?

So, now that we got my vision out of the way, let's compare it to what I see 
here:
>     The mixer takes the footprint of the paintop. Then the
>     footprint is mixed with the underlying colors. Optionally, the
>     result is automatically set as the current color of the
>     paintop.
Ok, but how will you introduce new colors on the mixer? Like you write a bit 
later on: you want to set the color of the dab to 'white'. That way, no new 
colors will ever be introduced onto the mixer except white. So if you start 
with a white mixer, it'll never get anything else.
So I think you should also allow the current paintop color to be transfered to 
the mixer, instead of only allowing the transfer of the color from the mixer 
to the paintop. In essence, you want a bidi approach here, I think :-)

>     To do this, we need to know the nature of the current paintop:
>     we expect that a pencil mixes colors in a different way
>     respect a brush; and this just because the brush is wetter
>     than the pencil.
Yep, that is indeed a hard problem.

>     But current brush and pencil paintops (to make an example)
>     don't have any painterly properties, so the mixer doesn't know
>     about their wetness. On the other hand, there will be some
>     paintops that do have painterly properties.
Indeed.

>     My idea is: for all non-painterly paintops, the mixer guesses
>     about their wetness using their ids. For painterly paintops,
>     the mixer takes their properties using KisPaintOpSettings.
*cringe* This sounds very bad. 'Guessing' is always a bad thing if computers 
are involved :-) If you really need this information, you might want to 
introduce a new derivative class of KoColorspace or so called 
KoPainterlyColorspace. Then you can try to dynamic_cast into it, to see if 
the paintop can do cool wetness stuff, and then put some wetness info in that 
class, so you can use it.

>     First issue: we don't want to respect exactly current paintop
>     settings: for example, it's better if we use a different size
>     for the paintop, and, if the current dab of the paintop is a
>     pattern, we will ignore it (we mix colors, not peppers! ;) and
>     take a default color instead.
I agree on the pattern, I don't on the paintop size. That you don't want to 
see a pattern being drawn sounds OK, since they don't have wetness 
information and so ;-). On the other hand, the user might want to choose a 
huge brush size to make a huge dab of 'base mix color', and then use a 
smaller brush to finetune different parts of it. At least, that's how I 
imagine how I'd use it, but I'm not a real artist :-)

>     Another issue: the bidirectional paintop that I'm going to
>     implement will interfere with the behavior of the mixer. In my
>     opinion, his "bidirectionality" (excuse me for the term :) has
>     to be deactivated while you use it in the mixer.
Well, I think I would expect a bidi behaviour in the mixer, so I'm not sure 
about this.

>     To do all this, my idea is:
>     - Draw the paintop footprint in a white dab (this way, the
>       bidirectional paintop can't do its stuff).
> [...]
>     - Mix up the color on the dab with the color in the mixer
>       canvas.
This confuses me even more. Which is why I think I misunderstand =)

>     To clear a frequent equivocal: the mixer doesn't need a
>     painterly overlay! The overlay provides a lot of extra,
>     interactive functions that in a mixer (that just need to *mix*
>     colors) are going to be not useful, if not even not wanted.
Yeah, but if you don't need overlay, I expect you to use a special colorspace 
for this mixer. Does this mean that you want to mix guache paint with 
watercolors on the mixer (or whatever paints, I don't know :P)? How do you 
plan to achieve this?

Or do you only want an oilpaint/waterpaint based mixer, which would also be 
quite cool? But then you wouldn't even need to do all the 'guessing' of 
non-painterly colorspaces: just convert their colors to your colorspace 
(through RGB8 if need be), and then adjust their wetness to a default value?

> Ideas? Questions? Problems?
Probably ;)

> I hope to have something working for Monday or Tuesday, but
> obviously I'd like to know if you agree with this behavior.
Monday or Tuesday is so fast :D Even if it is not what I think would work, a 
prototype of this would be interesting to see in action anyway, might 
convince me that it's actually a good thing to have. Cool.

Bart