Rainmeter Forums

RM: r2076

Without ImageTint: http://puu.sh/42txG.png

With ImageTint: http://puu.sh/42tyD.png

the Icon has 4 different states: http://puu.sh/42tzC.ico and I kinda expected it would choose the same sub-icon when tinted with another color.

After two years I tried testing it again and it still behaves the same. The only workaround I found so far is not using icons or use icons with only your specified sizes.

Another option would be to notice it in the documentation, that ImageTint chooses the lowest size icon in the *.ico file

Could you upload a simple test skin (in rmskin format) showing the issue? Also, could you re-upload the results you are seeing since the links in your original post no longer work.

I cannot guarantee that anything can be done to remedy this problem easily, since we rely heavily on the generic functions to handle our images.

-Brian

PS - I would like to apologize on behalf of the team that we did not get to this problem earlier. Due to the little amount of time we can actually spend working on Rainmeter individually, we often forget to tackle problems/issues in lieu of adding new functionality.

Here is a simple .rmskin that demonstrates.

Note, ANY Image option on the meter borks the image. ImageTint, ImageAlpha, ImageRotate, ImageFlip, any of them.
That icon has 48, 32, 24 and 16 pixel RGBA formats included.

When you load it as an image, the W and H "resize" that you specify plays a role. If you don't size the meter at all, it will use the smallest format in the .ico file. If you size the image, it then looks like it is picking the size "closest" to the requested size that is in the .ico file, and sizing that to the W and H.

However, if you add any modifying option to the meter, then that breaks down, and it just always uses the smallest format from the file, and literally "stretches" it to the defined W and H. A 16 pixel image stretched to 128 pixels is always going to be a bucket of fail.

If I remove all the formats except the 48 X 48 version from the .ico file, then it works as expected:
As Brian said, this may well be an issue with the standard image loading capabilities of GDI+ (the rendering engine Rainmeter still uses for Image meters) and there may not be much we can do about it until we convert our image functionality to D2D. I'm sure he will take a run at it however.

Just as an aside, if you want to extract any particular size from a .ico file (or .exe or .dll etc.) and create a nice .png of it to use in a skin, this is free and works really well:

http://www.howtogeek.com/109347/extract-high-quality-icons-from-files-using-a-free-tool/

http://www.becyhome.de/download_eng.htm#becyicongrabber

If you extract the size you want (or the closest to the size you want) from the .ico to .png, then you can use ImageTint and other Image meter options on it successfully. When possible, I would always extract the size from the .ico file that is the same or larger than what you are going to end up with in the skin. "shrinking" an image a bit with W and H is almost always better looking than "expanding" it.

Here are some Windows files with over 1,000 system icons you can play around with:

C:\Windows\System32\Shell32.Dll
C:\Windows\System32\imageres.dll

C:\Windows\Explorer.Exe
C:\Windows\System32\AccessibilityCpl.Dll
C:\Windows\System32\Ddores.Dll
C:\Windows\System32\GameUx.Dll
C:\Windows\System32\MorIcons.Dll
C:\Windows\System32\mmcndmgr.dll
C:\Windows\System32\mmRes.Dll
C:\Windows\System32\NetCenter.Dll
C:\Windows\System32\netshell.dll
C:\Windows\System32\networkexplorer.dll
C:\Windows\System32\PifMgr.dll
C:\Windows\System32\PniDui.Dll
C:\Windows\System32\SensorsCpl.Dll
C:\Windows\System32\SetupApi.Dll
C:\Windows\System32\wmploc.DLL
C:\Windows\System32\wpdshext.dll
C:\Windows\System32\DDORes.dll
C:\Windows\System32\compstui.dll

Brian has stumbled onto a "work-around" for this that might help for the time being. We are actually at a bit of a loss as to why this works, but it does. We will keep looking into the underlying issue, but it seems to be baked into the GDI+ routines we use, which we obviously can't modify.

If you use a !SetOption to set the ImageTint on the meter, so it happens "after" the initial creation of the meter when the skin is loaded, then the ImageTint works fine and doesn't cause it to go back and get the first / smallest image from the icon.

Hi all

Same problem with "Greyscale", but the "work-around" works here to.