lunapaint / vscode-luna-paint

A raster image editor extension for VS Code
https://marketplace.visualstudio.com/items?itemName=Tyriar.luna-paint
279 stars 25 forks source link

Flood fill blend mode support #101

Closed breedlovedesign closed 2 years ago

breedlovedesign commented 2 years ago

Issue Type: Feature Request

Great work on the Flood Fill tool! Contiguous/Global modes and Tolerance setting make it very powerful.

TLDR; Retain current behavior for the Flood Fill tool, call the mode 'Normal', and use it as the default. Add a 'Simple' mode for the Flood Fill tool that changes its behavior to setting all affected pixels to the exact RGBA values chosen by the user. Hopefully this will not alienate existing users, be fairly discoverable, and leverage existing code.

The discussion below is about user expectations in part, but it is also an argument not to close this request as a duplicate of existing issues on selection or eraser functionality. I am arguing against the status quo for image editor conventions only after repeatedly seeing kids look at the situation in a way I didn't expect. Whatever you decide, please know I am forever grateful for this awesome extension.

I am a trained artist, a certified teacher, and amature programmer. I tutor elementary and junior high aged students on coding and all they wanna do is make games. I'm having them make sprite sheets and whatnot. I really almost have everything I need from this amazing extension. Removing background pixels is not the only use case here, there is also smoke, lazors, and ghosts. Our metaphors of paint and erasers don't connect with these kids as well as we imagine.

Transparancy is a characteristic that one would like to be able to add to pixels the same way one can add color. One may argue that this is unintuitive, or that this functionallity is conceptually more the domain of an 'eraser' tool but I think the issue is more subtle than that.

Currently, when filling with a partially transparent color it is difficult to predict the outcome. Especially when using the tool repeatedly.

For example, consider starting with a white canvas 255,255,255,255 and a chosen color of faint red 255,0,0,4

First use of the Flood Fill tool does not result in a canvas of all faint red pixels, rather, the alpha remains maxed out at 255 and the hue is shifted toward red by the amount of alpha in my chosen color, 4. The resultant opaque pink is 255,251,251,255. If I do this 63 more times I imagine I could get to fully opaque red 255,255,255,255 but instead I only get to 255,92,92,255. Weird... Whatever. Color is weird so how many clicks DOES it take to get to solid red? You can't after 60 or so more clicks you get close, 255,31,31,255 and no matter how many more clicks that's as far as it goes.

This behavior seems to be purely mathmatical and not at all like paint. I love the magic of digital tools, I wanted all these white pixels to become faint red ones on the first click, but I fully understand I am likely to be unusual in having this intuition. However, it is not like watercolor either. Even faint watercolor applied repeatedly will get you to a fully rich red.

And, in fact, this is the current behavior if the alpha is 128 or above. 8 applications of 255,0,0,128 will arrive at 255,0,0,255. I'm sure the math is sound but the asymetries are unintuitive to me. Firstly, in terms of number of clicks required to reach equilibrium it is over 100 for low alpha values and only 8 clicks max for 128 and above. Secondly, the equilibrium point to be reached is only intuitive in the 128 and above case; get all the way to solid red pretty quickly. The case for under 128 alpha ought to be 'get all the way to solid red pretty slowly, no?

If the feature request is going to be rejected let it not be argued that the justification for doing so is trying to keep the Flood Fill tool conforming to user intuitions. It may be conventional behavior but I assure you these students of mine have made me think it is not intuitive.

Thanks for coming on this journey with me, whether you agree or disagree I hope you find something useful in the ideas touched on here.

Extension version: 0.9.0 VS Code version: Code 1.60.2 (7f6ab5485bbc008386c4386d08766667e155244e, 2021-09-22T11:59:27.195Z) OS version: Darwin x64 19.6.0 Restricted Mode: No

Tyriar commented 2 years ago

Glad to hear you're enjoying the extension 🙂

Correct me if I'm wrong but what I think you're describing is the desire for blend mode support when using the fill tool. Right now flood fill blends using the "normal" mode of other tools:

image

But you want "replace", which doesn't blend at all but replaces all channels of the color completely:

image

It's a little unclear whether you want 255 alpha in your result instead of 4, but I'd argue the former is pretty confusing and inconsistent with how other tools work.

Another way to do this eventually as you have probably seen from the other feature requests will be to use the magic wand (which will also support tolerance), clicking delete to erase the complex selection and then filling that empty area. Full support for blend modes in the fill tool should be easier to accomplish than that though.

breedlovedesign commented 2 years ago

Awesome! You were able to make sense out of my confusing rant. Good on you.

Being able to select different blend modes for the fill tool will totally meet my needs and also enable all sorts of other cool possibilities.

I imagine implementing the magic wand tool is no small task. Be sure to also recreate all the functionality of Photoshop while you are at it. 🤣 But, seriously, this was a really positive interaction and I hope other users can find ways to benefit from your proposed enhancement.

Correct me if I'm wrong, but I'm closing this issue because you added blend-mode support for the flood fill tool to the 0.11.0 milestone, making this issue redundant. Happy coding!

Tyriar commented 2 years ago

Not yet, I plan on implementing it for 0.11.0 which should come next month. I'll close this issue out when it's done 🙂