Thumbnails for icon files without scaling?

I would like Opus to always show the largest iconsize available in an ICO file without scaling when Thumbnail mode is ON.

Opus Thumbnail size = 32 -> show 16x16 icon OR 24x24 icon if available OR 32x32 icon if available
Opus Thumbnail size = 48 -> show 48x48 icon if available
etc ...

I have a lot of ICO files for the new toolbar icons with only one format (48x48). Opus scales them down
(Opus thumbnail size is set to 48) and I can't use Opus to test them this way:

And this is how Windows Explorer shows them (and how I would like to see them in Opus):

Do I overlook a setting and/or would it be possible to implement this in Opus?

I don't want to use Windows Explorer again :smiley:

Could you send me some of those .ico to try with?

I don't see anything that bad here, but maybe it's to do with the sizes or types of icons:

Hi Leo, I just sent you some icons by mail.


I see why it's different to mine now. My 48x48 icon also had a 32x32 version inside it, which is what was being used.

Opus only uses the 16x16, 32x32 and 256x256 shell icon caches, so icons that only have 48x48 versions must be coming from the 32x32 or 256x256 cache and being scaled down.

We avoid using the 48x48 shell icon cache intentionally, since it's such a rare .ico size (at least by itself; there's usually a 32x32 and/or 256x256 icon, with the 48x48 version only being useful for a very narrow range of thumbnail sizes) and enabling the 48x48 cache at all costs several extra MB of RAM to be allocated to dopus.exe (every icon that gets loaded, whether it has a real 48x48 version or not, and whether it is displayed in that size or not, gets a 48x48 version generated (if needed) and added to the cache).

The reason it works within zip archives, and also in the viewer pane for that matter, is that they both get the icon via another method. Their method is generally slower than using the shell cache, which is why it's not used for normal .ico thumbnails. Within archives, the shell cache can't be used as the shell doesn't know how to read the file at all. Within the viewer, it think it was just convenient (and a happy accident) to use the method that in this case happens to give the better result, and that the slight speed difference doesn't matter when only loading and painting a single icon.

Maybe we can add an advanced option to either enable the 48x48 cache or have the slower method used for all .ico thumbnails...

Thanks, Leo, for your in-depth explanation, that definitely makes sense. But I'm looking forward to a solution
for this in the future, because personally I think icons shouldn't be scaled at all when there's no need for it.

BTW: The 48x48 icon size is a standard icon size and not so rare :wink: ... con-sizes/

Yep, I didn't mean to suggest it was a non-standard size, I just haven't seen it used in many places and have encountered very few .icos with 48x48 that don't also have 32x32 (and often 256x256 these days, which can be scaled down well until the 32x32 size is reached, making the 48x48 seem redundant a lot of the time).

Of course, when the only size is 48x48 then it's not redundant.

BTW, the awful scaling seen with the 48x48-only icons is because that's what Windows itself uses when the 32x32 version is requested and has to be generated from the 48x48. Windows uses an icon scaling algorithm build for speed rather than quality (maybe it's a compatibility constraint). You get nicer scaling when Opus does it itself.

I've been experimenting with enabling support for 48x48 icons in thumbnails mode.

An option for this will be added in a future version, but it won't be on by default.

Unfortunately, there are some trade-offs due to the poor design of the Windows icon APIs.

Icons with a maximum size of 32x32:

  • Look awful if 48x48 icons are enabled.
  • Look their best if 48x48 icons are disabled.

Icons with a maximum size of 48x48, but with 32x32 versions to fall-back on:

  • Look their best if 48x48 icons are enabled.
  • Look good if 48x48 icons are disabled.

Icons with only 48x48 versions:

  • Look their best if 48x48 icons are enabled.
  • Look awful if 48x48 icons are disabled.

Icons with a maximum size of 256x256:

  • Look great regardless.

It is common for icons to have 32x32 versions and not have 48x48 versions. Those icons turn into a blurry mess if you enable 48x48 icons. (See setupugc.exe and sigverif.exe in the second screenshot, below.)

(Windows itself is doing that awful scaling. When we ask Windows for the 48x48 icons, Windows says, "yes, this icon has a 48x48 version, here it is", and hands us a version of the 32x32 icon that it has enlarged itself using the world's worst scaling algorithm. There is no way I know of to turn that scaling off (without ignoring 48x48 icons entirely), nor to reliably detect it is happening, without replacing everything to do with finding, loading and rendering icons with custom code, which would be a compatibility nightmare (it ties into exe-parsing, filetype and registry stuff, not just .ico files) and cost too much in terms of time, effort and bugs.)

On the other hand, it is extremely uncommon for icons to only have 48x48 versions.

So, enabling support of 48x48 icon sizes makes a rare case look good at the cost of making a common case look bad. (On top of using extra memory for every icon.) Not a good trade-off, IMO, but we'll add an option for it.

Hi Leo, I really appreciate your efforts to even find a solution for something that might only be my personal problem :slight_smile:

But actually it's a more general scaling problem (not just a 48x48 problem) So, I was wondering: wouldn't it be a better idea (if possible)
to add a general (not just for 48x48 icons) advanced option to generate icons outside zip files with the same method as within archive
files / viewer pane (no problem for me if it's a slower method), because that's exactly the behaviour I would like to see.

For example, when I was designing the 22x22 toolbar icons for Opus, I had exactly the same problem:

Opus scaled them up, but inside zip files I could view them without scaling:

We might be able to do that as a special case for .ico files.

I don't think it will be feasible for icons in general (e.g. .exe files).

How come you don't use PNG instead of ICO for these single-size images?

No problem if it isn't feasible for icons in general (e.g. .exe files). I use ico files, because I design icons in Iconworkshop.
Iconworkshop saves the images as ico files. To use png files, I have to constantly import and/or export the files as PNG.
(and some programs slightly change the colours of PNG files for some reason when saving them).

So it's easier / safer to use the .ico format.

I've done that and it seems to work, so far at least.

Makes sense to use .ico if you're using IconWorkshop, certainly.

Wow, this is just fantastic, many thanks for implementing this in the new beta!!! :thumbsup: