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.
Related
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.
After reading posts on this site and others, I am uncertain what pixel width I should make for a background cover image. For retina devices it is recommended to create a background image x2 the size if for a non-retina device.
I want to create a background image that will cover the entire screen but this would make a retina device image 2560 x 1760 and non-retina 1920 x 1200 if accommodating large monitors.
Is this too big?
I can't keep the jpeg image file size down to 276KB and that is with the most compression I can apply without destroying the image quality
Well your question is very interesting. To address your comment about what pixel width you should design your background image for. The size of a screen for a laptop, or desktop can vary. So you'll never exactly be able to make a single "universal" image for all backgrounds. Generally diagonal display in inches decides the amount of pixels. My screen is quite large, roughly the biggest size commercially purchased by public. Which is of course 1600 x 900 pixel, 17.3" diagonal display. I wouldn't recommend designing images for any display larger because those displays are custom and more for people who do things like graphic design themselves. Visit http://nodejs.org/logos/ If you scroll down to the computer display, you can see a list of pixel ratios that nodejs designs its logos for. These are very mainstream and popular display sizes. I would recommend you do the same and use those. Hope this answer helped.
Edit: nodejs builds for quality up to 2560 x 1440. If the size of the files doesn't matter. You should easily be able to build for sizes this large. Hope this helped.
I'm totally new to photoshop and I need to do something I don't really know how.
I got a picture with 100 dpi. We want that picture to be printed on a poster. I need to increase that 100 dpi to 300 dpi.
In photoshop, I went to Image/Image size. I uncheked "Resample Image", switched 100 pixel/inches to 300, but the document size has decreased. The thing is that I do not want to change the poster size. Is the "document size" the same as the poster size? If yes, what should I do to conserve the actual size with increasing from 100dpi to 300dpi? Is growing the image size from 3x is the better solution?
Thanks.
Photoshop, for all the power it has, is still a raster image editor at the core. DPI settings are simply a conversion factor. If you want a larger image, you'll have to increase the canvas size, or REDUCE the dpi setting
e.g.
100x100 image # 100dpi = 1" x 1" image
100x100 image # 200dpi = 0.5" x 0.5"
to "increase the size" of the printed images, you need to REDUCE the dpi count, so that
100x100 image # 5dpi = 20" x 20"
May I know what are the ways to calculate the length of 1 pixel in centimeters? The images that I have are 640x480. I would like to compare 2 pixels at different places on the image and find the difference in distance. Thus I would need to find out what's the length of the pixel in centimeters.
Thank you.
A pixel is a relative unit of measure, it does not have an absolute size.
Edit. With regard to your edit: again, you can only calculate the distance between two pixels in an image in pixels, not in centimeters. As a simple example, think video projectors: if you project, say, a 3×3px image onto a wall, the distance between the leftmost and the rightmost pixels could be anything from a few millimeters to several meters. If you moved the projector closer to the wall or farther away from it, the pixel size would change, and whatever distance you had calculated earlier would become wrong.
Same goes for computer monitors and other devices (as Johannes Rössel has explained in his answer). There, the pixel size in centimeters depends on factors such as the physical resolution of the screen, the resolution of the graphical interface, and the zooming factor at which the image is displayed.
A pixel does not have a fixed physical size, by definition. It is simply the smallest addressable unit of picture, however large or small.
This is fully dependent on the screen resolution and screen size:
pixel width = width of monitor viewable area / number of horizontal pixels
pixel height = height of monitor viewable area / number of vertical pixels
Actually, the answer depends on where exactly your real-world units are.
It comes down to dpi (dots per inch) which is the number of image pixels along a length of 2.54 cm. That's the resolution of an image or a target device (printer, screen, &c.).
Image files usually have a resolution embedded within them which specifies their real-world size. It doesn't alter their pixel dimensions, it just says how large they are if printed or how large a “100 %” view on a display would be.
Then there is the resolution of your screen, as others have mentioned, as well as the specified resolution your graphical interface uses (usually 96 dpi, sometimes 120)—and then it's all a matter of whether programs actually honor that setting ...
The OS will assume some dpi (usually 96 dpi on windows) however the screens real dpi will depend on the physical size of the display and the resolution
e.g a 15" monitor should have a 12" width so depending on the horizontal resolution you will get a different horizontal dpi, assuming a 1152 pixel screen width you will genuinely get 96 dpi
We have a requirement where our application needs to support high resolution monitors. Currently, when the application comes up in High res monitor, the text that it displays is too small. We use Arial 12 point font by default.
Now to make the text visible, I need to change the font size proportionally. I am finding it tough to come up with a formula which would give me the target font size given the monitor resolution.
Here is my understanding of the problem.
1) On windows, by default 96 pixels correpond to 1 Logical inch. This means that when the monitor resolution increases, the screen size in logical inches also increase.
2) 1 Point font is 1/72 of a Logical Inch. So combined with the fact that there are 96 Pixels per Logical inch, it turns out that, there are 96/72 Pixels per Point of Font.
This means that for a 12 point font, The number of Pixels it will occupy is 12*96/72 = 16 Pixels.
Now I need to know the scaling factor by which I need to increase these Number of Pixels so that the resultant Font is properly visible. If I know the scaled pixel count, I can get the Font size simply by dividing it by (96/72)
What is the suggested scaling factor which would ensure properly scaled Fonts on all monitor resolutions?
Also, please correct if my understanding is wrong.
There's an example on the MSDN page for LOGFONT structure. Your understanding is correct, you need to scale the point size by vertres / 72.
lfHeight = -PointSize * GetDeviceCaps(hDC, LOGPIXELSY) / 72;
If you set the resolution in Windows to match that of the physical monitor, no adjustment should be needed. Any well written program will do the multiplication and division necessary to scale the font properly, and in the newest versions of Windows the OS will lie about the resolution and scale the fonts automatically.
If you wish to handle this outside of the Windows settings, simply multiply your font size by your actual DPI and divide by 96.
Edit: Beginning with Windows Vista, Windows will not report your actual configured DPI unless you write a DPI-aware program. Microsoft has some guidance on the subject. You might find that the default scaling that Microsoft provides for non-DPI-aware programs is good enough for your purposes.