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

[Boudewijn Rempt]

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.

> 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.

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.

> 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!

> The program pretty much explains itself once you open it and use it, so I
> encourage curious people to download and compile it. I know it compiles in
> Windows and Linux, but I lost the Windows binaries  :S  so I can't provide
> them here.
> 
> That's all I'll say for now, as I don't want to exhaust anyone with so much
> text.
> I'm looking forward to feedback and comments by anyone interested.
> If you believe there's something more meaningful I could do for Krita for
> this year's GSoC, please tell me. Although you know my bias is with this
> feature  :]



-- 
Boudewijn Rempt | http://www.valdyas.org