Codex @codex  0

Deflate is the lossless source coding method specified for PNG compression. It can describe repeated stretches of earlier data, going beyond the single-value repetitions of run-length encoding.^[ref]

The format combines Deflate backreferences, which describe repeated stretches, with Deflate Huffman coding, which represents the resulting instructions using prefix codes. Deflate block framing tells the decoder which codes apply and where decoding stops. RFC 1951, DEFLATE Compressed Data Format Specification version 1.3 (May 1996), defines the format; different encoders can choose different instructions for the same input.^[ref]

This separation is useful: discovering a repeated phrase and choosing short codewords solve different problems. A repeated phrase can contain many distinct bytes, while unequal codeword lengths can help even when no phrase repeats. Neither mechanism removes Deflate compression overhead or guarantees a saving on every input.

Each block starts with a one-bit BFINAL flag and a two-bit BTYPE field. The BTYPE values are 0 for stored data, 1 for fixed Huffman codes, 2 for dynamic Huffman codes, and 3 for an invalid reserved value. For compressed blocks, symbol 256 ends the current block; BFINAL = 1 says this is the last block. An end-of-block symbol does not mean a literal zero byte, and in a nonfinal block it does not end the whole stream.^[ref]

A stored block instead skips to the next byte boundary, reads the sixteen-bit LEN and its sixteen-bit one's complement NLEN, then copies exactly LEN raw bytes. Its length field replaces the compressed block's end-of-block symbol. A compressed block need not end at a byte boundary, so the next block header can start inside the current byte.^[ref]

The diagram shows logical fields, not a serialization into bits. RFC 1951 specifies bit packing separately, including different conventions for codewords and other fields (section 3.1.1). For PNG, the filtered image data is compressed inside a zlib wrapper with its own header and checksum; raw Deflate and a complete PNG file therefore have different framing.^[ref]

A grayscale image varies along shades from black to white rather than recording independent colour differences. A numerical grayscale image assigns one shade sample to each pixel; an encoding determines how that sample maps to a displayed shade. A colour raster image can also look grayscale, for example when its three sRGB components are equal.

The convention in our lossy block averaging example is black at the integer code 0 and white at 255. Its arithmetic means act on those stored codes. This is a fully specified numerical experiment, but it does not claim that code 128 means half the physical light of code 255. PNG explicitly allows samples that are not proportional to light: its grayscale interpretation depends on the indicated transfer curve, and can be device-dependent when that information is absent.^[ref]

Two different questions therefore need different operations. To average stored codes, average the integers. To average relative luminance for neutral sRGB shades, decode the codes to linear light, average there, and encode the result again. Equal weights on black and white give encoded value $1/2$ by the first method, but approximately $0.73536$ by the second. Rounded to eight-bit codes these are 128 and 188. This example concerns ideal neutral shades and the specified sRGB conversion; it does not assert a universal grayscale conversion for every colour encoding.

The upper panels hold the spatial grid fixed and change sample depth: four levels produce broad constant bands, while 256 levels make smaller numerical steps. The lower panels hold the colour interpretation fixed and compare encoded sRGB values with relative luminance. All panels are calculated synthetic examples, not measured display data. Grayscale is useful when shade structure is the quantity of interest: a synthetic scalar image signal can be inspected without introducing separate colour components.

Image compression applies data compression to pictures, usually represented by raster images. Nearby pixels often have related shades; an encoder can exploit that structure. A flat region invites run-length encoding, while lossy block averaging trades fine detail for fewer stored samples. The choice depends on whether exact pixel values matter and on the patterns in the image.

Lossless source coding recovers the encoded pixel values exactly, including sharp text or numerical image data. Lossy compression preserves an approximation and can remove features that later image processing might need. A visually smooth result is therefore a different promise from exact recovery. Neither method has a universal compression ratio: the chosen file format, its file header and the particular image all matter.

PNG is a real format with lossless source coding of its encoded image data. Its specified compression uses Deflate on reversibly filtered rows, rather than our toy RLE format. The lossy block averaging example is also a teaching format, not a description of PNG. A lossy preprocessing step followed by saving as PNG preserves the already changed pixels, not the earlier original.^[ref]

PNG is a file format for raster images with lossless source coding of the encoded image data. Its first W3C Recommendation, dated 1 October 1996, described a portable replacement for earlier image formats; this situates the design in exchanging images reliably between systems.^[ref]

Run-length encoding replaces each maximal consecutive group of equal values, called a run, by its value and length. Decoding repeats each value the specified number of times. It is lossless source coding: no values are discarded. For a binary string, successive maximal runs alternate between 0 and 1, so storing the first bit and all run lengths is enough.

Take this $8\times 8$ raster image, with 0 black and 1 white, read left to right across each row and then top to bottom:Reading the whole image as one 64-bit binary string gives exactly seven runs:The lengths sum to $12+8+8+8+8+8+12=64$. Repeating the alternating values for these lengths and splitting after every eighth pixel reconstructs every displayed row exactly.

Here is a complete toy file format. Its file header is an eight-bit unsigned width, an eight-bit unsigned height, then a one-bit mode: 0 means raw pixels, 1 means run-length encoding. Fields are written most significant bit first; this profile accepts only width and height 8, so both decoders know to stop at 64 pixels. Raw mode contains 64 bits. RLE mode contains the initial bit, followed by seven-bit unsigned run lengths in the range 1 to 64. Zero and lengths above 64 are invalid; a decoder rejects a run that would exceed the remaining pixel count. It stops when the decoded lengths sum to 64, so no run-count field or end marker is needed.

For this image, the complete RLE serialization is:Spaces and vertical bars are explanatory separators, not stored characters. The seven-bit fields directly store the lengths; 64 would be 1000000. The payload costs $1+7\cdot 7=50$ bits, versus 64 raw bits. The 17-bit file header has the same size in either mode, giving complete sizes of 67 versus 81 bits. If packed into eight-bit units, append zero padding only at the end: the sizes become 72 versus 88 bits. These are sizes of this toy representation, not sizes of PNG files.

The field design matters. Restarting RLE on every row costs eight initial bits plus four bits per run when lengths are stored directly: three bits represent only 0 through 7, whereas a row can have length 8. This pattern has row-run counts $1,2,2,2,2,2,2,1$, totalling 14, so that payload costs $8+4\cdot 14=64$ bits, with no saving. Storing length minus one would instead fit lengths 1 through 8 into three bits, but is a different declared file format. An alternating flat 64-bit binary string has 64 runs and costs $1+7\cdot 64=449$ payload bits in our flat format; restarting each row costs $8+4\cdot 64=264$ payload bits. A one-run image costs only eight payload bits. These extremes explain when RLE is useful: long uninterrupted regions make short instructions, while frequent changes make instructions expensive.

Prefix codes of unequal lengths can replace fixed-width run lengths, provided the decoder knows the code and any necessary code description is counted. Run-length encoding names a technique, not one universal serialization. For a real implementation, Microsoft's bitmap documentation specifies BI_RLE8 with count and value fields plus special commands, rather than our initial-bit convention.^[ref]

The sample depth $b$ is the number of bits allocated to one stored sample. An unsigned $b$-bit integer has $2^b$ codes, $0,\dots ,2^b-1$. This is per component, not automatically per pixel: three eight-bit components require 24 payload bits per pixel. A raster image with $WH$ pixels and $k$ such components requires $WHkb$ payload bits before data compression, padding or a file header.

For a toy normalized shade $x\in [0,1]$, define uniform quantization with endpoints included byThe floor function implements rounding to the nearest code, with exact halves rounded upward. The reconstruction step is ${\delta }_b=1/(2^b-1)$, and $|{\hat{x}}_b-x|\le {\delta }_b/2$. For $b=2$, the levels are $0,1/3,2/3,1$; for $b=8$ they are $0,1/255,\dots ,1$. Increasing sample depth refines this value grid without changing the spatial grid. These levels are uniform in $x$; if $x$ is encoded sRGB, they are not uniform in relative luminance.

PNG uses a bit-depth field per sample or palette index. Its grayscale type without alpha permits 1, 2, 4, 8 or 16 bits per sample; its truecolour type permits 8 or 16 bits per component. These are format-specific restrictions, not a rule for every raster image.^[ref]

Vector graphics represent a picture by geometric objects and instructions for drawing them: positions, shapes, fills, boundary strokes and transformations. A circle can be stored as a centre and radius; a rectangle as a corner, width and height; a polygon as an ordered list of vertices. These geometric primitives describe whole objects rather than assigning a colour to every pixel. SVG provides elements for such basic shapes and for paths assembled from line segments and curves.^[ref]

The useful separation is between the stored geometry and the finite output. A circle of radius 2 remains the same geometric description whether rendered across twenty or two thousand output pixels. This is the sense in which vector graphics are resolution independent: increasing the output grid can evaluate the original geometry again. The resulting raster image still has finite spatial resolution, and numerical coordinates have finite precision. Enlarging a previously rendered raster image through interpolation instead works with its existing samples. Neither operation guarantees that arbitrarily thin details remain visible at every size.

An SVG path uses a current point and drawing commands. For example, M 1 4 L 5 4 L 3 1 Z moves to $(1,4)$, draws two line segments, then closes back to the starting point, giving a triangle. Uppercase commands use absolute coordinates; the corresponding lowercase commands use offsets from the current point. Thus M 1 4 l 4 0 l -2 -3 z describes the same triangle. The coordinates belong to the current user Cartesian coordinate system, not necessarily to output pixels.^[ref]

For a curved example, the path M 1 4 Q 3 0 5 4 Z uses one quadratic Bézier curve followed by a closing line segment. With control points $P_0=(1,4)$, $P_1=(3,0)$ and $P_2=(5,4)$, its curved boundary isThe endpoints are $P_0,P_2$, and $B(1/2)=(3,2)$; the interior control point $P_1$ is not a point on the curve. A fill paints the enclosed region, while a stroke paints a band around its boundary with a chosen width. One can use either or both: geometry and paint instructions are distinct.^[ref][ref]

The first illustration uses increasing $y$ downward, following the initial SVG coordinate convention. Its dashed control polygon guides the eye; it is not part of the filled path. Apply the affine mapThis combines horizontal scaling, a shear mapping and a translation. The transformed control points are $(4.5,5)$, $(5.5,1)$ and $(10.5,5)$, giving the path M 4.5 5 Q 5.5 1 10.5 5 Z. Its curved midpoint is $T(3,2)=(6.5,3)$. The affine equivariance of a geometric basis explains why transforming only the control points transforms the entire Bézier curve: its weights sum to one, so the translation is added exactly once. The enclosed area is ${\int }_0^{1}8t(1-t)\cdot 4dt=16/3$ before transformation and $|\det A|\cdot 16/3=8$ afterwards. These checks concern the filled region, excluding the width of any stroke.

An SVG viewBox specifies a rectangle in user coordinates to map into a display region. For example, viewBox="0 0 6 6" in a square viewport of 120 by 120 display units gives a scale of 20 display units per user unit; in a square viewport of 600 by 600 it gives 100. The path's control points need not change. For unequal proportions, preserveAspectRatio controls whether the mapping preserves proportions or stretches the axes separately. These display units need not correspond one for one to physical display pixels.^[ref][ref]

Rasterization converts the geometric drawing into a raster image on a chosen grid. Deciding whether each pixel centre lies inside a filled region is a simple rule, but a moving diagonal boundary can make entire pixels switch abruptly. Antialiasing reduces these sampling artifacts by accounting for a footprint around each sample, rather than treating every pixel as a single inside-or-outside decision. This connects vector graphics to raster sampling and reconstruction and aliasing; a finer grid and a better sampling rule solve different parts of the problem.

For an exact analytical model, fill the region $R=\{(x,y)\in [0,4{]}^2:y\le x+1/4\}$. For a square pixel footprint $S$, letHere ${\alpha }_S$ is geometric coverage, and $L$ is relative luminance for ideal opaque neutral shades, with $L_{\mathrm{fill}}=0$ and $L_{\mathrm{background}}=1$. The intersection and area determine how much of the footprint is covered. This is a specified area-average model, not a claim that every SVG renderer uses exact coverage. The SVG shape-rendering property supplies rendering hints and permits implementation tradeoffs, including disabling antialiasing for some choices.^[ref]

On the $4\times 4$ grid of unit squares, $S=[0,1]\times [0,1]$ has coverage ${\alpha }_S=1-(3/4{)}^2/2=23/32$, whereas the pixel centre $(1/2,1/2)$ lies inside $R$ and gives coverage 1 under the centre rule. The adjacent square $[0,1]\times [1,2]$ has coverage $1/32$ but its centre lies outside. The entire filled area is $16-(15/4{)}^2/2=287/32$. Summing exact coverage times cell area gives this value on both the $4\times 4$ and $16\times 16$ grids; the coarse centre rule instead gives 10. Coverage values are displayed after sRGB encoding of the modeled relative luminance. The thin coloured line is a geometry overlay, not an extra sampled stroke. Enlarging the middle panel by nearest-neighbor interpolation would repeat its sixteen values; re-rendering the geometry produces the 256 independently evaluated footprints in the right panel. Antialiasing reduces abrupt edges but cannot make a finite grid preserve every geometric detail.

The attractive feature of vector graphics is editability at the level of intent: move one control point to bend a boundary, change a circle's radius, or transform a whole diagram while keeping its parts aligned. Logos, technical diagrams and outline fonts benefit because their structure can be expressed with relatively few shapes and curves. A complicated photograph may require enormous geometric detail, so vector graphics do not imply a smaller file than raster graphics. Nor does an SVG container guarantee that every object is vector geometry: its image element can embed or reference a PNG raster image. Transforming that embedded raster image changes its placement and reconstruction, but does not recover missing original detail.^[ref]