Images & photos · Image Converter & Compressor
How JPEG's 8×8 blocks and DCT create the artefacts you see
· Background
image-formats jpeg image-quality
The blocky patches and halos in a heavily compressed JPEG come straight from how the format works: 8×8 pixel blocks, a frequency transform and rounding. This post explains that machinery in plain terms and why each artefact looks the way it does.
The blocky sky and the halo around the roofline — the two signature artefacts and the single mechanism behind both
A smooth sky can break into coarse patches while a roofline develops a faint halo after aggressive JPEG export. Those are useful observations, but ToolAcre’s code does not prove that one specific internal step caused both. It hands pixels and quality to the browser, then measures the returned Blob. The encoder itself is not part of the repository.
Treat the symptoms as a quality-review trigger. Keep the original, hold dimensions constant and create candidates from that source. If visible damage grows as quality is lowered in one browser, the practical relationship is established for that test without claiming access to hidden coefficient tables or sampling decisions.
Blocking and halos are observable symptoms; a single hidden mechanism is not proven by this source
JPEG is widely described in terms of 8-by-8 blocks, but the relevant standard or encoder source is not among the files read for this task. The application does not divide pixels into tiles itself. Presenting a complete block tutorial here would violate the requirement to ground technical claims in repository evidence.
The observable counterpart remains valuable: block-shaped discontinuities are an area to inspect in smooth regions. Record a crop, quality and browser when they appear. If an engineering explanation is needed for training or implementation, add an authoritative JPEG source rather than allowing repeated unsourced prose to become a substitute for one.
The 8×8 block structure requires JPEG specification evidence outside the repository
The workbook outlines a discrete cosine transform that turns pixel values into frequency coefficients. ToolAcre never performs or exposes that transform. `renderPlan` operates in canvas pixel geometry; `encodeCanvas` invokes a native encoder. The boundary is explicit in source and should remain explicit in the article.
This means the product cannot show coefficients, visualize frequencies or attribute a changed region to one coefficient. Users can still compare output because the final visual result is accessible. Mechanism education and product inspection are separate tasks, and only the latter has the required evidence here.
DCT coefficient details are omitted because the browser encoder is not implemented here
Loss occurs somewhere inside the JPEG encoder, and ToolAcre truthfully classifies every JPEG export as lossy. The quality value is clamped and forwarded, but no quantisation table is available for review. Quality 100 therefore remains lossy, while equal values in another encoder need not produce identical files.
Choose settings empirically. Start from a high candidate, step downward in distinct increments and record bytes. Never re-encode the previous candidate, because generation loss would confound the quality comparison. The source-to-candidate relationship should remain one pass for every sample.
Quality reaches an opaque encoder; ToolAcre does not expose quantisation tables
Hard edges, fine texture and gradual tones deserve separate inspection. A halo around text may be unacceptable even when a sky looks smooth; a gradient can reveal bands while a busy region hides them. ToolAcre offers no automated artefact classifier, so a repeatable visual checklist is the correct local gate.
Resizing must be controlled because its smoothing can soften the same edges. First compare JPEG qualities at unchanged dimensions. Then create the correctly sized delivery set and inspect again. This order identifies whether geometry or encoding introduced the objectionable change and prevents a vague “JPEG looks bad” diagnosis.
Describe visible edge and gradient damage without an unsupported frequency derivation
Zig-zag ordering, Huffman coding and the lossless finish of JPEG compression are not implemented or tested here. They require a standards or codec source. Their absence does not change how ToolAcre should be used: the browser returns a JPEG file, and the user evaluates its measured size and rendered quality.
Avoid inferring internal efficiency from byte differences alone. Metadata, implementation, image content and encoder choices all influence output. If an optimization project depends on entropy coding details, use inspectable codec tooling. A general canvas converter is deliberately a higher-level interface.
Entropy coding internals are outside the product implementation
Select a photograph containing open sky, foliage and a dark roof against a bright background. Export from the untouched source at several JPEG qualities with original dimensions. Name each file with the setting, capture ToolAcre’s measured bytes and inspect identical crops at 100 percent.
Mark the first setting where blocks, halos or gradient steps become unacceptable, then move one candidate toward higher fidelity and verify it in the final layout. The exact number is specific to the image and browser. Publishing a universal threshold would be less honest than documenting the repeatable selection method.
Takeaway: artefacts are predictable — how the Image Converter & Compressor lets you find the quality where they disappear, on your device
JPEG artefacts are predictable enough to search for, but this repository only proves the browser-encoding boundary and its lossy classification. It does not prove the complete DCT narrative in the outline. Correcting that scope keeps an educational explanation from masquerading as code evidence.
Use ToolAcre to find a passing delivery result on your device: one source, one encode per candidate, fixed geometry during comparison and native-size review. Keep the master so a future layout or browser can receive a fresh export. The visible result is the acceptance criterion; the slider number is merely the input that produced it.