FreeLists / openbeos / [openbeos] Icon Artwork

[Stephan Assmus <superstippi@xxxxxx>]

Hi all,

as you might be aware of, I have recently been working on "Icon-O-Matic", 
the icon editor for Haiku, along with a vector icon design / document 
structure and corresponding file format. I have put a preview release of 
Icon-O-Matic, along with a couple of self-made sample icons at this 
location:

<http://www.yellowbites.com/stuff/icons.zip>

If you are interested in helping with icon artwork for Haiku, please have a 
look. :-)

Best regards,
-Stephan


To save you some hassle, here is what I wrote in the Readme:

----------------------------------------------------------------------

Icon-O-Matic Readme

Hi,

thanks for taking the time to read this and for your interest in 
Icon-O-Matic.


Introduction:

We Haiku developers agree on the fact that Haiku cannot be officially 
released with the original BeOS R5 icons. For this reason, all icons within 
Haiku need to be original artwork. Since we have to do this work anyways, 
we might as well switch to vector icons now. At least we should be able to 
design the icons in a vector format, so that we don't have to do it all 
again when we do switch to vector icons. However, as things progress, I am 
confident that we can use vector icons in R1 without the associated 
drawbacks. The drawbacks are that vector icons usually don't look crisp at 
small sizes (16 x 16), and that they need too much storage space. I have 
come up with a rendering engine (based on Anti-Grain Geometry 
<www.antigrain.com>) and a storage format that try to work around these 
problems.


Storage Format:

Haiku Icon-O-Matic supports currently two storage formats: A "native" 
BMessage based format that stores *all* attributes of the icon document 
without worries (and you should always have a backup of your icons in this 
format). Then there is the "flat" format, which is the storage format that 
I came up with to save an icon in as little space as possible. It is not 
yet feature complete, but promises already to use very little space. BeOS 
native icons are bitmaps, a large (32x32) and a small (16x16) one. They use 
8 bits per pixel for storing indices into the BeOS system palette. Therefor 
they use 1024 bytes for the large icon and 256 bytes for the small one. So 
BeOS totals at fixed 1256 bytes for an icon. As you can see in the examples 
folder, the biggest icon I designed uses only 543 bytes.

Note: It is important to have small icons, because the responsiveness of 
the Tracker and Deskbar will depend on it. If the icon attribute fits 
within a files "inode", there doesn't have to be a second disk access per 
displayed file with unique icon.


Crisp Display:

The new vector icons support a number of features that are designed to 
improve crisp display:

1) Rendering is performed in linear gamma RGB space to elliminate false 
colors at anti-aliased pixels.

2) Shapes support "level of detail". Each shape has two attributes, minimum 
visibility scale and maximum visibility scale. If the global scale of the 
icon falls below "minimum scale", then the shape is not rendered, likewise 
with maximum scale. This feature allows in effect to have multiple 
appearances in one icon which the renderer chooses depending on the global 
icon scale.

3) Shapes support "rounding", that is, vector coordinates will snap to 
whole pixels if rounding is turned on. This feature can be weird with 
regard to shape transformers, and needs to be used with care. The snapping 
is done after any transformations, so shapes will snap to pixels regardless 
of global icon scale. Of course, this makes the shapes appear more crisp.

4) Icons are rendered in a single pass, removing the problems of "seems" at 
adjacent shapes. See "Tipps and Tricks" for more on this.


Icons documents:

I chose to design the icon structure in a way that allows to have powerful 
features while keeping the icon size small. However, for some types of 
icons, the way in which they are designed in Icon-O-Matic will feel 
cumbersome. The purspose of this test release is also to get feedback on 
how this could be improved.

An icon is made up of three parts: Styles, Paths and Shapes. A Style is 
either a solid color or a color gradient. A path is a sequence of Bezier 
curves and/or straight lines. Styles and paths are global to the icon. Then 
the shapes reference them. So the same style could be used by multiple 
shapes. Each shape has exactly one style assigned to it. For paths, it is a 
bit different, each shape can have any selection of the available paths 
assigned to it. Then each shape can have an optional list of Transformers. 
A transformer takes vector data and "transforms" it in some unique way. For 
example, there is a Stroke transformer which takes a vector path, and 
produces another vector path which formes a "stroke" around the original 
path. The output of one transformer is piped into the next transformer.

Example:

Suppose you want a white circle with a black outline. You could start by 
creating a new path which is a circle (no sorry, you have to draw it 
yourself, there is no circle tool in Icon-O-Matic yet). Then you create two 
styles, make them white and black. Now you can create the first shape. When 
a shape is selected (in the shape list view), the path and the style list 
view display check marks in front of the paths/styles so that you can 
assign them to the selected shape. For this shape, you would mark the 
circle path and the white style. Now create the second shape. While the 
shape is selected, add a Stroke transformer in the transformer list view. 
Now you can assign the black style and (again) the circle path. Whatever 
change you do to the circle path, it will reflect in both shapes. 

You will have noticed that whatever object you have selected, its 
properties will be displayed in the Property list view. There you can 
rename the object, and depending on the type, adjust additional properties, 
like the width of the Stroke transformer, or wether the path is closed and 
so on.

That's basically it, that's how you built up icons. Over time, the comfort 
will be improved, I know it's very basic right now. Please don't hesitate 
to write feedback with your ideas and complaints though!
Also keep in mind that Icon-O-Matic is not stress tested, save early, save 
often. When it crashes, please send me the stack crawl! Additionally, many 
menus are incomplete or pretend to support something when they don't. No 
need to report this, though.


Tipps & Tricks:

Icons support the alpha channel in colors and gradients. But because of the 
single pass rendering, it is not supported to layer a semi-transparent 
shape on top of other shapes. The icon is rendered as if it was flat! This 
is the lesser of two evils in my opinion, but switching from "single pass 
compound shape" rendering to "traditional multi pass" (bottom to top) 
rendering is trivial. So if enough people complain, I can change it easily. 
But for the time being, please bear with me, it really pays off with 
regards to the crisp icon look. If you want stuff like self-shadowing or 
highlights, be creative with fake transparency, take my "App Icon" as an 
example. 

To get the smallest possible icon size, use the "pixel snapping" feature 
from the Settings menu when you design vector paths. Try to reuse a single 
path in mutiple shapes, note that you can transform a shape to whereever 
you want, independent of the path. It will also allow you to make changes 
to multiple shapes at once, only by adjusting a single path.

Icons are designed at a "native" resolution of 64x64 pixels. To make shapes 
appear sharp at lower resolutions, optimize for the 32x32 and 16x16 size by 
placing the more important shapes at the 32x32 or 16x16 coordinate grid. 
There is currently no helpful snapping for this purpose, but you can keep 
an eye on the smaller icon previews to get it right.


Have fun and best regards,
-Stephan

Feedback: <superstippi@xxxxxx>