Windows icon file passed to copyResize() does resize all image sizes in it

[arthur-tacca]

A background fact: A Windows icon file (.ico file) can contain multiple different sized images. This is used to provide optimised images at smaller sizes that look better than downsampling larger sizes. Windows documentation says "Apps should have, at the bare minimum: 16x16, 24x24, 32x32, 48x48, and 256x256."

When you pass one of these multiple-image icon files to copyResize() in the image library, it will resize all of them to the same size. It's not clear what the right behaviour is in this situation... but it's definitely not that. I don't think it's even legal to have the same size image more than once in one icon file, although it does still seem to generally work (but it looks like the first image is chosen every time).

I noticed this because the Python Flet package calls the Dart flutter_launcher_icons package, which in turn calls copyResize in image. See flet-dev/flet#6007

[brendan-duncan]

I learn something new every day :-)

The ICO code was added a long time ago and I didn't even know if it was used. I can see how this is a problem.

I think I'll have to add a flag to Image that gets set for formats that have this sort of multi-image requirement (basically it'll just be set by ICO), so that copyResize knows that it needs to proportionally resize the secondary frame images proportionally. Not sure what other options there are, as most other multi-image formats are for animation frames, which do have like-sized secondary images.

I'll get to this soon.

[arthur-tacca]

resize the secondary frame images proportionally

Ah, that's a great idea. I couldn't think what you could possibly do, but resizing proportionally is sensible and I don't think anything else could work.

Just a warning that icon images are in no particular order (and there's certainly no concept of primary / secondary images); the user of the icon is expected to scan through it to find the most appropriate size and colour depth. In fact often I'd expect to see smallest size first, but I just looked at a few random icons in Windows and saw them in all sorts of orders, including smallest first, largest first, and (for 7zip) 32->16->48. So I think you'd have to look through the images to find the largest size. (And in principle you could have non-square icons and even multiple different aspect ratios but I think if someone does that then handling it well is really not your problem.)

[brendan-duncan]

It looks like I'm going to be going down the rabbit-hole of "everything is wrong with the ico encoder". Added some unit tests that are seeing some questionable results. I'll have to clean all that up while I'm in here.

For copyResize, my current thinking is to add a bool? proportionalResize argument to copyResize. If set to true, then copyResize will find the largest frame from the Image, and that will be the resize frame. It will calculate the scaling factor that frame is getting resized to, and apply that scaling factor to the other frames.

Come to think of it, I suppose the proportionalResize argument could be true by default. In almost every multi-frame case the frames will be of equal size, so "proportionalResize" would have the same effect as the current behavior. Having the argument would then allow it to be set to false, which would be for the not-very-likely case where you have a multiframe image of different resolutions and you do want them all to be resized to the same resolution.