First step for GSoC: the Painterly Color Mixer.
Emanuele Tamponi
emanuele at valinor.it
Fri Jun 1 22:43:30 CEST 2007
Bart Coppens ha scritto:
>> 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 :-)
>
I set the color of the dab to white (or, well, transparent). Then I draw
the footprint
on the dab: now the dab is no more white, it has the color drawn by the
paintop :)
Is it clear now?
>> 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.
>
Your idea is just an implementation of what I called "guessing"... Since
that class
will contain guessed stuff for non-painterly paintops :)
>> 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 :-)
>
This is an interesting point. But in Corel Painter X, the brush size in
the mixer
can be different from the "main"/"real" one. You just need to "magnify"
the result...
>
>> 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.
>
Now perhaps you understand this point: the bidirectional paintop does
more or
less the same thing that the mixer does.
You say: "so let use the mixer only with the bidirectional paintop"
I say: "let the mixer work with *any* paintop, and deactivate the
duplicate behavior
of the bidirectional paintop".
Got it? What do you think?
>> 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 =)
>
>
Again, I hope you understand now :)
> 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.
>
Too fast? We'll see ;)
Emanuele
More information about the kimageshop
mailing list