[BUG] Favicon download selection is suboptimal

[Doc-Steve]

Bug

When downloading favicons a suboptimal icon - not the smallest and best - is selected.

To Reproduce

Download favicon for entry with URL https://etsy.com

Settings:

The following icons are found:

Expected behavior

It should select the 551 Bytes version, which is smallest and best resolution. But it selects the bigger 1 KB version with inferior resolution. I think the optimal file size setting leads to an unwanted result. The goal is to have a balance of icon quality and database size, optimizing for minimum database size. In my opinion the goal of a smaller database size ranks higher than lower compression artifacts for a given resolution (the difference is very small in quality but often huge in file size). Setting a preferred resolution sets most of the quality aspect (not the file size - this is the parameter we want to minimize as much as possible). If more than one icon for the resolution exists, the one with smaller file size should be selected. So even for the 32x32 size the selection should be 680 byte version. But there also exists a higher resolution with an ever smaller file size, so this one should be selected instead.

My preferred solution would be to drop the optimal file size setting and just keep max. file size and optimal resolution. Procedure: Sort icons for file size. Cut list at max file size. Iterate list from low to high file size. Select the first candidate meet minimum requirement of optimal resolution (in the example the 57x57 version, with setting of 32 as optimal). If hole list doesn‘t give a hit the smallest file of the highest resolution in the list should be selected.

Max file size setting should also be able to set to lower setting e.g. 1 KB minimum (10 KB at the moment, which is huge in my opinion).

In a perfect world, if no icon is selected because of filtering criteria, the best icon (max found filesize of max found resolution) would be downscaled to optimal resolution. But this is another feature request - which would save a lot of database space … 😀

Software Version
Platform: iPadOS 16.7.7
Strongbox 1.59.8

[strongbox-mark]

Thanks for the details, it does seem like a suboptimal case here. The algorithm however does look to be behaving correctly as designed. It is selecting the icon closest to your ideal size.

In this case the optimal icon is actually higher resolution and smaller in file size than what the algorithm selects. But this seems to me an unusual scenario.

However, we could take some of your suggestions onboard for a newer algorithm at some point in the future, and your suggestion to allow more granular file size slider. Cheers for the suggestions.