Thank you, but there is no android build version in this version. You can find the build version of windows and linux in the above link
Yes, if it is successfully merged, it can be used in the next version after the official version of 5.0
@urzeye Ha, ok. My test were all using the default 8bit sRGB colorspace. But if the code comes from Mypaint, it makes sens ( Mypaint never really had a 8bit canvas. I remember this, and later the linear compositing and spectral blending work of Brien Dieterle).
I’ll retest, but as @Lynx3d said, it’s highly likely that this calulations might be (unfortunately) only limited to a specific color setup.
@Yundong : Hi, the feature is right now still very alpha. It will require some work, review, test, before being part of an official release. None of the spectral mixing code here is ready to be part of Krita 5.0.0 for sure. It will take time before happening in future versions if main problems can be solved.
It is going to be implemented in some of updates 5.x after testing.
Hi
Please, just read what people are writing… in all topics on which your asking something, people spent time to give you answers that it seems you don’t read
@Deevad wrote to you:
So no, you won’t find it in Krita 5.0
Maybe in Krita 5.1 (but maybe)
Grum999
And
Grum999
this looks awesome!
Do anybody there have windows build?
Hi
Link to windows build is provided in this topic…
Grum999
goggle drive one? can’t download from there - do not have permission
You have to request permission to @urzeye to access file
Or maybe @urzeye can change the permission to let everyone download the test build?
Grum999
I already did couple days ago but seems @urzeye didn’t have time yet. It would be extremely nice to have it available for everyone to test.
@urzeye Is there any progress on this project?
This is the original solver used to produce the spectral color matrices in MyPaint for the sRGB colorspace: mypaint/doc/spectral/rgb_to_spectral.py at master · mypaint/mypaint · GitHub
There are caveats with changing these matrices; basically the same as swapping one color profile with another without transforming the colors. So it’s kind of good they haven’t changed. That said, I’ve been fiddling around with a new solver that is a lot more sophisticated. Maybe it can be improved:
I use this to produce matrices for wide gamut color space (display P3). There’s a bunch of things the solver tries to accomplish, which could be modified or extended for creative purposes.
It seems like ICC color profiles will eventually be able to handle these spectral conversion matrices, but until then there is a problem waiting to bite people’s files. One solution could be to sidecar some metadata describing the matrices used for each file, in other words, reinvent ICC profiles. Or, just like sRGB, treat the absence of this information to mean those canonical MyPaint matrices were used, and kick the can down the road a bit :-).
I tried out the build and I’m blown away by your work! The performance is great and I’ve encountered no issues whatsoever. I see no reason why this cant be merged into the next update.
Thank you for your feedback!
Hi, @Deevad on the issue of spectral mixing, I recently made a new discovery. In krita, we can greatly improve the performance by changing the brush tip spacing. The code does not destroy the curve setting in the smudge length option, but because the foreground color ratio of the new smudge algorithm is only affected by the opacity option, while the old version is also affected by the smudge length option, so after using the new smudge algorithm, curves that adjust the smear length will no longer affect the foreground color ratio
As for using spectral mixing in 8-bit nonlinear space, we only need to convert nonlinear RGB into linear RGB first, and then perform spectral mixing operation, just like HSY
From my user/beta-tester point-of-view, what you are writing doesn’t make sens, sorry.
But, as you use ‘we’, I’ll assume you are a including yourself in the Krita developpers of this branch/MR.
As you use “only need”, I understand this change is something trivial for you or is already solved in theory for you.
Good, in this case, go ahead, fork the branch and tweak the code to make it happen.
Sorry, I use translation software, so there may be semantic ambiguity. However, the conversion between nonlinear sRGB and linear sRGB is indeed easy. Krita has such a function, which only needs to be called. However, since I am not a programmer, I can’t add setting options for krita for users to switch. I can only modify the original part of the code to realize it, but it will lose some of the original functions. So it would be great if developers could add setting options