Bug 446759

Looks interesting and I think everyone would welcome anything that promises even more lifelike or intuitive color mixing in Krita. 

I have a couple of minor questions/reservations about this, though:

[1.] I find the "non-commercial license" to be a bit vague as far as software licensing goes. Krita is obviously free and open source software licensed under the GPLv3, but it is also available through stores on various platforms as a means of broadening our user base and creating a way to support development. So, does that count as "commercial" or not? Because of that, we would probably be wise to contact the owners of this code and get an explicit answer (and permission) before using any of their code. 

I could be over-thinking it a bit, but I think there's an element of risk involved with making use of code with vague licenses.

[2.] Someone who knows more about color in Krita than I do might be able to answer this, but I wonder how this would mesh with our existing color management system. Krita supports a lot of different color models and color spaces, and we would need to make sure that this can either work across all of them or make sure that it is only enabled in the ones where it does work. Maybe it would be as simple as provide an alternate `KoMixColorsOp`, but that may still take a bit of work.

Anyway, the theory behind it makes sense to me at least. 
I think getting some clarity on the "non-commercial" license from the developers is probably a good idea.
That might be something to talk about at the next meeting.

> [1.] I find the "non-commercial license" to be a bit vague as far as
> software licensing goes. Krita is obviously free and open source software
> licensed under the GPLv3, but it is also available through stores on various
> platforms as a means of broadening our user base and creating a way to
> support development. So, does that count as "commercial" or not? Because of
> that, we would probably be wise to contact the owners of this code and get
> an explicit answer (and permission) before using any of their code. 
> 
> I could be over-thinking it a bit, but I think there's an element of risk
> involved with making use of code with vague licenses.

I guess I was actually under-thinking it.

Tiar tells me that the source code in this case is just plain incompatible with GPLv3, so it would need to be re-implemented in a GPLv3 compatible license based on the research paper.

We can always ask the authors to dual-license it. Also, my perpetual reminder whenever stuff like this comes up: we had this years ago. If you check the koffice 2.2 tarball, you'll find the color mixer plugin that Emanele Tamponi implemented using the Kubelka-Munk equations.

(In reply to Halla Rempt from comment #3)
> We can always ask the authors to dual-license it. Also, my perpetual
> reminder whenever stuff like this comes up: we had this years ago. If you
> check the koffice 2.2 tarball, you'll find the color mixer plugin that
> Emanele Tamponi implemented using the Kubelka-Munk equations.

Could THAT be implement into the newer Krita versions then? How much work would that be?

A lot of work, and honestly, for all the hype, it just is not that useful. 

Digital painting is not a sim, it's something all by itself.

The authors of this paper natter about pigments, without even defining the properties of these pigments -- no mention of smalt vs ultramarine, and their respective properties, and uses. for instance. This mixing might be a little bit closer to what people have learned in primary school, but even that depends on which country, which school, and which paints were available to them when they were kids. Most of which would have been ink-impregnated clay globules gouache type of paints, which have notoriously bad mixing properties.

I've been working on krita since 2003, have been excited about natural mixing, natural brush strokes, natural surfaces until about 2007, when I realized that all this sim business is not helping artists get work done.