IconVG is a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.

IconVG

IconVG is a compact, binary format for simple vector graphics: icons, logos, glyphs and emoji.

WARNING: THIS FORMAT IS EXPERIMENTAL AND SUBJECT TO INCOMPATIBLE CHANGES.

Specifically, we are considering substantial changes to the file format to happen in mid-2021.

It is similar in concept to SVG (Scalable Vector Graphics) but much simpler. Compared to SVG Tiny, which isn't actually tiny, it does not have features for text, multimedia, interactivity, linking, scripting, animation, XSLT, DOM, combination with raster graphics such as JPEG formatted textures, etc.

It is a format for efficient presentation, not an authoring format. For example, it does not provide grouping individual paths into higher level objects. Instead, the anticipated workflow is that artists use other tools and authoring formats like Inkscape and SVG, or commercial equivalents, and export IconVG versions of their assets, the same way that they would produce PNG versions of their vector art. It is not a goal to be able to recover the original SVG from a derived IconVG.

It is not a pixel-exact format. Different implementations may produce slightly different renderings, due to implementation-specific rounding errors in the mathematical computations when rasterizing vector paths to pixels. Artifacts may appear when scaling up to extreme sizes, say 1 million by 1 million pixels. Nonetheless, at typical scales, e.g. up to 4096 × 4096, such differences are not expected to be perceptible to the naked eye.

Example

Cowbell image

  • cowbell.png is 18555 bytes (256 × 256 pixels)
  • cowbell.svg is 4506 bytes
  • cowbell.ivg is 1017 bytes (see also its disassembly)

The test/data directory holds these files and other examples.

File Format

  • IconVG Specification
  • Magic number: 0x89 0x49 0x56 0x47, which is "\x89IVG".
  • Suggested file extension: .ivg
  • Suggested MIME type: image/ivg

Implementations

This repository contains:

The original Go IconVG package also implements a decoder and encoder.

Disclaimer

This is not an official Google product, it is just code that happens to be owned by Google.


Updated on June 2021.

Owner
Google
Google ❤️ Open Source
Google
Comments
  • Drawing opcodes section could be clarified

    Drawing opcodes section could be clarified

    The drawing opcodes section is a bit confusing. First, the deference to SVG makes everything have an additional level of (very ambiguous) indirection, which is really confusing. SVG is defining all this in the context of a text attribute, not an abstract data model, so a great deal of squinting and hand-waving is required to strictly map the IconVG definition to the SVG spec text.

    There's also some more specific issues in this text. For example, it's not 100% clear exactly how to interpret the parameters, for example:

    The opcode is followed by (2 * RC) coordinates, RC sets of (x, y).

    ...presumably is intended to mean that you read two coordinate numbers and apply the "lineto" command for those two numbers, RC times overall? There's a lot of vagueness here that is only really disambiguated by guessing at the most likely intention based on knowing how SVG path data works, which is not ideal for a spec. :-)

  • Allow only simple, absolute segments

    Allow only simple, absolute segments

    SVG path specification is extremely overcomplicated and error-prone (afaik, the current iconvg C implementation is also incorrect #23). Maybe it would be easier to stick just to M, L, C, Z segments (absolute only)?

    SVG supports relative commands to simplify authoring and reduce size on large coordinates. And I'm not sure it affects iconvg in any way.

  • Meaning of viewBox should be clearer

    Meaning of viewBox should be clearer

    It's not clear what exactly the viewBox means.

    • Must an implementation clip drawing operations outside the viewBox? (Hopefully not, clips are expensive.)
    • May an implementation drop drawing operations outside the viewBox? (Different implementations would have different renderings.)
    • May a drawing draw outside the viewBox?
    • Should an implementation honour the viewBox aspect ratio when rendering the image?
  • Minor rendering optimizations

    Minor rendering optimizations

    Turns out the Path() constructor was taking half the time of rendering an image. Using a static Path removes all of that time.

    The other optimizations are less significant. Path.close() is expensive, but is pointless since we always fill (this may not be a real savings, since the work presumably is just done when painting now, but it does get it off the profile). The nextByte getter is very hot; inlining nextByte seemed to help, but I might be imagining it. The real problem here is that what we really want to do is just walk a buffer with a pointer but Dart doesn't give us that option short of playing with dart:ffi and that seems unnecessarily complicated...

    Tests still pass (tested locally).

  • Gradients through transparent colors

    Gradients through transparent colors

    The spec specifies that colors use premultiplied alpha. This causes problems for gradients that go through fully transparent (0x00000000) colors, since there is no way to know what the lerped color value should be. For example, a gradient from (RGBA) 0x00000000 to 0xFFFF00FF could be going from transparent black to opaque yellow, or transparent yellow to opaque yellow, or transparent green to opaque yellow, each of which has rather different effects.

    The spec does not specify how to handle this.

    Some of the golden images suggest that 0x00000000 should be treated as fully-transparent whatever-happens-to-be-the-next-stop?

  • Can LOD be set to NaN?

    Can LOD be set to NaN?

    The specification states that:

    It is valid for the 4 byte encoding to represent infinities and NaNs, but if not loaded into LOD0 or LOD1, the subsequent rendering is undefined.

    This suggests that LOD0/1 can be set to NaN, but nowhere in the spec mentions the behavior in that case.

  • IconVG virtual machine also has x and y registers

    IconVG virtual machine also has x and y registers

    One of the important but implicit details about an IconVG virtual machine is that in addition to all the described registers, it also holds x and y registers (float values of some sort; I guess the precision isn't strictly observable), which must be updated as drawing opcodes are run. Currently this is only implied by the deference to the SVG spec and its definition of "current point".

  • Metadata block error conditions underdefined

    Metadata block error conditions underdefined

    It's not clear if it's legal for data in a metadata block to extend past the end of itself.

    For example, consider a situation where the metadata section has a block declared with length 0. The byte after the length gives the MID. Suppose (for simplicity) that it's not recognized. That byte also then gives the first opcode of the file. Is that valid?

    I can imagine (absurd) situations where an IconVG serializer finds ways to overlap data in this way to save a few bytes...

    Similarly, is it valid for a metadata block to be too long? e.g. what if a MID=0 block has length 1024? Are the extra bytes just ignored, or is that an error?

  • Clarity on LOD Jump decoding

    Clarity on LOD Jump decoding

    The spec mentions that an LOD Jump is followed by two floating point numbers

    The JumpCount is followed by two floating point numbers, LOD0 and LOD1

    However, in tests/data/lod-polygon.iconvg.disassembly, they appear to be decoded as coordinate numbers.

    3a            #0003 Jump Level-of-Detail
    07                  Target: #0007 (PC+3)
    81                  +0
    02 d0               +80
    

    The spec mentions early on that floating point numbers always take four bytes.

    Floating point numbers are always encoded in 4 bytes: the little-endian encoding of a 32-bit IEEE 754 float32 number.

    Following this leads to incorrectly decoding lod-polygon.

    I suggest the verbage be updated to say that LOD0 and LOD1 are coordinate numbers.

    Specifications

    • Version: FVV1
    • Platform: N/A
  • "The suggested palette is encoded in at least one byte." unclear

    The MID 1 section of the spec says:

    The suggested palette is encoded in at least one byte. The low 6 bits of that byte form a number N. [...] The chunk then contains N+1 explicit colors, in that 1, 2, 3 or 4 byte encoding.

    It's not clear what the "at least one byte" part of this means. Since N cannot be negative, and there's always N+1 colors, wouldn't a more accurate statement be "at least two bytes"? It may be clearer to just say "The low 6 bits of the first byte of the metadata block after the MID form a number N...".

    See also https://github.com/google/iconvg/issues/11.

  • Clarify 2 byte color encoding

    Clarify 2 byte color encoding

    From the example I believe this is what was intended? A literal interpretation of the original text could be interpreted as saying the color values literally are just 4 bits per channel, but in 8 bit color space, so the brightest you can generate in each channel is 0x0F, which doesn't match the example.

  • Call opcodes and updated encoder

    Call opcodes and updated encoder

    Hello.. love this project. I was sort of obsessed today with trying to create a function to output text.. which I think might not be possible, but it seems like at least I can make a function for outputting a character at a time. But looking at the code, seems that call is not implemented. Also would you consider updating the encoder for the new version? I understand if you have other obligations. Just wanted to mention my interest in the continued work.

  • Q: Recommended in-browser IconVG decoder?

    Q: Recommended in-browser IconVG decoder?

    Hi! Do you know of any usable work, or have any recommendations, for IconVG decoding in the browser?

    I'm thinking of something that'd be able to replace inline elements, like say <img src='data: image/x-iconvg;base64,iklWRwMLEVFRsbE1gVkzWYGBqTWFlTR9lX19NYV1NH11fW2I' />, with the rendered image.

    I suppose compiling @Hixie's contributed DART decoder to JS might be a fruitful approach – though of course supporting the current IconVG format would be preferred.

    Thanks!

  • Specify color space (sRGB?)

    Specify color space (sRGB?)

    I didn't see a mention of either "color space" nor "srgb" in https://github.com/google/iconvg/blob/main/spec/iconvg-spec.md, and neither did I find references in the original IVG spec. I believe the (implicit) color space should be specified, and because colors are limited to 32 bit, I suggest the common sRGB color space. As a corollary, conformant rasterizers must blend and compute gradients in linear RGB space.

  • Design: Coordinates Encoding

    Design: Coordinates Encoding

    As per #29, it seems that we limit ourselves to lines, quadratic Bezier and cubic Bezier curves. This would change the coordinates distribution and thus gives an opportunity to simplify and optimize the coordinates encoding.

    Concrete Analysis

    To get a gist of the typical usage, I've analyzed the Material Design Icons as of Templarian/[email protected] (which also includes the Google's icon set). A quick and dirty Python script used is available here.

                   0       1       2       3       4       5       6
            --------------------------------------------------------
        M |    22073       2       0       0       0       0       0 |    22075
        L |    16774    3547   10394    3325    1668     154      18 |    35880
        C |    17939    4987    5525     873     221      46       1 |    29592
        Q |        9      66      13      28      19       0       0 |      135
        Z |     5614       0       0       0       0       0       0 |     5614
            ---------------------------------------------------------+---------
     line |    18816    3221    8243    1572     701      55       9 |    32617
            ---------------------------------------------------------+---------
               62409    8602   15932    4226    1908     200      19 |    93296
    

    This table shows the number of operations and (run length - 1) in bits. So 0 corresponds to a run of 1, 1 to a run of 2, 2 to runs of 3--4, 3 to runs of 5--8 and so on. All shapes have been normalized to one of M, L, C, Q and Z; arcs in particular have been converted to cubic Bezier curves with the same algorithm as the current C version of IconVG.

    It seems that there are significant gaps between 2--3 bits and 4--5 bits. This is of course a characteristic of this particular icon set, but it seems that we can safely limit the max run length to 16 with a minimal size increase (<0.3% in this case, theoretically 6.25% max).

    The "line" row is a subset of L where only perpendicular lines are allowed. This was to see if having separate V or H opcodes with a run is desirable; it seems not, given that a vast majority is a run of just one. It however shows that most lines are perpendicular, suggesting a per-coordinate flag.

                  rel=0   rel=2   rel=3   rel=4   rel=5   rel=6  no rel
               --------------------------------------------------------
       abs=0 |      477       2      51      32      14      10     167 |      753
       abs=1 |     2068     164     283     174      90      68     737 |     3584
       abs=2 |    17969     516    3415    1192    1035     933    6386 |    31446
       abs=3 |    26993    1290    6440    5666    4693    1025   13364 |    59471
       abs=4 |    53465    3088   15459   12100    7933       4   29965 |   122014
       abs=5 |    55161    2272   10986    5645    7161    4601   23959 |   109785
       abs=6 |        0       0       0       0       0       1       0 |        1
      no abs |    91903    2418    2467    1134     740      39  174819 |   273520
               ---------------------------------------------------------+---------
                 248036    9750   39101   25943   21666    6681  249397 |   600574
    

    This table shows the frequencies of coordinates that can be safely represented in one-byte absolute or relative encoding. I've made tons of assumptions:

    • No further quantization has been performed. If the number is not close enough (±0.01) to the nearest integer it was assumed to not fit in one byte at all.

    • The icon set has a fixed view box of (0,0)--(24,24). This means that absolute integral coordinates almost always fit in 5 bits. To be fair I think this small view box does model the post-quantization distribution. I've also tested with every coordinate multiplied by 2--10, 16 and 100; the entire table is too large to include here though.

    • There is no relative encoding with a single bit, since it will entirely consist of a sign bit. For more bits 2's complement representation was assumed.

    • The relative encoding always refers to the last coordinates. This means that, say, if there are 2 coordinates per one operation then the second coordinates are encoded relative to the first coordinates. This is different from SVG but seems reasonable especially given that we no longer has arcs (which center points significantly deviate from the path). Just to be sure I've also tested with SVG-like reference coordinates and found them to be much worse.

    • The initial coordinates used for the relative encoding are (0,0). There might be a better default or even a general way to maximally use available one-byte space, but such improvements cannot harm this baseline encoding.

    • We don't care about the exact encoding (would it be 2 bytes quantized or 4 bytes IEEE 754?) if the number doesn't fit to one byte in any encoding. I do think it should be quantized to 2 bytes in that case.

    There are two kinds of encodings imaginable with this table.

    1. Use a separate flag, allocate A bits to absolute and B bits to relative. This would use 1+max(A,B) bits; the asymmetric A != B cases can be used to stuff other encodings.
    2. Allocate A bits to absolute, but switches to relative if the encoded number is less than 2^B. This would use A bits; both the absolute-only encoding (B = 0) and the relative-only encoding (B = A) are included.

    In addition to this, it is possible that coordinates are multiplied by some scaling factor, possibly differently for absolute and relative encodings. The shared scaling factor models the optimization performed by authoring tools, so it doesn't need to be a part of the encoding itself. The ratio between absolute and relative encodings would have to be fixed or somehow encoded however.

    I've simulated both encodings with all possible parameters and collected the best and runner-ups within 10% of the best (plus a selected few indicated with *). The first number is the number of required multi-byte encodings, so lower is better.

    4 BITS:
    236518   4 bits 1x absolute
    246139   4 bits 1x absolute, 2 bits reinterpreted as 1x relative
    253685   4 bits 1x absolute, 3 bits reinterpreted as 1x relative
    268101*  1 bit flag, 3 bits 1x absolute or 3 bits 1x relative
    
    5 BITS:
    181894   5 bits 1x absolute
    193787   5 bits 1x absolute, 2 bits reinterpreted as 1x relative
    211320*  1 bit flag, 4 bits 1x absolute or 4 bits 1x relative
    
    6 BITS:
    161368   6 bits 2x absolute, 2 bits reinterpreted as 1x relative
    161855   6 bits 2x absolute
    169863   6 bits 2x absolute, 3 bits reinterpreted as 1x relative
    174859   1 bit flag, 5 bits 1x absolute or 5 bits 1x relative
    175599   1 bit flag, 5 bits 1x absolute or 4 bits 1x relative
    176733   1 bit flag, 5 bits 1x absolute or 3 bits 1x relative
    181893*  6 bits 1x absolute
    
    7 BITS:
    156161   7 bits 4x absolute, 3 bits reinterpreted as 1x relative
    156467   7 bits 4x absolute, 2 bits reinterpreted as 1x relative
    157162   1 bit flag, 6 bits 2x absolute or 6 bits 1x relative
    157174   1 bit flag, 6 bits 2x absolute or 5 bits 1x relative
    157506   1 bit flag, 6 bits 2x absolute or 4 bits 1x relative
    158129   1 bit flag, 6 bits 2x absolute or 3 bits 1x relative
    158312   7 bits 4x absolute
    159624   1 bit flag, 6 bits 2x absolute or 2 bits 1x relative
    161367   7 bits 2x absolute, 2 bits reinterpreted as 1x relative
    161579   1 bit flag, 6 bits 2x absolute or 0 bits 1x relative
    161854   7 bits 2x absolute
    164619   7 bits 4x absolute, 4 bits reinterpreted as 1x relative
    169862   7 bits 2x absolute, 3 bits reinterpreted as 1x relative
    174819*  1 bit flag, 5 bits 1x absolute or 6 bits 1x relative
    181893*  7 bits 1x absolute
    
    8 BITS:
    129256   8 bits 10x absolute, 3 bits reinterpreted as 1x relative
    129903   8 bits 10x absolute, 4 bits reinterpreted as 1x relative
    130264   8 bits 10x absolute, 2 bits reinterpreted as 1x relative
    131482   8 bits 10x absolute
    138738   8 bits 10x absolute, 5 bits reinterpreted as 1x relative
    152645*  1 bit flag, 7 bits 4x absolute or 7 bits 100x relative
    174819*  1 bit flag, 5 bits 1x absolute or 7 bits 1x relative
    181893*  8 bits 1x absolute
    

    At least for this particular icon set, both encodings seem to perform relatively well, especially with scaling. The first kind of encodings does leave additional opcode space though so they are preferred. It also seems that 2x and 10x scaling factors are common, where the latter is perhaps an artifact from the decimal encoding of SVG.

    It should be also noted that there are disproportionally many coordinates that are exactly equal to the previous (i.e. rel=0). This is, of course, the original rationale of H/V opcodes. Any efficient encoding should take care of that.

    Concrete Proposal

    There would be five more sets of opcodes in the combined styling-drawing mode:

    • 16 L opcodes, corresponding to 1--16 line segments.
    • 16 C opcodes, corresponding to 1--16 cubic Bezier segments (thus 3x coordinates).
    • 16 Q opcodes, corresponding to 1--16 quadratic Bezier segments (thus 2x coordinates).
    • one Z opcode, closing the current path. If there is no current path this is a nop.
    • one ZM opcode, closing the current path and move to the following coordinates.

    Alternatively, if the opcode space is sufficient the following opcodes might be possible as well:

    • 16 L, C and Q opcodes as above.
    • 16 ML, MC and MQ opcodes. They have an additional pair of coordinates to move before other coordinates.
    • one Z opcode.

    In any case coordinates always come in pairs, in the order of x then y. Each coordinate is encoded as follows.

    <- LSB     MSB ->
    +-+-+-----------+
    |1|Z|   number  | one-byte absolute
    +-+-+-----------+
    
    +-+-+-+---------+
    |0|1|Z|  delta  | one-byte relative
    +-+-+-+---------+
    
    +-+-+-+-+-------+---------------+
    |0|0|1|Z|         number        | two-byte absolute
    +-+-+-+-+-------+---------------+
    
    +-+-+-+---------+---------------+-------------+-+-------------+-+
    |0|0|0|                mantissa               |    exponent   |S| four-byte absolute
    +-+-+-+---------+---------------+-------------+-+-------------+-+
    

    One-byte absolute encodes an absolute integer from -32 to 31. The actual number encoded is (integer + 32).

    One-byte relative encodes an integral difference from -16 to 15. The actual number encoded is (difference + 16). The reference coordinate for x is always the previous x decoded, even in the previous operations or operations with multiple coordinates pairs (unlike SVG path); same for y. The reference coordinates for the first coordinates are (0, 0).

    Note: This particular encoding corresponds to "1 bit flag, 6 bits 2x absolute or 4 bits 1x relative" above. (Due to the scaling difference, the specified encoding of "1 bit flag, 6 bits 2x absolute or 5 bits 2x relative" is no worse than it.)

    Note: I've also experimented with an opportunistic absolute encoding, where if the absolute range and relative range completely overlaps the relative range is reinterpreted as a distinct absolute range. This sadly had no effect for this particular icon set. Moreover reference coordinates have to be an exact integer for this to work, and it is very hard to ensure that this is repeatable. It is possible, but the resulting complexity didn't justify itself.

    Two-byte absolute encodes an absolute number from -64 to (64 - 1/64) in little endian. The actual number encoded is (number + 64) * 64.

    Four-byte absolute encodes an IEEE 754 binary32 number in little endian. The encoded number has only 20 bits of coded mantissa (compared to 23 in the original); the lowest 3 bits are fixed to zero, allowing a direct conversion from the wire format to the number (#33). I personally don't want this at all, but the format's flexible view box demands this unfortunate addition.

    A flag bit Z is in the lowest position of the decoded integer and, if set, indicates that next coordinates use a compressed relative zero and only one of two coordinates are encoded. Z is assumed to be unset in the four-byte absolute encoding. (As mentioned above, I expect four-byte encoding to be very uncommon anyway.)

    In the initial state, Z in the x coordinate (hereafter ZX) and Z in the y coordinate (hereafter ZY) are interpreted as follows:

    • ZX=0, ZY=0: Both x and y are encoded for next coordinates.
    • ZX=1, ZY=0: Only y is encoded for next coordinates. The x coordinate is assumed to be same to the previous (reference) x coordinate.
    • ZX=0, ZY=1: Only x is encoded for next coordinates. The y coordinate is assumed to be same to the previous (reference) y coordinate.
    • ZX=1, ZY=1: Reserved. I currently don't have any good idea for this case.

    In the state where the only single coordinate is encoded, Z is interpreted as follows:

    • Z=0: Both x and y are encoded for next coordinates.
    • Z=1: Different coordinate is encoded for next coordinates. In the other words, if x was encoded this time, Z=1 indicates that only y would be encoded next time, and so on. It is highly unlikely that the same component is repeatedly zero (only possible with some Bezier curves), so this encoding optimizes for the much more common case.

    It is invalid that the very last coordinates in the run have any Z bit set. (This can be changed to affect the next run for optimization, but I'm not sure it's worth.)

    It is equally valid to make this in the other direction, Z=1 indicating previous coordinates had a zero. This however was more difficult to specify and performed slightly worse than the current proposal (70.5% vs. 70.0% of the original).

  • Make binary32 numbers interpretable in place

    Make binary32 numbers interpretable in place

    Currently all number encodings except for natural numbers use IEEE 754 binary32 for the longest (4-byte) case. Since there are 30 bits of data the lowest two bits of the mantissa is assumed to be zeroes, but the actual encoding has ones so they can't be read as is. This is particularly annoying when the implementation language doesn't natively support the binary32-uint32 reinterpretation. Since otherwise the choice of those two bits doesn't matter, I propose to flip them.

(Simple String Format) is an syntax of format and a library for parse this.

SSFMT (Simple String Format) is an syntax of format and a library for parse this. SSFMT != {fmt} SSFMT is NOT an API/library for parse {fmt} syntax !

Jan 30, 2022
Shows different icons for 64 and 32-bit DLLs. Register with RegSvr32 to install

DllIconHandler This project demonstrates how to create a Shell Icon Handler, that is loaded by Explorer.exe. An icon handler can show different icons

Nov 10, 2022
A remote start arduino sketch, written for a Volkswagen Golf Gti MK4. Icons provided by Icons8
A remote start arduino sketch, written for a Volkswagen Golf Gti MK4. Icons provided by Icons8

Introduction ?? This is an arduino sketch that enables the use of a sim-reader in order to remotely start a vehicle Description This Arduino sketch is

Feb 18, 2022
The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.
The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.

OpenEXR OpenEXR provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the mot

Nov 21, 2022
A library to handle Apple Property List format in binary or XML

libplist A small portable C library to handle Apple Property List files in binary or XML format. Features The project provides an interface to read an

Nov 14, 2022
C++ implementation for a binary data storage format.

bsmlib- A C++ library for loading and writing binary data to and from files. bsmlib provides functions for loading, modifying, and saving BSM (Binary

Oct 9, 2022
GraphicsFuzz provides tools for automatically finding and simplifying bugs in graphics drivers, specifically graphics shader compilers.

GraphicsFuzz GraphicsFuzz is a set of tools for testing shader compilers GraphicsFuzz provides tools for automatically finding and simplifying bugs in

Nov 18, 2022
F Graphics Library (FGL) is a small graphics C++ portable library for LCD displays on embedded systems

F Graphics Library (FGL) Full documentation: fgl.docsforge.com (By Filipe Chagas) F Graphics Library is a C++ library that I created for use in embedd

Oct 31, 2022
CSC404: Computer Graphics [CG] & CSL402: Computer Graphics Lab [CG Lab]

COMPUTER-GRAPHICS-AND-COMPUTER-GRAPHICS-LAB CSC404: CG & CSL402: CG LAB [SEMESTER IV] Syllabus CG - Reference Books THE WALL MEGA SATISH - AUTHOR CG C

Apr 28, 2022
Treexy is a library that implements a compact hierarchical data structure that can store and manipulate volumetric data, discretized on a three-dimensional grid
Treexy is a library that implements a compact hierarchical data structure that can store and manipulate volumetric data, discretized on a three-dimensional grid

Treexy is a library that implements a compact hierarchical data structure that can store and manipulate volumetric data, discretized on a three-dimens

Nov 10, 2022
My new zigbee project. Wireless temperature and humidity mini sensor with electronic ink display 2.13 inches, low power consumption, compact size, enclosure with magnets.
My new zigbee project. Wireless temperature and humidity mini sensor with electronic ink display 2.13 inches, low power consumption, compact size, enclosure with magnets.

My new zigbee project. Wireless temperature and humidity mini sensor with electronic ink display 2.13 inches, low power consumption, compact size, enclosure with magnets. The device use SHTC3 sensors, chip CC2530, battery CR2477.

Nov 20, 2022
DimensionalAnalysis - A compact C++ header-only library providing compile-time dimensional analysis and unit awareness

Dimwits ...or DIMensional analysis With unITS is a C++14 library for compile-time dimensional analysis and unit awareness. Minimal Example #include <i

Jul 8, 2022
A simple processor emulator written in c++ that can parse and execute x32 code. x32 is binary code made by me for this processor.

A SIMPLE PROCESSOR EMULATOR AND CODE EXECUTOR The Repository This is a fairly new project and is still heavy in development. If you find and bugs feel

Jan 20, 2022
The simple UEFI application to create a Windows Platform Binary Table (WPBT) from the UEFI shell.
The simple UEFI application to create a Windows Platform Binary Table (WPBT) from the UEFI shell.

WPBT Builder This is a simple UEFI application to create a Windows Platform Binary Table (WPBT) from the UEFI shell. Motivation WPBT is one of the Adv

Oct 20, 2022
Implementation and tutorial for a dynamic vector data-structure in C.

Vec: A Dynamic Vector in C The subject.md file contains exercises for this implementation if you want to do it yourself. In that case, don't peek at t

Oct 17, 2022
A C++ fast and lightweight 3D vector library

Vector3D A C++ fast and lightweight 3D vector library. Usage On your C++ code include the file. #include <vector.h> Then, declare your vector and ini

Sep 23, 2022
An implementation of a weak handle interface to a packed vector in C++

Experimental handle container in C++ Overview Following on from c-handle-container, this library builds on the same ideas but supports a dynamic numbe

Mar 11, 2022
Highly efficent, caching, copy-on-write lua vector math library

lua-vec Table constructions in Lua are expensive, creating and destroying thousands of "vector" tables frame to frame in an engine can cause serious p

Jul 23, 2022
C++11 header-only library that offers small vector, small flat map/set/multimap/multiset.

sfl library This is header-only C++11 library that offers several new containers: small_vector small_flat_set small_flat_map small_flat_multiset small

Nov 15, 2022