Palette Tin is a Krita Docker plugin designed to help with color mixing and palette management. Inspired by the Art Academy mixing interface, it aims to make painting more fun by reducing the need for micromanaging color picking and mixing outside the canvas.
Why PaletteTin?
PaletteTin is built to enhance your painting workflow by:
Make color mixing a satisfying and fun experience
Making color mixing more intuitive.
Avoiding micromanagement in color selection.
Embedding your palette history within the document for easy reference.
I really like using this plugin for my watercolor art. I wonder if this is still being developed? It’s been a while since it released.
I’d really like there to be a feature to adjust the amount of color trays and tubes for a palette, as well as showing the mix percent alongside the slider.
Glad you like it! The plugin is basically done and currently in the testing stage. It includes all the features I originally planned, and I’m already using it myself. I’ll keep a backlog of new ideas and add more features over time. Thanks for your suggestions!
I get the need for this feature, but unfortunately, I won’t be implementing it. Making it adjustable adds too many pain points in both UX and potential bugs, and as a solo project, it would quickly become unmanageable.
There are a few workarounds though:
Save palettes and switch between them, that’s what I do for larger or more complex projects.
Use the scratchpad to store some colors.
Color-pick directly from the canvas.
What might be on the table is adding an extra column, but honestly, I feel 48 colors is a solid amount for most projects.
Sadly, this breaks one of the core principles of the project: avoiding micromanagement in color selection.
There’s no noticeable difference between 50% and 51% when mixing colors, and since colors can shift slightly during export anyway, it doesn’t really add any real value.
Speaking of the scratchpad, I’ve been having issues using it. It seems that the clear button is the only part of it that works. I can mark on it, but I can’t colorpick from nor move it around.
Before accidentally nuking my krita settings in a move from my steam deck’s steam os to cachy linux, I had a personal edit of this plugin. From what I can remember, I completely stripped out the scratchpad stuff, which I don’t think was working for me anyway, and split out the toggle between ovals/rectangles onto a separate button than the lock/unlock setting. My ideal workflow was going to be to always select when left clicking, and always mix when right clicking, but I couldn’t get it working in the 15 minutes or so I spent blindly hacking on stuff. I definitely got bitten by the default deleting the default palette aha. @josepabloespinoza let me know if you’re interested in some of those changes, I remember they didn’t take too long.
Wow, I clearly misremembered about how easy it was to make changes. Not being able to easily reload the plugin without restarting Krita is brutal. I’ve forked and pushed my changes up on github here (which among other things does include a numeric label for the slider, although that’s pretty unrelated to the general UX flow change).
I tested it, and you’re right, weird error. I’ll look into it, thanks for pointing it out! In the meantime, the stylus left-click color picks, and right-click pans the scratchpad.
That’s a good idea! I actually tried something like that before but couldn’t get it to work in a way that felt right. It also makes things harder to document and showcase. For example, I do something similar with color picking and panning using the scratchpad, but it’s a feature that’s tricky to explain to new users, that’s why I went with the 3-way mode switch.
Great work! I really like what you’re going for with the crosses. I think I’ll make the empty trays outlined boxes instead, so it’s a bit easier on the eyes. I’ll add that to the backlog.
For anyone else reading this thread, feel free to share your suggestions or ideas here or on GitHub. I have a clear vision for future updates, but I’m always open to new ideas. Cheers!
One of the things I want to do is overhaul saving - it seems to me that there’s no reason the save format couldn’t be more self-describing, and thus allow for variable palette sizes.
I encourage you to go for it! When reworking the saving feature, there are a few key things to keep in mind:
Changing how user data is stored should come first. The current format risks overwriting saved palettes as updates roll out.
The save format should include a version number to help manage compatibility in future updates.
Whatever schema you choose for the new palette format, it’s best to keep RGB as the main color model. It has the widest range of color mixing algorithms available.
As for variable palette sizes, it’s not a technical limitation. It was a UX decision. There are a lot of edge cases and potential bugs involved, and I simply didn’t have the time or interest to handle all of that.
Good luck! And if you have any questions about the code, feel free to ask me on GitHub.
