Bug 446759 - Implement Mixbox, a "Practical Pigment Mixing for Digital Painting"
Summary: Implement Mixbox, a "Practical Pigment Mixing for Digital Painting"
Status: REPORTED
Alias: None
Product: krita
Classification: Applications
Component: Color models (show other bugs)
Version: unspecified
Platform: unspecified Unspecified
: NOR wishlist
Target Milestone: ---
Assignee: Krita Bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-12-09 23:07 UTC by John Kirk
Modified: 2021-12-10 19:48 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Kirk 2021-12-09 23:07:59 UTC
Mixbox is a pigment mixing black-box. You pass RGB colors in and get the mixed RGB out. Internally, Mixbox treats the colors as if they were made of actual real-world pigments. It uses the Kubelka & Munk theory to predict the color of the resulting mixture. This way, Mixbox achieves that blue and yellow mix to green, the same way real pigments do.

Source Code: https://github.com/scrtwpns/pigment-mixing
The research paper: https://scrtwpns.com/mixbox.pdf
Video demonstration: https://youtu.be/9egCAxhOHg4
Talk: https://youtu.be/_qa5iWdfNKg

It has a non-commercial license, and according to their website "Being this simple plug-and-play module, Mixbox can be easily integrated into any painting software." So I trust that is easy to implement.

(Forgive me if I didn't tag the correct component.)
Comment 1 Emmet O'Neill 2021-12-10 04:23:39 UTC
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.
Comment 2 Emmet O'Neill 2021-12-10 04:44:02 UTC
> [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.
Comment 3 Halla Rempt 2021-12-10 09:24:05 UTC
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.
Comment 4 John Kirk 2021-12-10 18:10:01 UTC
(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?
Comment 5 Halla Rempt 2021-12-10 19:48:21 UTC
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.