Why are Haiku vector icons so compact?
In Haiku, vector icons are so compact, how is it? You probably expect some kind of hack, but the secret is that HVIF (Haiku Vector Icon Format) is pretty simple. Most importantly, this format is optimized for icons. As soon as you agree with this simple assumption, immediately come the ideas of various ways to optimize the amount of data.
For example, let the icons have a standard resolution of 64x64 pixels. It would be nice to tie the coordinates of the vector path to the integers of the squeak. It would also be nice to be able to set coordinates beyond the borders of the icons, so we will define a range from -32 to +95 pixels, which will fit in just 7 bits. If the coordinates are not integers, or are outside the range [-32, 95], we will use the 8th bit to specify a two-byte sequence that extends the range to [-128, 192], and the additional precision will be used for fractional values coordinates.
It is also useful to think about optimizing the general form of vector paths.
HVIF distinguishes between three basic types: the path with commands, the path with straight lines, and the path only with curves. All paths are curves that can represent two other forms of paths, but they require storing a large amount of data, because it’s just a joke, as many as 6 coordinates are required for each segment. If the path includes many straight sections, or there are many horizontal and vertical lines, it will be better to associate the commands with the segments, which significantly reduces the number of required coordinates per segment. The SVG format defines a lot more, but how can you find enough four different commands for paths that cover all the needs for icons. This is a horizontal line, a vertical line, just a line and a cubic curve. The first two need only one coordinate (X or Y), since the other will be unchanged with respect to the previous point. An arbitrary line will require 2 coordinates, and the curve is already 6. Four encoded commands for the paths may take two bits, add finesse, write them separately from the coordinates, so one byte encodes up to four commands. Let's now calculate how much data a simple rectangle with integer coordinates will occupy:
HVIF analyzes which commands to use when encoding to get the least data. For example, if all curves or all lines, then there is no point in storing a section of commands.
')
Most of the icon objects are encoded with an additional reserved byte for the “flags”, which determines which aspects need to be stored in the file. For example, if the shape will never change - there is no point in storing the transformation matrix. In this case, “empty labels” for unused parameters will simply be excluded.
Speaking of transformation matrices, it should be borne in mind that they can take quite a lot of space if you do not take additional measures.
HVIF uses normal affine matrices for transformations, which are usually encoded with 6 double (48 bytes) or float, if you do not think about high precision (24 bytes). To further reduce storage costs (since precision is not required for icons), HVIF uses its own floating point format, which uses only 3 bytes per value. So the required volume for the matrix is ​​reduced to 18 bytes.
Often it is required only to displace a figure, but not to rotate, cut or scale. In this case, it makes sense to store only the offset using the same format as for the coordinates of the paths.
There are two kinds of styles: just color and gradient. Section style can occupy a significant place, so there are a number of steps to reduce this indicator. A color or gradient that does not use an alpha channel is not encoded with an alpha channel, and gray is encoded with one byte. What type of coding for colors is also used is determined by the byte of flags of any given style. There is also a special format for gradients with two colors, one at 0% and one at 100% offset (a very common type of gradient), where color offsets are not coded.
HVIF data consists of three sections. The first encodes all the styles, the second all the ways, and the last all the shapes. Styles and paths are global in Haiku icons, so they can be used by various shapes. But there should be no more than 256 styles or 256 paths in total. Thus, the figures can refer to them with just one byte, which is an index of the style or the path in the global list. Figures can also have attached transformations, for example, a Stroke transformer can transform a path into a stroke. For storage of transformers nothing special was invented.
As you can see, it hardly makes sense to use HVIF for general vector graphics. This format is only suitable for very special tasks. But, as was said, it can be useful for solving these problems, ultimately, at least in terms of the responsiveness of the working environment. But this will not happen by itself. If the icon is designed without knowing how HVIF works, then its potential is lost. For example, if the coordinates of a vector path are not integer values, or if the paths are not reused, where they may be, then the icon may take up much more space than it could. This is especially true when the SVG icon is imported into Icon-O-Matic and is simply stored in HVIF as it is, which is not good. Some works have yet to remove redundant or unnecessary information from the icons, but now, with the information that has just been presented, everyone will be able to use optimization techniques when creating icons for Haiku.
Coordinates
For example, let the icons have a standard resolution of 64x64 pixels. It would be nice to tie the coordinates of the vector path to the integers of the squeak. It would also be nice to be able to set coordinates beyond the borders of the icons, so we will define a range from -32 to +95 pixels, which will fit in just 7 bits. If the coordinates are not integers, or are outside the range [-32, 95], we will use the 8th bit to specify a two-byte sequence that extends the range to [-128, 192], and the additional precision will be used for fractional values coordinates.
Paths
It is also useful to think about optimizing the general form of vector paths.
HVIF distinguishes between three basic types: the path with commands, the path with straight lines, and the path only with curves. All paths are curves that can represent two other forms of paths, but they require storing a large amount of data, because it’s just a joke, as many as 6 coordinates are required for each segment. If the path includes many straight sections, or there are many horizontal and vertical lines, it will be better to associate the commands with the segments, which significantly reduces the number of required coordinates per segment. The SVG format defines a lot more, but how can you find enough four different commands for paths that cover all the needs for icons. This is a horizontal line, a vertical line, just a line and a cubic curve. The first two need only one coordinate (X or Y), since the other will be unchanged with respect to the previous point. An arbitrary line will require 2 coordinates, and the curve is already 6. Four encoded commands for the paths may take two bits, add finesse, write them separately from the coordinates, so one byte encodes up to four commands. Let's now calculate how much data a simple rectangle with integer coordinates will occupy:
- 1 byte to specify the number of paths (4)
- 1 byte for four path commands (2 bits may remain unused, but there is a command (line) that determines the first point anyway)
- 5 bytes for coordinates (2 bytes for the first point, 3 bytes for the rest)
HVIF analyzes which commands to use when encoding to get the least data. For example, if all curves or all lines, then there is no point in storing a section of commands.
')
Flags
Most of the icon objects are encoded with an additional reserved byte for the “flags”, which determines which aspects need to be stored in the file. For example, if the shape will never change - there is no point in storing the transformation matrix. In this case, “empty labels” for unused parameters will simply be excluded.
Matrices
Speaking of transformation matrices, it should be borne in mind that they can take quite a lot of space if you do not take additional measures.
HVIF uses normal affine matrices for transformations, which are usually encoded with 6 double (48 bytes) or float, if you do not think about high precision (24 bytes). To further reduce storage costs (since precision is not required for icons), HVIF uses its own floating point format, which uses only 3 bytes per value. So the required volume for the matrix is ​​reduced to 18 bytes.
Often it is required only to displace a figure, but not to rotate, cut or scale. In this case, it makes sense to store only the offset using the same format as for the coordinates of the paths.
Styles
There are two kinds of styles: just color and gradient. Section style can occupy a significant place, so there are a number of steps to reduce this indicator. A color or gradient that does not use an alpha channel is not encoded with an alpha channel, and gray is encoded with one byte. What type of coding for colors is also used is determined by the byte of flags of any given style. There is also a special format for gradients with two colors, one at 0% and one at 100% offset (a very common type of gradient), where color offsets are not coded.
HVIF data consists of three sections. The first encodes all the styles, the second all the ways, and the last all the shapes. Styles and paths are global in Haiku icons, so they can be used by various shapes. But there should be no more than 256 styles or 256 paths in total. Thus, the figures can refer to them with just one byte, which is an index of the style or the path in the global list. Figures can also have attached transformations, for example, a Stroke transformer can transform a path into a stroke. For storage of transformers nothing special was invented.
As you can see, it hardly makes sense to use HVIF for general vector graphics. This format is only suitable for very special tasks. But, as was said, it can be useful for solving these problems, ultimately, at least in terms of the responsiveness of the working environment. But this will not happen by itself. If the icon is designed without knowing how HVIF works, then its potential is lost. For example, if the coordinates of a vector path are not integer values, or if the paths are not reused, where they may be, then the icon may take up much more space than it could. This is especially true when the SVG icon is imported into Icon-O-Matic and is simply stored in HVIF as it is, which is not good. Some works have yet to remove redundant or unnecessary information from the icons, but now, with the information that has just been presented, everyone will be able to use optimization techniques when creating icons for Haiku.
Source: https://habr.com/ru/post/79163/
All Articles