Rename flood-fill "softness" to "opacity spread"
This is a follow up to !1174 (merged).
I renamed the option from "softness" to "opacity spread" after some feedback (see https://bugs.kde.org/show_bug.cgi?id=438799 and https://krita-artists.org/t/feedback-wanted-fill-tool-options-redesign-proposal). It seems that the term softness is ambiguous and can create confusion with "feathering" and "fuzziness". I totally agree, so I decided to change the name of the option to better reflect what it does. I proposed "opacity spread" in that KA thread and it seems it didn't get any push back.
Another suggested term is "opacity fall-off" or "opacity roll-off". Is that better? (English is not my native language).
The meaning of the "opacity spread" is kind of reverse to "softness" (100% spread = 0% softness, 100% spread = 0% softness) so I had to change some values.
In the MR that introduced the "softness" option I didn't explained it because I thought it was straightforward, but since it is kind of confusing I'll explain it here along with the motivation for its introduction.
Issues with the previous tools
- The contiguous selection tool had an anti-aliasing option that wasn't real anti-aliasing. It just produced a "soft" selection driven by the color similarity between pixels if the option was on, or an aliased version if it was off. This was confusing a lot of users, as can be seen in the bug report previously linked.
- The fill tool only allowed to create "soft" regions in normal mode. The only way you could create an aliased, hard-edged region, is by using the fast mode, but that prevented the user from using other options like growing the region or filling with a pattern.
How I changed it
-
I deleted the anti-alias option in the contiguous selection tool, since it was not real anti-alias. I plan to add real anti-alias in the future, something based on fxaa or similar, as long as it is fast, so that option can come back when that's done.
-
The aliased version of the contiguous selection tool was just a thresholded version of the anti-aliased one. This anti-aliased region is the same used by the fill tool in the normal mode. I introduced the "softness" option to enhance that concept by allowing to go smoothly from a soft to a hard-edged region. I think that allowing to generate "soft" regions is useful when dealing with soft transitions in the image. This option allows the user to control how "soft" is the edge of the region. But it can be interpreted in different ways: as how soft is the edge of the region; as a contrast adjustment; as how big is the fully opaque portion of the region; etc. I went with "opacity spread" and the "how big is the fully opaque portion of the region" interpretation here since I think it can evoke a more accurate image in the user's mind of what's going on.
Source image used in the following examples.
Here are some examples of the type of regions that the fill tool produced before the introduction of the "softness" option in non-fast mode. On the left column a "threshold" value of 20 was used; on the right column a threshold value of 60 was used. Blue represents the region selected. The black dot is the seed pixel. The green outline is the region extent contour.
The thresholded version of the regions. This is the method that the aliased version of the contiguous selection tool used.opacity_spread
The effect of changing the "softness"/"opacity spread". As can be seen it is just like a contrast adjustment on the mask, and when the spread is 100% the effect is the same as thresholding the region with a threshold value equal to 0 (the region would be a mask with black as transparent and white as opaque). This option doesn't change the actual extent of the region, that's what the "threshold" option does. This only changes how the opacity inside the region is mapped. -
As you can see I feel confortable with calling this option softness, it feels right if we consider the flood-fill algorithm alone, but I guess it gets confusing if it is used in other contexts, so "opacity spread" seems more suitable to me.
Formalities Checklist
-
I confirmed this builds. -
I confirmed Krita ran and the relevant functions work. -
I tested the relevant unit tests and can confirm they are not broken. (If not possible, don't hesitate to ask for help!) -
I made sure my commits build individually and have good descriptions as per KDE guidelines. -
I made sure my code conforms to the standards set in the HACKING file. -
I can confirm the code is licensed and attributed appropriately, and that unattributed code is mine, as per KDE Licensing Policy.