I currently display 115 (!) different sponsor icons at the bottom of many web pages on my website. They're lazy-loaded, but even so, that's quite a lot.
At present, these icons are loaded separately, and are sized 75x50 (or x2 or x3, depending on the screen of the device).
I'm toying with the idea of making them all into one sprite, rather than 115 separate files. That would mean, instead of lots of tiny little files, I'd have one large PNG or WEBP file instead. The way I'm considering doing it would mean the smallest file would be 8,625 pixels across; and the x3 version would be 25,875 pixels across, which seems like a really very large image (albeit only 225 px high).
Will an image of this pixel size cause a browser to choke?
Is a sprite the right way to achieve a faster-loading page here, or is there something else I should be considering?
115 icons with 75 pixel wide sure will calculate to very wide 8625 pixels image, which is only 50px heigh...
but you don't have to use a low height (50 pixel) very wide (8625 pixel) image.
you can make a suitable rectangular smart size image with grid of icons... say, 12 rows of 10 icons per line...
115 x 10 = 1150 + 50 pixel (5 pixel space between 10 icons) total 1200 pixel wide approx.
50 x 12 = 600 + 120 pixel (5 pixel space between 12 icons) total 720 pixel tall approx.
Related
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'll sometimes use small, uniform pixel patterns as background images.
I've found myself using 4 x 4 or 10 x 10 pixel images in these situations, and I'm wondering if it might be better to use 50 x 50 or 100 x 100 pixel sizes instead.
Regardless, the file size will be very small, but it occurred to me that it might be much more efficient for browsers to map 30 (or so) 50x50 pixel images to a background than to map 60,000 4x4 pixel images.
It seems like it might take up significant CPU (and therefore, battery life) for the browser to repeat a background image 60,000 + times.
Does the number of CSS background repetitions affect webpage efficiency?
4 x 4 px = [1280 x 720 screen : 57,000 repeats] [3.47kb]
100 x 100 px = [1280 x 720 screen : 9,200 repeats] [13.83kb]
Why do you say you can't use transparent background in css?
Try using RGBA - where 'a' is alpha.
i.e
background: rgba(255, 0, 0, 0.4);
Examples:
http://www.css3.info/preview/rgba/
When I am reading about the resolution of a digital image from the following link http://www.rideau-info.com/photos/whatis.html, I confused at the following Paragraph:
If the field of view is 20 feet across, a 3 megapixel camera will be resolving that view at 102 pixels per foot. If that same shot was taken with an 18 Mp camera it would be resolving that view at 259 pixels per foot, 2.5 times more resolution than a 3 Mp camera.
Here, how come the author is arriving at the conclusion: "102 pixels per foot and 259 pixels"?
A 3MP camera, in that article, is 2048 wide x 1536 high. Think of 2048 pixels across as 2048 boxes laid in a straight line. Now, if you were to divide these equally amongst 20 sections (20 feet of field of view), you would get ~120 boxes per section. Hence, the logic behind 102 pixels per foot. Similar reasoning is used for the 18MP camera which is 5184 W x 3546 H. 5184 divided into 20 is ~259.
I am playing through an animation of about 90 images # 480x320 each, and I am wondering with the images not being power of 2, will this be a big performance hit? I am programing for as far back as the iphone 3Gs. Also I am using cocs2d.
Assuming you load all of these images at the start and they are 16 bit images.
Well you will have 512x512x90 = 23,592,960 pixels
With 16 bit images thats 377,487,360 bits.
377,487,360 bits = 45 Megabytes of RAM.
So yes that is a big performance hit.
Let's see...
480x320 image will create a texture of 512x512 (next nearest power of two). 512x512 times 32bit color depth (4 bytes) equals 1 Megabyte. 90 times 1 Megabyte equals 90 Megabytes.
Your biggest problem will be allocating this much memory and caching it. Without caching the animation images, you'll have to load each image every time the animation frame changes. Loading 1 Megabyte from flash memory is pretty darn slow, I'm guessing > 100 milliseconds. So every time a frame changes, your app will stop for a fraction of a second. This will be a problem on the 3GS, and possibly the Retina devices as well if you use Retina images (each 960x640 image then requires 4 Megabytes texture memory).
You can only improve this by using PVR compressed images (use TexturePacker). Even halving texture size to 16 bit will probably not be enough for a smooth animation.
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