-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spectrum mixing speed up by direct mixing colours that are close enough #182
Comments
Also: I noticed in the forum that we might have a floating point back end that is supposed to be a bit faster? when is that gonna come? |
Hi I was mistaken in the original issue description... so I updated a patch to speed up the spectral mixing by directly mixing colous that are close enough. |
@briend if you are still around, this would be up your alley to review. |
I think it probably makes more sense to just flip pigment mode off if a brush is slow :-) Maybe just make it exact and optimize when
|
Yeah that's how I expect it to be, in this case if the differential of colour and target rgb is within 1/50 of original colour, then it's off. It has to match a lot because a lot of brushes are just dabbling in the same places, like that acrylic brush, a lot of times things are just overlapping, mostly only dabs outside "dabbed" region would have meaningful pigment mixing. (If you apply it very lightly, the "inside" would also mix in pigment mode because the colour haven't been close enough). We can have a dynamic threshold as a setting as well.
That's why I have that equal condition first. |
Oh I didn’t know that the uint subtraction gets promoted to signed Int, so negatives are ok huh. I still wonder about comparing the alpha unassociated color (‘straight”) (r) with the associated alpha color (“premultiplied”) (rgba). Does that make sense? I also think |
Ah I see... that could be an issue, but I don't think I fully understand the logic here... I probably should not be comparing with the premult value. What would you suggest is the best thing to do? After all the goal is to eliminate "a ton of" spectrum mixing for very opaque brushes. I do have some colour differences when I apply airbrush pretty lightly and over a bit pressure, maybe that could be a case, but that could also be caused by the "very low alpha cut off" in the code, didn't check that carefully, however the current code works in my paintings pretty well, so I guess it's not that far off. Maybe just need some tweaks to those conditions. |
Here I have a patch:
Because most brushes are dabbed repeatedly around the same spot, so there are a lot overlapping, so if colours are close enough, we don't really need to do spectrum conversion, which greatly speeds up large brushes.
Results are still visually correct:
My original description which I thought it was a bug: (wrong, don't look at it)
Because spectrum mixing is ridiculously slow even with fully opaque brushes, I am looking into the code and found the spectrum switch seems to be controlled by "alpha underneath" instead of "input alpha"? Is this a typo error or am I not understanding the algorithm correctly?
brushmodes.c
line 375:I'm not sure I understood the code correctly, but I think for opaque brushes there should not be any spectrum mixing? Or if it's a different mindset I'd appreciate a more in-depth explanation.
Thanks and have a great day!
The text was updated successfully, but these errors were encountered: