Jump to content

QOI (image format)

From Wikipedia, the free encyclopedia
Quite OK Image
Filename extension
.qoi
Magic numberqoif (4 bytes, ASCII)
Developed byDominic Szablewski
Initial release24 November 2021
Latest release
1.0
5 January 2022; 2 years ago (2022-01-05)
Type of formatLossless bitmap image format
StandardSpecification
Open format?Yes
Free format?Yes
Websiteqoiformat.org

The Quite OK Image Format (QOI) is a specification for lossless image compression of 24-bit (8 bits per color RGB) or 32-bit (8 bits per color with 8-bit alpha channel RGBA) color raster (bitmapped) images, invented by Dominic Szablewski and first announced on 24 November 2021.[1]

Description

[edit]

The intended purpose was to create an open source lossless compression method that was faster and easier to implement than PNG. Figures specified in the blog post announcing the format claim 20-50 times faster encoding, and 3-4 times faster decoding speed compared to PNG, with similar file sizes.[1] The author has donated the specification to the public domain (CC0).[2]

Software and language support

[edit]

QOI is supported natively by ImageMagick,[3] Imagine (v1.3.9+), IrfanView (v4.60+),[4] FFmpeg (v5.1+),[5] and GraphicConverter (v11.8+).[6] Microsoft PowerToys (v0.76+) for Windows 10 and 11 adds support for previewing QOI images to the Windows File Explorer.[7][8] Community made plugins are available in GIMP, Paint.NET and XnView MP.[9]

The game engine GameMaker designates bzip2 + QOI as the default format of texture groups since version 2022.1.0.609, to achieve the better compression but still quicker to decompress, while the standalone QOI and PNG formats are optional for the even faster performance and better compabilities respectively.[10][11]

There are also implementations for various languages such as Rust, Python, Java, C++, C# and more.[12] A full list can be found on the project's Git(Hub) repository README.

File format

[edit]
[edit]

A QOI file consists of a 14-byte header, followed by any number of data “chunks” and an 8-byte end marker.

qoi_header {
    char magic[4]; // magic bytes "qoif"
    uint32_t width; // image width in pixels (BE)
    uint32_t height; // image height in pixels (BE)
    uint8_t channels; // 3 = RGB, 4 = RGBA
    uint8_t colorspace; // 0 = sRGB with linear alpha
// 1 = all channels linear
};

The colorspace and channel fields are purely informative. They do not change the way data chunks are encoded.

Encoding

[edit]

Images are encoded row by row, left to right, top to bottom. The decoder and encoder start with {r: 0, g: 0, b: 0, a: 255} as the previous pixel value. An image is complete when all pixels specified by width * height have been covered. Pixels are encoded as:

  • Run-length encoding of the previous pixel (QOI_OP_RUN)
  • an index into the array of previously seen pixels (QOI_OP_INDEX)
  • a difference compared to the previous pixel value in r,g,b (QOI_OP_DIFF or QOI_OP_LUMA)
  • Full r,g,b or r,g,b,a values (QOI_OP_RGB or QOI_OP_RGBA)

The color channels are assumed to not be premultiplied with the alpha channel (“un-premultiplied alpha”). A running array[64] (zero-initialized) of previously seen pixel values is maintained by the encoder and decoder. Each pixel that is seen by the encoder and decoder is put into this array at the position formed by a hash function of the color value.

In the encoder, if the pixel value at the index matches the current pixel, this index position is written to the stream as QOI_OP_INDEX. The hash function for the index is:

index_position = (r * 3 + g * 5 + b * 7 + a * 11) % 64

Each chunk starts with a 2- or 8-bit tag, followed by a number of data bits. The bit length of chunks is divisible by 8 - i.e. all chunks are byte aligned. All values encoded in these data bits have the most significant bit on the left. The 8-bit tags have precedence over the 2-bit tags. A decoder must check for the presence of an 8-bit tag first. The byte stream's end is marked with 7 0x00 bytes followed by a single 0x01 byte.

The possible chunks are:

QOI_OP_RGB

[edit]
Byte[0] Byte[1] Byte[2] Byte[3]
7 6 5 4 3 2 1 0 7 .. 0 7 .. 0 7 .. 0
1 1 1 1 1 1 1 0 red green blue
  • 8-bit tag b11111110 (254)
  • 8-bit red channel value
  • 8-bit green channel value
  • 8-bit blue channel value

The alpha value remains unchanged from the previous pixel.

QOI_OP_RGBA

[edit]
Byte[0] Byte[1] Byte[2] Byte[3] Byte[4]
7 6 5 4 3 2 1 0 7 .. 0 7 .. 0 7 .. 0 7 .. 0
1 1 1 1 1 1 1 1 red green blue alpha
  • 8-bit tag b11111111 (255)
  • 8-bit red channel value
  • 8-bit green channel value
  • 8-bit blue channel value
  • 8-bit alpha channel value

QOI_OP_INDEX

[edit]
Byte[0] (Range: 0 .. 63)
7 6 5 4 3 2 1 0
0 0 index
  • 2-bit tag b00
  • 6-bit index into the color index array: 0..63

A valid encoder must not issue 2 or more consecutive QOI_OP_INDEX chunks to the same index. QOI_OP_RUN should be used instead.

QOI_OP_DIFF

[edit]
Byte[0] (Range: 64 .. 127)
7 6 5 4 3 2 1 0
0 1 dr dg db
  • 2-bit tag b01
  • 2-bit red channel difference from the previous pixel -2..1
  • 2-bit green channel difference from the previous pixel -2..1
  • 2-bit blue channel difference from the previous pixel -2..1

The difference to the current channel values are using a wraparound operation, so 1 - 2 will result in 255, while 255 + 1 will result in 0.

Values are stored as unsigned integers with a bias of 2. E.g. −2 is stored as 0 (b00). 1 is stored as 3 (b11). The alpha value remains unchanged from the previous pixel.

QOI_OP_LUMA

[edit]
Byte[0] (Range: 128 .. 191) Byte[1]
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
1 0 dg dr - dg db - dg
  • 2-bit tag b10
  • 6-bit green channel difference from the previous pixel -32..31
  • 4-bit red channel difference minus green channel difference -8..7
  • 4-bit blue channel difference minus green channel difference -8..7

The green channel is used to indicate the general direction of change and is encoded in 6 bits. The red and blue channels (dr and db) base their diffs off of the green channel difference. I.e.:

dr_dg = (cur_px.r - prev_px.r) - (cur_px.g - prev_px.g)
db_dg = (cur_px.b - prev_px.b) - (cur_px.g - prev_px.g)

The difference to the current channel values are using a wraparound operation, so 10 - 13 will result in 253, while 250 + 7 will result in 1.

Values are stored as unsigned integers with a bias of 32 for the green channel and a bias of 8 for the red and blue channel. The alpha value remains unchanged from the previous pixel.

QOI_OP_RUN

[edit]
Byte[0] (Range: 192 .. 253)
7 6 5 4 3 2 1 0
1 1 run
  • 2-bit tag b11
  • 6-bit run-length repeating the previous pixel

The run-length is stored with a bias of −1. Note that the runlengths 63 and 64 (b111110 and b111111) are illegal as they are occupied by the QOI_OP_RGB and QOI_OP_RGBA tags.[13]

References

[edit]
  1. ^ a b "Lossless Image Compression in O(n) Time". Phoboslab.org. 2021-11-24. Archived from the original on 2022-05-08. Retrieved May 1, 2022.
  2. ^ "QOI The Quite OK Image Format". qoiformat.org. 2023-12-14. Archived from the original on 2023-12-16. Retrieved December 14, 2023.
  3. ^ "ImageMagick - Image Formats". Archived from the original on January 2, 2022. Retrieved May 4, 2022.
  4. ^ "History of IrfanView Changes/Versions". www.irfanview.com. Archived from the original on 2021-01-14. Retrieved 2022-05-10.
  5. ^ "FFmpeg Changelog - Gitweb". ffmpeg.org. Archived from the original on 2022-07-13. Retrieved 2022-07-13.
  6. ^ "GraphicConverter Release Notes version 11.8 (build 5762)". Lemke Software. Archived from the original on 11 February 2023. Retrieved 21 February 2023.
  7. ^ "Release v0.76.0". Microsoft. Retrieved 26 March 2024.
  8. ^ "PowerToys File Explorer add-ons utility for Windows". learn.microsoft.com. 2023-12-04. Retrieved 2024-02-05.
  9. ^ James Hein (16 March 2022). "Moving images to the next level". Bangkok Post. Retrieved April 1, 2022.
  10. ^ "Version 2022.1.0.609". GameMaker Release Notes. YoYo Games. 26 January 2022. Retrieved 26 March 2024.
  11. ^ "Texture Groups". GameMaker Manual. YoYo Games. Retrieved 26 March 2024.
  12. ^ Simon Sharwood. "Developer creates 'Quite OK Image Format' – but it performs better than just OK". The Register. Archived from the original on 2023-06-02. Retrieved 2023-12-30.
  13. ^ Szablewski, Dominic (2022-01-05). "The Quite OK Image Format Specification" (PDF). Archived (PDF) from the original on 2022-04-30. Retrieved 2022-06-05. Public Domain This article incorporates text from this source, which is in the public domain.
[edit]