Resolution independent bullshit meter off the charts
Over at iconfactory Craig Hockenberry tries to make the case against using vector representation for icons (via daringfireball).
Now, before I get into this, I would like to point out that there is an entire industry which revolves around bitmap icons, not just images but icons specifically, and there are tools which are specifically designed to manipulate bitmap icons. The iconfactory is one of these companies. While I have nothing against that, consider that vector icons are a threat to the established base of bitmap icon purveyors. So, if you are looking for a new product idea, start working on tools to create and optimize vector based icons.
Craig writes:
Size: Today’s photorealistic icons require a lot of vectors. More than you may realize. Unless you’re dealing with simple line art, effects such as gradients, shadows, and highlights result in enormous files. As an example, compare this 512×512 pixel PNG file of the CandyBar icon with a PDF file containing the same image. The PNG file is about 100 KB while its PDF counterpart is a whopping 3 MB. Consider a five icon toolbar with PNG files versus a toolbar with PDF files—500 KB versus 15 MB. Your ISP will love you and your PDF icons!
PNG is a file format designed specifically for storing bitmap image data in a compact form, so it is fairly well suited for an icon. PDF is a file format designed for documents, business documents, archival storage, absolute highest quality printer rendering. See the problem here? PDF can be excessive for storing just vector art for icons, while it does the job accurately, it typically stores a ton of other information which is not desirable for icons. This is like comparing the storage requirements of a wallet photo to a life size portrait mounted in a Baroque frame with an artists statement and brief history of the subject.
Now, this is not to say that PDF can not store things efficiently, it can, but typically programs which generate PDF are interested in preserving information, not saving disk space.
Craig links to a 100KB PNG of a CandyBar icon and a 3MB PDF file of the same icon to illustrate his point.
First of all, if you take this PDF, open it with Mac OS X Preview, Print it and re-save it as a PDF it reduces the file size down to 1.6MB. This is because Craig's PDF is full of XML metadata which is completely extraneous to creating the image, the OS X printing system removes it, even the printer doesn't need it.
Second of all, this is a PDF 1.3 file, the most recent PDF version is 1.7, each version has decreased file size, so this is not an optimal PDF, how un-optimal you say? Well, if you run this file through Acrobat 8.0 on Windows and create a PDF 1.7 file with it (Reduce File Size), the result is 1.1 MB, another half a megabyte down, still displays fine on OS X too.
Now, let's take a look at what this PDF is made of, Acrobat's PDF auditing at your command:
1MB of images. raster data. So, what the hell, this guy is comparing high resolution bitmaps stored in a PDF to smaller bitmaps stored in a PNG. Yea, what is the point of his post? To be fair, these bitmaps are probably generated by the drawing program and Craig has no idea they are in there. This PDF is obviously some sort of original proof just saved as PDF and is not optimized as a vector icon. If you actually set out to design a vector based icon considering storage requirements, you wouldn't have a PDF like this.
Gradients, shadows, highlights and the graphics effects you see in use today can usually be expressed compactly. The problem is finding the right combination of file formats and programs to generate and store vector icon images with all the desired effects. It's not a hard problem these days, companies like Adobe and Macromedia have put a lot of work into it with Flash, Flex and SVG.
Craig again:
Speed: As developers we love to deal with abstractions—unfortunately, concrete reality often gets in the way. Vectors present a nice conceptual image model which fails when you consider today’s graphics hardware. Simply put, a GPU can’t deal efficiently with vectors. Processing of raster images can be sped up significantly by performing tasks in parallel—no such speedup is obtained with vectors. Try opening both of the sample images above in Preview. You can zoom in and out to get a feel of the performance characteristics of vector versus raster data.
I can't believe this is actually being said. "Simply put, a GPU can’t deal efficiently with vectors" ? One of the primary benchmarks for a GPU is triangles per second, what is a triangle? Vectors. While GPU's are amazingly good at throwing bitmaps around, they are equally good at vector rasterization. A huge part of the field of computer graphics is the invention of algorithms which can render abstract representations efficiently. 3d graphics (of which 2d is a subset), bitmap and vector based, lend themselves to high degrees of parallelization. Even in the realm of high frame rate 3d games you see some moves away from textures (raster surface image) towards shaders (abstract surface description) because the abstract description is resolution independent, great for HD, and highly optimizable with silicon.
The whole Preview zooming thing is a red herring, PDF is not the best format to begin with and the document is full of raster data! Keep zooming, you'll see the resolution independence fall apart on the purple gradients.
Craig last assertion:
Appearance: Like all Mac developers, we’re concerned about our application’s appearance. Scaling vectors that are optimized for presentation at a large size will result in images that look unacceptable at small sizes. The trained eye of a designer knows which pixels to keep and which ones to throw away—automated scaling of an image does not.
I do agree with this to a certain extent, low resolution icons are not well represented by vector art, high resolutions icons can be though, which is the point, Apple is slowly gearing everyone up for higher resolution displays. You can have both, neither are bad.
In closing I leave you with these, kittytank at 12KB is my favorite:
http://www.dlanham.com/art/dragon/dragon.swf (112KB, press the button)
http://www.dlanham.com/art/kittytank/kittytank.swf (12KB)
http://www.dlanham.com/art/reddog/reddog.swf (84KB, press the button)
http://www.dlanham.com/art/bones/bones.swf (28KB, click the creature)
http://www.dlanham.com/art/hyper/hyper.swf (12KB)
Not only are these cool artwork which scale well, they have animation, some have sound, the file sizes are pretty small relative to the quality of the content, and best of all, the guy who created them works for iconfactory.
29 Comments:
Those are some spiffy SWFs and all, but they don't represent the sort of detail or quality you find in a typical Mac OS X icon. Notably, they're missing the "gradients, shadows, and highlights" that Greg mentions.
Those are some spiffy SWFs and all, but they don't represent the sort of detail or quality you find in a typical Mac OS X icon. Notably, they're missing the "gradients, shadows, and highlights" that Greg mentions.
Gradients, shadows, and highlights take as much space as vector data to store -- because they are vector data! A gradient is two control points that has a series of colors assigned to it. Shadows and highlights are just special cases of gradients.
I wrote my own blog post about this, which said essentially the exact same things:
Vector Vs. Raster: The Fool's Game
Uh, I zoomed in to 2000% on the purple gradient and got no blurring at all. Are you sure your conjectures are correct?
Your assertions speak for themselves, it would have been nicer if you could have presented them without character assassination.
Craig's a great guy and doesn't deserve the personal attack, especially since his key point is one you ultimately agree with.
The original file looks very much like a vector file to me.
Could it be that your `compression by printing' converts it to a bitmap-pdf?
Chill out, guys, it's just a rebuttal. People who don't want their characters assassinated shouldn't post such easily disprovable claims (or at least, hope they aren't linked from d.f.).
The article might have been terse but I did not see any character assassination.
It was simply a response to an article written by a respected author, claiming that his article has false assumptions.
Good read and thanks for the info.
At 2000%, you can see pixellation in the gradients if you look closely. At 3000% the pixellation is obvious. Vectors are used for highlights and the bounding shapes, but a lot of the soft shading is done with bitmaps.
The fact that one has to zoom in so far to see the pixellation means these are high-resolution bitmaps, which explains the large amount of bitmap data.
Can't help wondering if Hockenberry knew that this particular icon was a mix of vector and bitmap. It's possible he picked an icon at random to use as his example and didn't think about its components. I'd prefer to think that, rather than him hoping nobody noticed.
I don't think you can argue one of Hockenberry's points: on today's hardware, with today's software, detailed vectors don't display as quickly as detailed bitmaps. Zoom in on a detailed vector illustration in Illustrator and watch it sloooowwww down. Dump a 20mb TIFF into Illustrator, and redraws are snappy. Sure, that could change with tomorrow's hardware & software, but I wouldn't count on it.
My opinion is that this whole subject is a tempest in a teapot. I keep my dock icons at about 50x50. My sister, who's a typical computer user (only a few apps, likes everything big), keeps hers at around 120x120. As much as Iconfactory would like there to be a market for 512x512 icons, does it exist? Given that RAM and HD cost are always coming down, and display resolution will increase somewhat, I just don't see the need for vector anything in interfaces. Make all your icons at 512x512, and let the software scale them down as necessary. With higher display resolutions, individual pixels become less important. Hockenberry will one day look back on his pixel-by-pixel optimizations and think to himself, "Sure glad I don't have to do that anymore."
Regardless of the use of the PDF format--I have designed tons of EPS illustrations for icon use and average a 1.5 to 6 megabyte file. Vector art just isn't practical for icons. Even if the file sizes were half--would you want your OS using thousands of vector icons on the fly? Have you ever seen illustrator struggle with a redraw of a detailed illustration?
It's slow as hell and is extremely cumbersome.
And next time, asshole, try to post without the attitude, okay?
Christopher -- Excellent, thorough work. I fear that a number of your commentors seem to have no knowledge of how vector data is actually represented, and that it can in fact be quite small, and even smaller with modest compression.
I don't know Craig, but I suspect he simply made a mistake and accepted the 3Mb PDF at face value because it supported his view.
One apt analogy came to mind: rendering vector icons every time they need to be displayed is like rendering a 3D animation every time you want to view it. Sure, throw enough hardware at the problem and you can do anything, but at this point in history, when processor power is not unlimited, why would you? Scaling bitmaps requires only a fraction of the processor power required for rendering detailed vector illustrations.
Many thanks to all the fans of my post, your supporting information is interesting and enlightening, we are all better off for it. I can only hope to maintain your support and interest in future posts.
To the anonymous person who called me an "asshole", your EPS file sizes example is completely stupid. We all know it and now you do. The only smart thing about your comment was that it was posted anonymously.
I know it's fun to hop on the vector vs bitmap bandwagon and spout-off about how screwed up Craig's PDF example is... but before you rake Craig over the coals too much, consider this:
Iconfactory collectively has probably created more desktop icons than anyone. Their icons appear in products developed by just about any major software company in the world. Microsoft, Apple, Ubuntu, Adobe, Macromedia... on and on.
Craig personally wrote one of the most popular icon creation tools for the Mac, period. And to top it off, Iconfactory was using vector source files for their icon work long before OS X was released (as was I).
I'd cut them some slack. I imagine they know a whole heck of lot more about icons than most of the talking heads do.
One more thing:
To anyone reading Mr. Deken's offhand advice to "start working on tools to create and optimize vector based icons," I'd suggest a healthy dose of reality before jumping in the deep end.
And Mr. Deken, the suggestion that Hockenberry's reasoning is tainted by self-interest is ad hominem. Stick to arguing the facts. Your post works just fine without that first paragraph.
Whoops -- sorry about the identity confusion. I've been reading too many posts on this subject. The above references to "Mr. Deken" should read, "Mr. Lloyd."
My apologies.
You don't have to draw vector icons as vectors every single time you need them... you can obviously cache the rendered bitmap as needed.
Greg's argument that you need to hand-edit icons at tiny sizes seems beside the point, since on 200-300dpi displays, 32x32 pixels (at which vectors still look fine) will be the smallest you'd want an icon to get -- it'll be tiny.
The simple fact is that Greg was flat-out wrong about file sizes. And I believe he's wrong about needing to hand-edit icons and in his belief that you can't create great-looking icons with vectors, as well.
Craig, not Greg.
As usual the truth is somewhere between..
With current design tools (Freehand/illustrator/Photoshop) and the usual formats (EPS/PDF) vector icons are large, unwieldy and slow.
But,
Current tools don't necessarily make best use of GPUs either plus there is a lot of old-slow-old-code in some of these apps as far as I can tell. Compare with Quartz. It is, after all, display PDF - and blisteringly fast.
Flash also proves that Vector art can be both small and fast. Core Image and Core Animation shows how much further this sort of thing can be taken.
As a side not while a 1MB image file isn't desirable on a website, embedded in an application it may not be too much of a problem, especially when only a small part of it needs to be parsed at any one time to generate an icon of a particular size. There may never be a reason to read the whole file at all.
And: What is to stop Apple producing a new image file format based on Display PDF rather than Print PDF for their own application images. Or an image bundle that allows vectors and bitmaps and cache folders at various sizes?
As another side note: Didn't the old Macs had a file format that was just a series of Quickdraw calls strung together? They were fast enough for most things on 68000s. Surely todays machines could do something like that at incredible speeds.
Also: Once someone has the guts to move in this direction I'm sure that GPUs will soon be optimized for it.
Either way, in the long-run Vectors (with filters) is where we aught to be heading. You only have to look at Core Image and Core Animation to see that. Imagine a Flash-like tool for Core Animation that spat-out shiny, blurry, shadowy, pulsating animating icons and desktop backgrounds (and the odd game perhaps) and you'll be where I am heading.
And hopefully Apple too.
Ok, 2 thoughts:
1. I find it much easier to work on icons as bitmaps. Why? Because bitmaps are so much easier to work with for gradients, reflections etc. Yes you can do the same thing with vectors but in my experience it requires much more work and too many shapes to be workable. Vectors are great as a starting point but there's a reason most people use Photoshop for their final web images instead of Illustrator
2. Leopard is going to have 512x512 px icon support. We are currently at around 100dpi resolutions for monitors. So assuming that OS X allows up to 128x128 points for icon display then the simple maths says that 512x512 px icons will not be usable when we have 400dpi displays. Now would anyone like to make a guess when we will actually have 400dpi displays? I doubt it will be any time this decade. By the time that using a vector icon over a bitmap icon becomes relevant most developers will have updated their icon in some way, providing them with the chance to update the size for if we get 400dpi+ displays
The CandyBar icon was drawn completely in Illustrator and while most of it is vector based, there are some raster effects that are needed to give it a more realistic effect. It was my fault for exporting the 3 MB PDF file and after reading your post I tried exporting with some better PDF settings, it did indeed get down to about 1MB. This is still much larger than the PNG icon though. If I took out all the raster effects, it would drop to around 200 KB, but it also loses the shading that gives it the Aqua look.
While I will be the first to agree that vectors are fantastic, they just aren't cut out for being used by the OS for Aqua styled icons. For simple styles, vector icons would rock and probably be much more efficient, but it's just very unlikely that this format would be adopted given the highly detailed nature of Apple's icons and interfaces.
And comparing my simple styled animations to the CandyBar icon (I drew the high res version based on the original) isn't really a fair comparison, although it does show how style can affect the file size.
The iconfactory guys know a lot about creating icons for OS X with the help of vector graphics using ADOBE ILLUSTRATOR.
Can anyone tell me at what point in time Adobe Illustrator has become the benchmark of effective vector data storage, let alone the benchmark for vector art on-screen display performance?
For all I can tell, by looking at Cocoa based vector apps (Lineform, Intaglio etc.), Illustrator with its tons of legacy code is the worst, it's a resource hungry (in disc space, memory and performance) bloated hog second to none. Also the PDFs or .ai files Illustrator creates are not remotely optimised for minimal storage space since even a highly compressed PDF contains a lot of information that is not needed by the user just to display the image.
Ah, and thinking of it IRIX has had vector-icons for years. Seems to work flawlessly even on "old" hardware.
sgi have been there, done it and got the t-shirt, so it has been possible using vector-based icons for years, why should it suddenly be not feasible anymore?
I don't think some of you realise the other issues associated with vector artwork when used like this. There's so many issues and so little benefit. I really don't see the need.
I've posted an example of how poor vectors can look at small sizes as well as some other comments here:
http://islayer.com/blog/?p=87
I think no one brought this up before, but vectors only have to be rendered once per resolution. Then that can be cached. So the speed issue is mostly FUD.
Yet vectors also allow for use-cases that bitmaps suck at. What if I want an unusual resolution that bitmaps don't support? Or what if Granny wants everything 1.5x in size? The vectors look great, the rendering still only needs to be done once, and Granny's happy.
Why not have an icon composed of bitmaps for standard or lo-res, and a vector for unforseen cases?
Incidentally, the limitations of Illustrator are not the limitations of vector art.
Gosh, add a little sauce to something and everyone gets their panties in a bustle!
I agree that we should use vector icons. Although they may be a bit large in file size, I prefer them. They can be very crisp and clear, and I bet I could make something similar to a basic icon in the Aqua theme. Take the Flash CS3 icon, for example. It could be turned into vector in a very small amount of filesize! And inkscape, for example. That already is vector! So back to the flash icon. It's just some text saying "Fl" and a gradient in the back. Just a few more gradients and you couldn't tell the difference! And all of the icon in CS3 (with the exceptions of Flash Video Encoder, Device Central, Acrobat, and Extension Manager) are like this. Like Dreamweaver. It's exactly the same as the flash icon, except it has "Dw" and the gradient behind it is different. And again looking at my dock, Blender 3D looks like it could be made in vector at a low filesize! People, look! However, there are some that just can't be vectorized or have a giant filesize when vectorized. For an exaple of this, let's take Quartz Composer. And then, it the middle of filesizes, there would be Xcode, Dashcode, and TextEdit. And check out the Eclipse IDE! That's pretty simple. You don't have to get all too fancy to get a good icon. And if it's simple enough, it can be vectorized at a low filesize. Anyway, enough of my rant. Keep insulting us who love vectors if you want. We're sticking with vector.Ni9aerei
Sorry, my browser is kinda messed up. It adds that after every thing i write in a textarea.Ni9aerei
... and while THEY are arguing about how bad vector icons are and/or might be, Linux has been using them for quite a while now. KDE was the first to switch, i believe, Gnome followed. The reason was: single resolution source. Scaling down bitmap data invariantly muddes up the picture, while scaled down vector icons can use automatic techniques for visibility improvement - for example, enhancement of lines which were just about to become invisible.
The files are made with Inkscape and are small, and there are also no performance problems. Rendering an SVG to bitmap does not necessarily take longer time than uncompressing a PNG image.
Furthermore, while pixel image decompression always has to be done on the CPU and are thus limited in performance, vector rendering can be offlayed to much faster 3D rendering hardware, which is available on almost every computer since 1999. See libcairo for one possible implementation. These techniques are not in major use yet.
Post a Comment
<< Home