74

Sometimes in apps I look into the Resources and find files for, for example, a 256x256 version, a 128x128 version, a 64x64 version, AND a 32x32 version, of the same icon. When I see simple geometric icons like circles I already wonder why they do not just use SVG, but on top of that, what is the purpose of storing an original icon in addition to progressively lower quality versions of the same icon? Storing the smaller icons does not even save space because the full size icons are being stored anyway.

For example in Roblox Studio the @2x and @3x images are just higher resolution versions of basically the same icon:

Example

Why do that?

user16217248
  • 1,029
  • 1
  • 5
  • 19
  • 6
    Is this an iOS app? If so, the simple answer here is [because Apple require it](https://developer.apple.com/design/human-interface-guidelines/ios/icons-and-images/image-size-and-resolution/). – Philip Kendall Oct 26 '21 at 17:18
  • 2
    @PhilipKendall I have seen this or similar on apps of all platforms – user16217248 Oct 26 '21 at 17:21
  • 1
    @user16217248 which answers the question. App developers ever more don't create different code bases for different platforms but use systems that allow a unified code base to be compiled for all the platforms they're targeting. – jwenting Oct 27 '21 at 08:32
  • 1
    the keyword is "mipmapping" – BЈовић Oct 27 '21 at 09:19
  • 3
    @PhilipKendall But that just changes the question to "why do they require it?" – Barmar Oct 27 '21 at 14:13

4 Answers4

206

Image scaling isn't necessarily free

Modern processors are fast, but they're not magic, and everything that needs calculating on the fly uses up resources that could be better spent elsewhere. Similarly, if you load a large image into RAM (not to be confused with storage), or transmit it over a network, and then rescale it to one which only needs 1MB, you've wasted that 4MB of memory or bandwidth.

In the case of icons, this is generally negligible, but it could add up for a large number of images.

More importantly, image scaling is not always easy

Scaling a bitmap down means throwing away part of the image data, but trying to keep the "look" of the image. For some images, that's trivial - throw away every other pixel in a large block of colour, and you have an identical block of colour, but smaller. For some, it requires a smarter algorithm - a curved line will look jagged if you just drop pixels, but blurred if you over-use anti-aliasing.

For some images, it is better to simply redraw from scratch. To produce an icon at a very low resolution, an artist might take the original design and drop irrelevant details, straighten up curves and slanted lines, and so on. Notably, even storing a vector image such as an SVG would not give as good a result in these cases.

For a nice example of this, here are the 8 sizes of icons embedded in the LibreOffice Writer executable on Windows, which have clearly been hand-drawn at each size (form left to right, 16x16, 22x22, 24x24, 32x32, 48x48, 64x64, 128x128, and 256x256):

LibreOffice icons at actual size

Here is what each would look like if simply scaled down to the smallest size (16x16):

LibreOffice icons scaled to 16x16

And here they are all scaled to 64x64 (the actual size of the sixth one along):

LibreOffice icons scaled to 64x64

Special cases require effort

As you pointed out, some applications have very simple icons which could be made to look fine with automatic scaling. However, if some icons are stored at multiple resolutions, it's much easier to code the application or framework assuming that all icons will be stored at those resolutions. It's also easier to tell designers to always give you a series of icon files at the appropriate sizes, and name them in a standard way, leaving it up to them how much time to spend optimising each one.

IMSoP
  • 5,722
  • 1
  • 21
  • 26
  • 4
    The other thing to remember, that's specific to file/program icons: In Windows you can zoom in and out in explorer to make the icons really gigantic or really tiny. You would not want a tiny 16x16 image scaled up to 512x512, it would be very pixelated, and you also would not want a 512x512 image downsized to 16x16, as the post demonstrates (the high resolution image is less distinguishable). – jrh Oct 27 '21 at 01:38
  • Pre-making smaller sizes (each half the size of the previous) is called Mip-Maps or mipmapping. – Owen Reynolds Oct 27 '21 at 02:27
  • Do you know why this set of LibreOffice icons includes sizes 22x22 and 24x24? I never knew those were important or useful sizes to provide for Windows icons. – Roel Schroeven Oct 27 '21 at 07:47
  • 2
    @RoelSchroeven: GUI scaling, at least for the latter. With high DPI settings, Windows can scale its UI by 150%. This means Windows will check for a 24x24 icon icon instead of a 16x16. Why not add an 48x48? Presumably LibreOffice thought that the 32x32 icon scaled well enough. 22x22 is weird, I'd expect a 20x20 for 125%. – MSalters Oct 27 '21 at 08:03
  • @MSalters The 5th icon along is 48x48, so no mystery to solve there. The 2nd is indeed 22x22, though; no idea why. – IMSoP Oct 27 '21 at 08:26
  • 1
    Great answer. Feels like the 3rd point should come first though, it's the most important, IMO. – Jack Aidley Oct 27 '21 at 09:55
  • @OwenReynolds I believe the term Mip-mapping applies specifically to textures in 3d computer graphics, rather than be a general term for pre-making smaller sizes in general. – Jack Aidley Oct 27 '21 at 09:56
  • 3
    @RoelSchroeven it's typical to have these sizes in freedesktop.org-based environments. You can see other common sizes in e.g. Ubuntu using a command like `basename -a /usr/share/icons/*/[0-9]*/ | sort -uh` – Ruslan Oct 27 '21 at 11:04
  • This is also why fonts usually have different size images, rather than scaling everything. – Barmar Oct 27 '21 at 14:40
  • 3
    The latter part of the answer is good, but the implied order of relevance of the reasons given in this answer is off: image processing time is essentially completely irrelevant: *if* it is considered at all (and, I claim, it usually isn’t), it’s much less important than the issue of accurate scaling. Similarly, I don’t think memory requirements are often considered for icons. – Konrad Rudolph Oct 27 '21 at 16:24
  • 1
    @KonradRudolph I didn't mean to imply that the first two sections were more important than the third, but you're not the first person to read it that way, so I've reworded a bit. – IMSoP Oct 27 '21 at 16:42
  • @JackAidley 2D images use mipmaps, as described in this answer. 3D graphics uses mipmaps plus lots of other tricks (like when you see an image from the side, stretched out long but short -- they apply 2 sets of mipmaps, I think, then do extra math on that). – Owen Reynolds Oct 27 '21 at 21:09
  • 1
    @KonradRudolph Devices with lower resolution screens (which will use the `@1x` versions) are more likely to be older, less powerful devices, with limited CPUs, less RAM, etc. Only loading the smaller versions, not having to process them, will help. Some devices are really slow and memory-constrained and every little bit helps. – jcaron Oct 29 '21 at 16:56
  • 1
    Barmar, TrueType fonts are heavily hinted. A 24 point is definitely _not_ a 12 point font blown up by a factor two. One change is that large fonts are typically thinner. Exception is when you create huge posters, intended to be seen from 10 meters. They _are_ blown up. – gnasher729 Oct 30 '21 at 13:19
15

It's often so that you can display differently sized versions of an icon without having to go through the process of scaling down to smaller sizes.

The smaller versions may have been tweaked to make them easily recognisable, while an automatically scaled one could be fuzzy or pixelated.

Simon B
  • 9,167
  • 4
  • 26
  • 33
  • Are there some systems where you cannot decide how to render images, and just renders them based on how many pixels in size the images are? – user16217248 Oct 26 '21 at 17:35
  • @user16217248 I expect there is a really dumb system somewhere that does that. But anything that someone has taken some care over will handle differing size icons properly. – Simon B Oct 26 '21 at 22:50
  • 1
    MacOS and iOS will scale whatever image needs the least amount of scaling. Plus you can have different point sizes with different resolutions. For example 32x32x3 (designed for 32x32 size with 3 pixels per point) vs 48x48x2 (designed for 48x48 points with 2 pixels per point). – gnasher729 Oct 30 '21 at 13:23
10

For images over many magnitudes of scale, programs will store multiple resolutions in an efficient format https://en.wikipedia.org/wiki/Pyramid_(image_processing)

One use case: for high resolution maps, it would require not only lots of computation but an impossible amount of bandwidth to transmit the full resolution of a map, so when zoomed out lower detail tiles are presented, then when zooming in these are replaced with higher definition tiles.

Another use case is for reducing aliasing artifacts and speeding up computation is using mipmaps. The basic idea is that lower resolution textures are used for further away graphics.

mipmaps

Credit: User BillyBob CornCob on Wikimedia

The original description of mipmaps by Lance Williams in 1983 used a neat trick to store images with 3 channels, usually RGB such as in JPEG images, into one square using a recursive pattern. Here is the beautiful hand-drawn diagram from the paper:

recursive rgb

There are advantages and disadvantages to using a single image file for multiple resolutions: a single file is better for filesystems and can image compression algorithms can potentially compress better when all data is one file, but there is a little computation needed to extract the relevant resolution.

This would not extend so nicely for image formats that have 4 channels, such as an additional alpha (transparency channel) to get 4 channel RGBA in PNG images (conveniently, four 8-bit values pack perfectly into a 32-bit word).

The PNG format can optionally use interlacing, which uses a similar idea of storing multiple "resolutions" of an image, in this case so that over a slow internet connection, the user sees a degraded version of the image instead of say the first couple raster lines. I was quite inspired when I saw this GIF 14 years ago on Wikipedia:

adam7

Credit: CountingPine on Wikipedia.

qwr
  • 333
  • 1
  • 9
  • 1
    I've seen this geometric layout before, but I can't find any info on it after tons of googling. I'm curious if somebody has a reference – Alexander Oct 27 '21 at 13:32
  • is that black-gray-white-recursing square just a way of mapping the channels of all the different size images into a square grid? As in that the largest actual image is 1/4 of the full square, with the black, gray and white quarters the three channels, and then repeating the same for the lower quarter and the next smaller size? I wonder if that's any more useful than just storing the different images as regular images back to back. – ilkkachu Oct 27 '21 at 17:05
  • I've never seen the recursive square used in practice, but maybe there are some advantages to using a single image for all scaled images instead of multiple files. – qwr Oct 27 '21 at 19:49
  • @qwr Sure. When you're storing on disk, space is allocated in clusters/chunks so you can have wasted space up to almost the cluster size - per file. Like carrying 2.1 gallons of liquid when your only container is 1 gallon jugs. When you have 10 small files you can lose up to 10*cluster size, vs only 1*cluster size for one larger file. You lose some space with the larger file because you have overhead of the grey and white areas, but compressing image formats such as PNG are very good at large areas of solid color, instead of saving "pixel 1, grey, pixel 2, grey, etc."... – user3067860 Oct 28 '21 at 11:24
  • ...it will just save "pixels 1 through (1234), grey". (Or similar to that, the exact algorithm varies by image format but you get the idea.) For network transfer there is a similar per connection overhead. To transfer a file your computer first takes some time to contact the remote server, make sure that it is listening, and then explain what file is wanted. That's usually about the same amount of time per file, so 10 files has 10x as much transfer overhead as 1 file. Etc. (Same concepts apply to file reads, in memory storage, etc.) – user3067860 Oct 28 '21 at 11:24
  • @ikkachu If you mean storing on the diagonal like in the picture, instead of, for example, in one file but side by side in a row (like a film strip), for CSS sprites if you use the *other* diagonal it's so that you can handle the wrong size container without other images showing... http://www.aaronbarker.net/2010/07/diagonal-sprites/ – user3067860 Oct 28 '21 at 11:47
  • @user3067860, no, I was talking about distinct image files. Like in the question where the `@2x` and `@3x` versions are distinct files. Nothing here hinted at a need to put the different size images in a single image file and a single canvas, but if that's needed, I'm not sure what the use of having three different subframes of each particular size is. Most image file formats are already RGB in depth, no need to allocate different areas of the image canvas for each color... – ilkkachu Oct 28 '21 at 17:41
  • @ilkkachu Oh, see my previous comments about having one big file instead of multiple small ones is a huge savings. For example, it's even being used on this page (StackOverflow)! If you look at the files loaded, one of them is this https://cdn.sstatic.net/Img/favicons-sprite16.png?v=fd9ee425c546 which contains all of the site icons in one file. And putting them on the diagonal in that one file can be useful (but not on the diagonal with the channels split up--just on the diagonal in general). – user3067860 Oct 28 '21 at 17:53
  • In my experience, NTFS is really bad with handling lots of small files. Also as mentioned, putting many PNGs into one file can usually compress better and avoid a small amount of file overhead. – qwr Oct 28 '21 at 18:03
  • @Alexander I've only come to know this in the area of computer graphics, but it also had no name back then. Our usecase was MipMaps, in which case this layout allows you to store all the mip maps in a single texture with minimal memory overhead. Can't find a distinct name or any papers for it though.. – CShark Oct 29 '21 at 07:41
  • I updated my answer with the original paper http://www.cs.cmu.edu/afs/cs.cmu.edu/academic/class/15869-f11/www/readings/williams83_mipmap.pdf – qwr Oct 29 '21 at 08:17
2

One big reason is even in the current version of Windows, program icons are bitmap files. Vector images - like SVG - aren't supported by the OS yet. The official design guide says:

Because app icon assets are bitmaps and bitmaps don't scale well, we recommend providing a version each icon asset for each scale factor: 100%, 125%, 150%, 200%, and 400%. That's a lot of icons! Fortunately, Visual Studio provides a tool that makes it easy to generate and update these icons.

Instead of adding support for vector graphics, they opted to simply automate the process of generating the myriad of image files at different sizes. The guide lists 14 different "target sizes" for icons.

That applies not just to program icons, but to certain controls/widgets in the OS's native GUI toolkit.

bta
  • 1,003
  • 6
  • 12
  • 1
    SVG support might reduce the number of images which need storing, but a well-designed icon still needs to be customised to look good at very small and very large sizes, as the example in my answer demonstrates. [This Windows Vista / 7 era design guide](https://docs.microsoft.com/en-us/windows/win32/uxguide/vis-icons) discusses the principles quite clearly. I couldn't find the equivalent for Fluent Design, but [this Q&A touches on the same principle](https://medium.com/microsoft-design/developing-an-open-source-icon-system-at-microsoft-b1796315df9f). – IMSoP Oct 30 '21 at 13:34
  • So if anything it's the other way around: Microsoft considers bitmap rather than vector icons as a feature, because it allows designers to draw pixel-perfect icons, and adapt the style and detail for different contexts. – IMSoP Oct 30 '21 at 13:42