Re: (resend) programs/winemenubuilder: scale 64x64 classic icons to 48x48 for Icns format
On Oct 16, 2012, at 2:15 PM, Aric Stewart wrote:
@@ -1052,6 +1079,7 @@ static inline int size_to_slot(int size) case 16: return 0; case 32: return 1; case 48: return 2;
case 64: return 2; /* Classic Mode */ case 128: return 3; case 256: return 4; case 512: return 5;
If an ICO has both a 48x48 and a 64x64 entry (improbable, I know), then the 48x48 should be preferred. So, you need additional logic to pick the best index for a slot in platform_write_icon(). Track the best-so-far's width and prefer the smaller.
Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size.
Although it might be better to synthesize a 32x32 rather than a 48x48 from a 64x64. *shrug*
-Ken
On 10/16/12 7:40 PM, Ken Thomases wrote:
On Oct 16, 2012, at 2:15 PM, Aric Stewart wrote:
@@ -1052,6 +1079,7 @@ static inline int size_to_slot(int size) case 16: return 0; case 32: return 1; case 48: return 2;
case 64: return 2; /* Classic Mode */ case 128: return 3; case 256: return 4; case 512: return 5;If an ICO has both a 48x48 and a 64x64 entry (improbable, I know), then the 48x48 should be preferred. So, you need additional logic to pick the best index for a slot in platform_write_icon(). Track the best-so-far's width and prefer the smaller.
I thought about that case and decided not to worry about it, however I will work out some logic to cover it.
Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size.
I thought about this also and was not sure if the ICNS encoder in windowscodecs was following some spec or understood behavior on rejecting the size. I know that winemenubuilder is wine specific and so doing the scaling there would not have to be windows compliant. A quick google search seems to indicate that CLSID_WICIcnsEncoder is not a windows feature either.
Although it might be better to synthesize a 32x32 rather than a 48x48 from a 64x64. *shrug*
Just because 32 is half of 64? I will admit my understanding of image scaling is poor enough that i just assumed the closer the size the better the scale would turn out.
-aric
On Tue, Oct 16, 2012 at 7:40 PM, Ken Thomases ken@codeweavers.com wrote:
Beyond that, perhaps the scaling should be put into the ICNS encoder rather than convert_to_native_icon(). That is, if it's handed a size that doesn't fit properly into one of the predefined slots, it would scale down to the next lower size.
It would be far more difficult to make that change in the ICNS encoder than it is here. I think we should avoid it just so we can keep the code simple.
I agree that scaling to 32x32 would probably work out better. Personally, I probably would've chosen 128x128, since that would involve no loss of information or distortion (but maybe we don't like the increased file size?).
I guess it also depends on what size the OS uses to display the icon. If it will usually be a particular size, we should probably take that into account, though I don't know how much we can really do about it.
On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk madewokherd@gmail.com wrote:
I agree that scaling to 32x32 would probably work out better. Personally, I probably would've chosen 128x128, since that would involve no loss of information or distortion (but maybe we don't like the increased file size?).
It's however much more common that a 32x32 icon is already present. In fact, checking my own set of wine generated icons, they all already contain a 32x32 icon. Actually, most contain a 48x48 icon as well.
I must admit I'm also no expert at image scaling, but presumably scaling twice is much worse than scaling once, right? In that case I'd say we only want to store a 64 -> 48 scaled icon only if there's no 128, 256 or 512 size icon available, as those would only be scaled once to produce the final image.
I'm not so sure it's a good idea to scale upwards, it's better to let the OS scale down an even larger size in that case, if one is available. It's quite uncommon to have larger icons though, at least in my set.
I guess it also depends on what size the OS uses to display the icon. If it will usually be a particular size, we should probably take that into account, though I don't know how much we can really do about it.
I don't think it's possible to say that it has a usual display size. Default in the Finder seem to be 64x64, but has probably changed over time. Other applications, e.g. launchpad, has larger ones and the dock is dynamic based on the number of items it contains.
Regards,
On 10/17/12 3:11 AM, Per Johansson wrote:
On Wed, Oct 17, 2012 at 6:08 AM, Vincent Povirk madewokherd@gmail.com wrote:
I agree that scaling to 32x32 would probably work out better. Personally, I probably would've chosen 128x128, since that would involve no loss of information or distortion (but maybe we don't like the increased file size?).
It's however much more common that a 32x32 icon is already present. In fact, checking my own set of wine generated icons, they all already contain a 32x32 icon. Actually, most contain a 48x48 icon as well.
The issue I am working on resolving here is that many older windows programs only provide a 64x64 icon. With the old code, because there is no 64x64 slot in icns files, these applications where loosing there icons.
Ken's suggestion of making sure we do not overwrite a real 48x48 icon is good and I will implement that.
-aric
On Wed, 17 Oct 2012, Aric Stewart wrote: [...]
The issue I am working on resolving here is that many older windows programs only provide a 64x64 icon. With the old code, because there is no 64x64 slot in icns files, these applications where loosing there icons.
If the Mac behaves sensibly when there's a a single 128x128 icon, then in the case where there's only a 64x64 icon in the source Vincent's suggestion of scaling up would seem to be better.
As far as I know, scaling 64x64 -> 48x48 will produce a somewhat fuzzy-looking icon, more so than scaling down by a factor of two like 64x64 -> 32x32. Similarly, scaling up by a factor of two will produce a blocky icon (assuming you do it by simply replicating pixels) but scaling that back down should produce the same result as starting from the original 64x64 icon. Scaling up by any other factor will produce a very fuzzy icon.
So we have the following scenarios:
Windows Icns file Needed for display Result 64x64 Fuzzy 48x48 32x32 Fuzzy twice 64x64 Fuzzy 48x48 48x48 Fuzzy 64x64 Fuzzy 48x48 64x64 Fuzzy twice 64x64 Fuzzy 48x48 128x128 Fuzzy+Very fuzzy
64x64 Blocky 128x128 32x32 Fuzzy 64x64 Blocky 128x128 48x48 Fuzzy 64x64 Blocky 128x128 64x64 Perfect 64x64 Blocky 128x128 128x128 Blocky
Even if you actually have other sizes in addition to 64x64 I think the upscaling option would actually work pretty well. So it may make sense to change the code to scale up to 128x128 unless there's already a 128x128 icon.
On Oct 18, 2012, at 9:58 AM, Francois Gouget wrote:
Even if you actually have other sizes in addition to 64x64 I think the upscaling option would actually work pretty well. So it may make sense to change the code to scale up to 128x128 unless there's already a 128x128 icon.
... or larger.
-Ken
-
Aric Stewart -
Francois Gouget -
Ken Thomases -
Per Johansson -
Vincent Povirk