Add 20px, 40px bitmaps; Regenerate all icon bitmaps

[0tkl]

Fix #315. Because it's been a long time, I'd like to repeat it: my motivation was to generate 20px bitmaps because a 16px toolbar was too small for me, while 24px was too large.

I then tried updating the existing bitmap sizes with similar code and found they looked slightly clearer (thanks to a good amount of ringing effect), so I'm posting those as well. Note that this PR did not touch the two icons mentioned in #496 to avoid conflicts. The current results are still far from perfect, mainly because text in small bitmaps is still blurry. For a truly excellent visual experience, I estimate we'll have to manually create those mini bitmap texts.

The new resolution added in this PR isn't limited to the single option. I welcome feedback from people using various resolutions on what icon sizes are most suitable for them.

[arch1t3cht]

How did you generate these bitmaps? You mention them looking clearer due to strong ringing artifacts, but I think that actually makes them look worse:

Even if one wanted to add sharpening to make the bitmaps clearer (though I'd think that there are better ways to do this, seeing as the actual SVG sources are available and can be adapted to fit pixel grids if necessary), this looks excessive, since it adds two sharpening lobes.

Also, if you used a script to generate all bitmaps, it would be nice to also add such a script to the repository (which would ideally work in a deterministic and idempotent way) and use that for future bitmap generation.

[0tkl]

I subjectively believe that for non-integer ratio scaling, "scale up then downsample" is the more correct choice, while for integer ratio scaling, the direct result is good enough. Anyway, to avoid getting into bikeshedding, I'll upload a set of bitmaps rendered at a 1:1 scale. If you are satisfied with the 1:1 rendering result, I can replace the icons from the previous few commits, force-push to here tomorrow. (Or a more concise commit would be to not regenerate the existing bitmap.)

[arch1t3cht]

I'm not opposed a downsampling approach for non-power-of-two sizes in principle if those turn out to work well, my observation was just that the bitmaps you pushed did not look good. (And, if I recall correctly, the screenshot I attached above was of a 64x64 bitmap, where this wouldn't even apply.)

"Scale, then downsample" is also still a very general description and will depend a lot on what methods are used for the scaling and downsampling. Downsampling using a gaussian kernel will behave very differently from downsampling using a ringing kernel like Lanczos. I'd be interested in an exact description of how you generated those bitmaps and/or how you propose to.

[0tkl]

will behave very differently from downsampling using a ringing kernel like Lanczos

Yes, the two kenels I tried were Lanczos and MagicKernelSharp2021. They all appear to be kernels that would create too visually noticeable ringing. The former has a more exaggerated ringing effect than the latter, so the icons I uploaded at Dec 18th were all generated using the latter.

I will try to switch to kernels with less pronounced ringing later.

[arch1t3cht]

I see, that checks out. Neither Lanczos nor any magic kernel variant (setting aside all the other problems I have with the whole "magic kernel" story) are in any way suitable for downscaling. The way that most conventional resizing tools implement downscaling (by horizontally stretching the kernel by the downscaling factor) completely changes the kernel and makes downscaling completely different from upscaling. There is no reason why a kernel that works well for upscaling should work well for downscaling using this method.

If you do want to use this form of convolutional downscaling, Hermite (b=c=0 bicubic) and Gaussian are generally agreed to be the best kernels. But, as I've said, I have yet to be convinced that downscaling is even beneficial at all here.