A GSoC proposal to work on a canvas with realistic color mixing

[JL VT]

On Sun, Mar 21, 2010 at 7:47 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Saturday 20 March 2010, JL VT wrote:
>> Greetings everyone, Krita developers and users.
>>
>> My name is José Luis Vergara, but I prefer to be called Pentalis, as I
>> couldn't complain about the other name when I was born  :-)
>
> Hi Pentalis! Welcome to the mailing list.
>
Thank you!

>> I'm aware that work has already been done on implementing the Kubelka-Munk
>> formula in Krita (which allows for realistic color mixing to be done within
>> the digital canvas). My vision is to consolidate that work into a
>> seamlessly integrated "realistic color mixing" option for the canvas in
>> Krita, such that whenever the user wants, he can switch from additive
>> mixing (the default and only option in most programs) to K-M based color
>> mixing.
>>
>> Ideally, much more customization should be possible, but for the sake of
>> realistic timelines, I believe just the option of switching color mixing
>> behavior for the whole image with a single and accesible control is more
>> than enough to solve the problem of realistic color mixing (I know it'd
>> solve it for me).
>
> There are some technical issues here: the main thing is that colorspace you
> are working in is very basic to Krita. If you want to move from K-M to RGB
> mixing on the canvas itself or the other way around, you have to convert your
> image and layers, and that is both expensive and can cause loss of image
> information. I can't see how we can solve this in an elegant way, but I am
> open for ideas.
>
After extensive conversations with Emanuele, regarding this very
complication, and the fact that he is going to keep working to
complete his K-M colorspace, I've started to consider the chance to
instead help with Textures (problem 2) instead of realistic color
mixing (problem 1). Which leads us to...

> The other issue, getting a nice and detailed texture, can be solved in two
> ways. Gimp really isn't the best application to compare with here since it
> doesn't implement either. The first method is to store texture information
> (roughness, height map, wetness, etc) on the canvas, the other is to make a
> brush engine that paints in a way that gives a textured feel, like Krita's
> sumi-e or soft brush (with some settings).
>
> We did attempt a couple of times to implement the first method, and even had a
> proof of concept for watercolor + height/water-mapped canvas working in 1.6.
> It's tough to do this right, because the physics simulator interferes with
> undo/redo and because of the extra memory constraints. It was also originally
> part of Emanuele's summer of code project that ended with the K-M colorspaces.
> Right now, physics simulation of canvas/paint properties is not part of what
> we want to achieve for Krita: we want to implement an application that feels
> natural to artists used to traditional media, but we think that "faking" it
> with good brush engines is currently the better approach.

...to this part!.
So we have two ways to approach the texture problem:
1.- Texture on the canvas.
2.- Texture from the brush.

Texture on the canvas and realistic color mixing are both very
ambitious goals from all I've read and conversed, and Google has
stated that they'd rather put higher priority on more "realistic"
applications for GSoC than those with high ambitions and less chances
of fulfilling them.

Experimenting with texture on the canvas and realistic color mixing
seems really exciting in an of itself and, on second thought, I'd
rather not make an application for GSoC based on those ambitious goals
(yet); instead I'd try to explore those features in my free time.

With regards to "faking" it with good brush engines, I say so far
you've done a very good job. Lukas' spray brush is different to
anything I've tested before and it actually feels useful for
texturing, I'd say the same about the Sumi-e brush, except that I've
seen and used things like it before, and I love it.

This leads me to the new idea...

The alternative proposal I've been thinking for GSoC would be more paintops.
I'm aware that Lukas is working on those, but there's plenty of
textures in the world and ideas floating around, enough for some
parallel work.

Hatching and halftones are one of those very interesting textures that
could never go wrong in a paint-from-scratch application. It's
actually not painting in itself, but you said you were interested in
features for comic artists!.

One way to implement hatching and halftones would be to reimplement
gimp-painter's mixbrush into Krita (which does much more than just
mix). This time I actually compiled the gimp with the patch and toyed
with the tool for half an hour. It's an excellent tool, with enough
options to achieve a great variety of textures and colormixing at the
same time, achieving something that looks convincingly more
traditional than any other tool in the GIMP.

The drawbacks of the mixbrush for hatching and halftones is that I'm
limited by the texture I'm using, being unable to add other special
effects beyond the linearity of what you can observe in this video
(around minute 2:40)
http://www.youtube.com/watch?v=dNvcifmXGmw
Which is halftoning based on a texture (you can briefly see its
thumbnail during the demonstration). [I can't get enough of the music
:P ].

So, for example, I couldn't decide the ANGLE of the hatching, or
making non-linear effects like adding more hatching patterns on top of
the basic one with increasing tablet pressure, like this:
http://pentalis.org/hatching_example.png

On the other hand, the advantage of implementing something like the
gimp-painter-mixbrush would be its versatility, although I think it
has too many options and can easily confuse, therefore it'd be better
to implement it in the form of separate paintops which as a set are
equivalent to all of gimp-painter-mixbrush's functionality.

Given their different functionality, a halftone brush, hatching brush
and mixbrush could all be implemented, depending on circumstances
(necessity, skill points, task difficulty, availability of cheating
dice...).

Suggestions, comments and any other feedback is muchly appreciated.


>
>> For the record, I've never contributed code to a FOSS project before, but I
>> have worked on a few personal projects.
>> I don't like to show unfinished work (The Dragon Cave is actually finished
>> somewhere, so it doesn't count :-)  ) so the only thing I have to show is
>> my dice roll probability analizer, the Analizator:
>>
>> http://pentalis.org/Analizator.cpp
>
> Sounds like you're a tabletop rpg player!

Yes sir!, I even had my own system.
http://www.scribd.com/doc/217723/Gidra-V-01

But I failed miserably at both promoting it and bothering to write all
the updates  :P