Well, that’s the thing here, isn’t it? It might be just an unfortunate combo of poor wording and misunderstanding. I’m certainly not an expert regarding licensing models - but what I’ve learnde over the years, is that it’s a minefield. So, maybe give them the benefit of the doubt…
Don’t get me wrong, I’m not trying to defend shady marketing tactics. I’m as much anti-capitalist as it get’s - but the MixBox folks might just not fit in here as a bogeyman. If they were, would they even publish their method and code, so everyone interested could learn from that material?
And no doubt, great art can be created without that “trick” - however, it’s a really nice and welcome option for people who want (close to) traditional behaviour in a non-traditional medium. I love me Rebelle, and I have never painted in the real world before.
Honestly after using their web page to test the mixing I lost all interest in this yes it feels like paint but is it really useful? Only for certain looks I feel. For most use cases I think it would be a detriment. But mixing with black and white I feel is where Mixbox shines more, because with colors I think YUV is more pretty.
An interesting news: Mixbox released 2.0 a few days ago.
The number of pigments has increased to 8, supporting more languages and software, and the license has become CC BY-NC 4.0.And seems to be available on Linear RGB.
Kitra is under GPL license yes, but you can sell Krita.
Then, the “non commercial” clause is not compatible because Krita Fondation won’t be able to sell Krita anymore.
After it’s my point of view about how I understand licenses. @halla in all case will be the one to decide what can be or not included in Krita’s source code (she might have better comprehension than me about all of this )
@halla For Blender I have seen commercial plugins (e.g. Substance Painter or 3dIO’s UV Packer) being shipped with two separate installs. One is a dedicated executable as a C(++) file and the other being a plugin that serves as an interface between the two. Apparently, that would be a sufficient legal basis for Adobe’s lawyers to give green light for GPL integration.
Would something like that be appropriate for Krita? Mixbox as a stand-alone module and a downloadable plugin? It certainly isn’t as neat as an integrated version, but if it saves a lot of work and helps with performance, well, it’s an option.
It really is a bit of a gray area, and I am not a lawyer. Some people argue that coding to a remote api is a problem, others say, not so. Some people think a shim between incompatibly licensed code solves the issue, others disagree.
I have mailed the Mixbox people about these questions, linking to this thread, and I’ll report back on their answer.
Apart from the licensing question, Mixbox is essentially a lookup table, and the code to generate that table is not part of the package.
In my opinion (which carries not much weight, I now), not having the complete source should preclude inclusion of mixbox into krita, except perhaps as a 3rd party plugin.
Okay, the answer was pretty clear: as long as we have Krita in any stores, we cannot use Mixbox. They offered two suggestions, one was we create a closed-source plugin for Krita that would only be available in the stores, or they would fork part of Krita and create a plugin that links to mixbox and distribute that themselves. Both would violate the GPLv3.
This demand is not urgent, is it? From my immature point of view, the biggest difficulty of the mixbox is experimental data what mixbox2.0 has given approximately, next is optimization, not technicals.
Optimistically consider that other implementations will emerge one by one after the first resolution mixbox, we can just wait.
We don’t have to use mixbox. I’m just curious whether it has become more “complete” in 2.0.This is what they wrote in their paper:
The main restriction of our approach is that the number of primary
pigments is limited to four. A practical reason is that we need to use
look-up tables for quick conversion between latent vectors and RGB
values. If there were more than four pigments, the use of the 3D
table would no longer be possible, and the real-time performance
would suffer. Another reason is that a fifth pigment would cause
ambiguities. There would be more ways to mix the primary pigments into the same RGB color. For example, if we add Viridian
Green as the fifth pigment, we can now obtain certain green hues
in two possible ways: either by mixing blue and yellow, or by using
the green pigment in its pure form. This ambiguity would cause
the conversion between pigment concentrations and RGB values
to no longer be invertible and our method would cease to work.
The four-pigment-limitation can be alleviated to some extent by
precomputing multiple versions of the lookup tables for different
sets of primary pigments and switching between them on the fly.
However, the question how to properly generalize our approach
to a case of more than four pigments is an interesting avenue for
future work.
Another limitation is that our approach only considers homogeneous mixing of opaque paints. When compositing two RGB layers
using alpha-blending, our approach treats both layers as if they
consisted of thick wet paint. A possible extension left for future
work is to add support for the Kubelka–Munk layer-compositing
model, which would enable more faithful simulation of translucent
layers and handle effects like watercolor glazing
I remember they said that the fifth pigment would be green, but they did not:
In addition, I don’t know whether other methods have solutions to “more reliable simulation of translational layers and handle effects like watercolor glazing”. Perhaps the method of real-time spectral tracking itself does not have this problem.
I have read (and understood) the mixbox paper, so I’m in a pretty good position to compare the mixbox and mypaint colour mixing methods (each has its downsides). It will take some time, though. I will do most of that work in python, will be doing my own implementation of mixbox (based on the mixbox paper), and I’m not promising working builds of Krita for testing.
Should be fun though.
And adding both to Krita is obviously a little dumb, so that’s not going to happen, but we will be making an informed choice when an approach is chosen.
Csp2.0 may add mixbox?
To tell the truth, it looks a little strange. It can only be used for mixing brush, not for ordinary brushes and layers. And “Mixed colors retain their original brightness” should not be the behavior of pigments. I have some doubts that it is LCH color space.
)
