What is an ideal size for a .ico file, that would sit in the top corner of a window?
Short answer: 16 x 16 pixels.
Long answer:
.ico files can actually contain multiple images, at multiple colour depths - you can provide 16x16, 32x32, 48x48 and 64x64 in a single file and the OS will pick the best one to show.
Of course to keep the file size low you don't want to put too many in there, but if you think people might be saving a link on their desktop (say it's a web application) then it's probably a good move.
See Microsoft's recommendations.
Basically, 16x16, 32x32, 48x48, and 256x256 for application icons. I guess the window icon is a toolbar icon so 16x16, 24x24 and 32x32.
To originally figure this out when wanted to start making .ico images I opened a good looking icon already being used in Windows 11 with GIMP. I found nine layers 256 128 64 48 40 32 24 20 and 16. So this is kind of the formula I've been following creating the icons in Gimp and none of my icons fail ever they always display no matter what size they are.
With GIMP you can take any single image and turn it into a multi-layer icon, you just have to know how to do a bit of image editing.But it %100 free.
Related
I am currently working on a GUI at a Windows 7 64-bit PC. While comparing the visualisation of text in different programs, I recognized, that there are differences in how big text is displayed on my monitor, given the same text style and size.
Does anyone has an idea where this comes from?
I created this behaviour by typing a text in Arial Regular 12pt containing the letter T in a program and scaling the view to 100%. Afterwards I measured the height of the letter T in pixels with the help of a screenshot.
Programs I testet:
MS Word 2010: T is 12 pixels high
LibreOffice Writer 5.2.7.2 (x64): T is 12 pixels high
Scribus 1.4.6: T is 12 pixels high
GIMP 2.8.14: T is 9 pixels high
Java 8 Update 181 (which I use for my own GUI): T is 9 pixels high
pt (point) is a unit for physical sizes, typically 1/72th of an inch.
In order to transfer this to a size in pixels, you need to know how many pixels will be in one inch on your screen. This value is known as Pixels Per Inch (PPI), sometimes somewhat ambiguously called Dots Per Inch (DPI).
Note that this value will usually be different for an application UI and the documents you are working on.
From the values you provided, it looks like MS Word, LibreOffice and Scribus assume 72 PPI (or at least the documents you are working on do), whereas GIMP and Java use 96 PPI.
It's not obvious whether you are referring to the size of text ion the respective applications' UI or documents opened in them, though, so I could be totally off.
I have a native MFC C++ application for which I've got a ribbon UI based version and a toolbar based version. Both EXEs are similar size (~30mb), but running the ribbon based version takes about 25s whereas the toolbar version takes about 5s. This is just to get the frame window displayed with tools. I've profiled the start up of the ribbon UI based version, and sure enough the time is being spent in CMFCRibbonBar::LoadFromResource and deeper down in
BOOL CMFCRibbonInfoLoader::LoadImage(CMFCRibbonInfo::XImage& image, BOOL bSingle)
{
'
'
'
image.m_Image.SetTransparentColor(GetGlobalData()->clrBtnFace); // 15%
image.m_Image.SmoothResize(dblScale); // 64%
'
}
Digging deeper, a lot of time seems to be spent manually shading the toolbar ~44% of the total time.
Is there any way to speed up this load time, possibly by setting a non-transparent drawing scheme? 25 seconds to run a program seems a bit excessive, this is on an 8 core 4ghz AMD 8350 with the EXE image coming from an SSD.
Edit: Tried the following which helped understand the problem but doesn't really make for a useful answer.
After some poking around, it seems a call to afxGlobalData.EnableRibbonImageScale(FALSE); disables the scaling but can leave poor results visually on some monitors. If the image sizes are correct for the monitor to start with, 40x40 pixels on my 1920x1080 display, the scaling will also get skipped. I haven't tried it yet, but I'd imagine if you specify HDPI images for all the ribbon controls and you are lucky enough to get 1:1 scaling for your HDPI images, it would also get skipped. Searching the MFC source code (\Program Files (x86)\Microsoft Visual Studio 14.0\VC\atlmfc\include\afxglobals.h) for m_bIsRibbonImageScale and m_dblRibbonImageScale yield most of the relevant code.
If the large button images aren't 32x32 the ribbon editor seems to treat them as they were, and chops the base BMP up incorrectly. So resizing a the base large button BMP to 40x40 resulted in garbage on screen.
Edit: I had thought Vlad's answer would work, but apparently the XML used in an MFC ribbon resource is not Ribbon XML. See related question on MSDN here.
Edit Further discussion on MSDN here
The page Specifying Ribbon Image Resources states:
For any image, the exact pixel size is dependent on the display
resolution, or dots per inch (dpi), of the monitor being used. At 96
dpi, large images are 32x32 pixels in size and small images are 16x16
pixels in size. The image sizes increase in a linear fashion relative
to dpi as illustrated in the following table.
DPI Small Image Large Image
96 dpi 16x16 pixels 32x32 pixels
120 dpi 20x20 pixels 40x40 pixels
144 dpi 24x24 pixels 48x48 pixels
192 dpi 32x32 pixels 64x64 pixels
The Ribbon framework scales image resources as required. However,
because resizing may yield undesirable artifacts and image
degradation, it is highly recommended that the application provide a
small set of image resources that span various commonly used dpi
settings. If an exact match is not found, the nearest image will be
scaled up or down.
To facilitate this, image resources can be declared in Ribbon markup
by using a set of Image elements for each Command element. At run
time, the framework selects the image to display based on the MinDPI
attribute of each Image element.
There is an example at the bottom.
Problem solved: Configuration -> Manifest Tool -> Input And Output -> Enable DPI Awareness NO
NO, is the solution. The default value is unfortunately YES.
When I try to do some research on making icons for Windows, and what size/resolution images I should leave in my .ico files before saving, there's too much weird information.
Some say put 16x16, 24x24, 32x32, 48x48 ... and so on in 96 DPI.
This is what irks me, and I feel it doesn't make any sense.
Isn't 1 pixel = 1 pixel?
Why do they insist on mixing DPI into this?
What is always true is that 1 pixel = 1 pixel. What does change is how big that pixel is on various displays that have different screen densities. That is what DPI describes - number of dots (pixels) per inch. But using DPI in context of image size only makes sense when you use it in combination with inches (centimeters). For instance "create image 10x10 inches at 300 DPI" and from that statement you can calculate that image has to be 3000x3000 pixels in size.
As far as Windows is concerned what does count is font scaling setting that can be set from 100% to 200%
So when you are creating your icons make sure that you have at least 1x and 2x dimensions. If the icon has to be 16x16 pix under normal resolution, that means that you would also create 32x32 pix icon. Other commonly used scaling are 125% and 150%, so it would be good idea to provide icon for those sizes too.
You can freely ignore statements like "Make the icon x pixels wide and x pixels high in x DPI" because those people have no clue what they are talking about.
I've written a Shell Icon Overlay handler that contains a multi-image icon with 256, 48, 32 and 16 bit icons. The overlay bits are in the lower left corner, and respectively are 32, 15, 10 and 6 bits.
In Windows Explorer, with the View set to Small, the icons are 16 bits and the overlay selected consumes 6 bits. Medium icons: 48 bits overlaid with 10. All as I expected.
When the View is set to Large, a 96 bit icon is used, which is overlaid with 15 bits. Whether this is the 15 bits from the 48 bit overlay, or downsampled from the 256 bit, I can't tell. If I add a 96 bit overlay to the multi-image, using 32 bits for the overlay (just as a test), the overlay used still appears as 15 bits.
When the View is set to Extra Large, the overlay used is still just 15 bits. Just a splotch on a very big icon.
All of the above is on Windows 7. On Windows 8 desktop, the same results are seen, EXCEPT that the Extra Large icon is now only overlaid with a 12*12 bitmap, clearly downsampled from a larger size (15? 32?)
Can anyone help with a definitive answer for what size overlays I should be providing for maximizing the viewing experience?
If you see on overlay icon of lnk file in imageres.dll you will see that icon contains the following formats:
48x48x16
32x32x16
16x16x16
48x48x8
32x32x8
16x16x8
256x256x32
48x48x32
32x32x32
16x16x32
I think if Microsoft uses such formats for internal overlay icons it is optimal variant to use the same formats too.
I have a VB6 application and one of the Form icon is set as application icon. The problem is that in Windows 7 the icon looks blurred even though the icon contains 16x16, 32x32 and 48x48 sizes.
Is there a way around this problem? It tried the SendMessage(... SETICON... ICON_BIG) but it does not seems to work.
What colour depth are the icons in your ico file?
VB6 (I believe) supports a maximum 8 bit colour depth (256 colours) for icons:-
So if there is no size 48 x 48 icon in 8 bit colour depth it could be using the nearest match and scaling it to 48 x 48
EDIT:
I just tried this using an icon that did not have a 48 x 48 icon at 8 bit depth (but did have 48 x 48 at higher depths) and the icon used in the taskbar was the 32bit icon at 8 bit colour depth.
I don't claim to understand the full heuristics used to choose the icon image to display in various places, but I think what is happening here is that your 48x48 image is being taken and scaled down.
I suspect what happens with a VB6 program on many versions of Windows is that if there is no 16-color 16x16 image then a larger size gets taken and scaled. The reason may simply be due to the order of the images in the ICO resource/file.
If you edit your ICO and add a 16-color version of your 16x16 image your "problem" may disappear.