DEV Community: Lank_M

A 25 MB video target came back at 14 MB, and the fix is checking how far under you landed

Lank_M — Tue, 27 Oct 2026 08:31:45 +0000

I asked x264 for a 25 MB file from a 60-second, 1080p screen recording. It returned 14.0 MB on the single pass and 14.3 MB on the two-pass run. Then I let a quality-based search try as hard as it could, and the smallest it would go down to was still 11.05 MB, with the quality setting pushed almost to the bottom of its scale. The budget was simply bigger than the video needed.

Most of the target-size math I know is about not going over, and this run is the opposite case. Everything below is a single local run on an M4 Mac: FFmpeg 7.1, libx264 at the medium preset, AAC at 128 kbps, one pass per cell, nothing repeated. Sizes are real bytes, and 1 MB here is 1,000,000 bytes.

The formula was never the hard part

The formula is the familiar one: target size times 8, divided by duration. For 25 MB over 60 seconds that is 3,333,333 bits per second, minus the audio. At 128 kbps, 60 seconds of AAC takes about 0.97 MB, and the MP4 container adds roughly 66 KB. On a 1080p action clip I will call clip A, skipping the audio subtraction put the file 3.1% over at 25 MB and 9.2% over at 10 MB. With the subtraction, single pass landed at -0.66% and -0.35%.

On clip A the arithmetic works. The open question is a clip where rate control has nothing hard to chew on, so I made clip B: a synthetic screen recording, 60 seconds at 1080p and 30 fps, with a slide-like page, a moving cursor and scrolling, all drawn frame by frame. It is calmer than a real recording, so read everything about B as this one clip, not as screen recordings in general.

What the 25 MB budget did on a quiet clip

Clip B, 25 MB target	Result	Off target
Single pass, audio subtracted	14,020,677 bytes	-43.9%
Two pass, audio subtracted	14,326,893 bytes	-42.7%
CRF search, range 0 to 51	11,053,804 bytes	-55.8%

The CRF row settled it. I bisected the quality value for the largest file that stayed under the target, and it ran down to CRF 0.4 and stopped at 11.05 MB, with no room left to spend. My first attempt used a range of 14 to 51 and stopped at 4,111,034 bytes, because 14 was the lowest value allowed. When a search ends on the edge of its range, the answer is the range, not the video.

None of this is a bug, since the encoder simply spent less than it was given. The gap is in the wrapper that says "25 MB target, done": it cannot tell you that you were sitting at 56% of the budget (14.0 MB of 25 MB) and never needed the rest, or that the full 1080p frame size fit with room to spare.

The same clip at 10 MB is a different story

Drop the target to 10 MB and the budget is tight again, so the same clip B behaves differently. Single pass with audio subtracted came back 8.65% under, the CRF search 1.6% under (CRF 1.99), and two pass 11,195,510 bytes, which is 12.0% over. On clip B the video bitrate swings from 40 to 5,000 kbps, with sharp spikes where the page changes. My reading, which I did not verify, is that two pass plans around those spikes and ends up too generous.

So a bigger budget is not the only way to miss. Two pass was also the only method that went over target on clip A at both sizes, and CRF bisection never overshot but costs a full encode per trial: 157 to 217 seconds for seven trials on clip A, against about 23 seconds for a single pass.

What I would do with a budget

Treat the target as a ceiling rather than a goal. Subtract the audio and about 70 KB of container first, run one fast pass, and look at the size. If it came back near half of the target, keep that file or spend the spare room on resolution. Whether a hard rate cap such as a maximum bitrate would keep a two-pass run from overshooting on a clip like B, I have not tested.

One note on tools that wrap all this. ImgIng (https://imging.ai/) runs in a desktop browser and has no "compress to this size" setting; it works from presets. Its interface also counts a "MB" as 1,048,576 bytes, so a "25 MB" there is about 4.9% more bytes than the figure I used. On clip B its smart recommendation was accepted and wrote 9,351,418 bytes, while on clip A the same feature rejected its own candidate because the saving was 10.3%, under its 12% bar. The hosted 8mb.video does have a size picker, and for clip B it returned 7,550,319 bytes when I chose 25 MB, at 1280x720. A picker tells you the ceiling, not whether the video needed it, so the under-target check above is still yours to do.

Table structure after OCR: why I'd rather get word boxes than tab-separated text

Lank_M — Mon, 26 Oct 2026 08:04:17 +0000

Should an OCR engine hand back a table, or just word boxes and let the caller build the table? OCR is not my area, so I read it as a caller would: I cut columns out of one set of word boxes through three interfaces. Short version: I'd rather get boxes. Setup: tesseract 5.5.3, English pack, three clean tables I generated (63, 63 and 45 cells), and one browser OCR tool. Every number below belongs to those samples.

Plain text has already lost the columns

First interface: text only. I grouped tesseract's boxes into rows, joined each row's words with single spaces, and split on whitespace. Cell accuracy was 16%, 33% and 84% on the three tables. Cells here contain spaces: Steel Thermos, Power Bank, a full name, a report title.

Second interface: the engine inserts a tab wherever the space between two words exceeds 1.0 times the median word height, and the caller splits on tabs. That gave 84%, 100% and 91%, the same as cutting the boxes myself at that threshold, because it is the same decision.

A tab freezes a threshold the caller can't move

The difference shows up when the caller can move the threshold. With boxes in hand I swept it from 0.4 to 2.0 times word height, scoring each setting against the ground-truth cells.

for k in (0.4, 0.6, 0.8, 1.0, 1.2, 1.5, 2.0):
    cells = [cut_row(r, k * med_h) for r in rows]
    print(k, score(truth, cells))

On the bordered score table, 0.6 gave 100% against 84% at 1.0. On the borderless quote table, 0.6 to 1.2 gave 100% and 1.5 dropped to 11%. The merged-header table sat at 91% across most of the range. The 1.0 was fixed in advance and 0.6 turned up afterwards on the same samples, so it is no recommended value. It only shows that a fixed number costs something on some tables, and behind a tab-only interface nobody finds out.

The same tool flipped which separator works

For the browser tool I used ImgIng (https://imging.ai/) on a desktop, the default Professional model, and copied out the text. On the three Chinese tables all 171 cells came back right, and rows mostly came back right too: 9 lines for a 9-row table on five of the six clear images and 10 on the sixth, with no tuning on my side.

Columns were looser. The score and quote tables have 7 columns, and tabs split most rows into only 2 to 6 cells. I rescored four of the tables by splitting the text two ways.

Table (same data, two languages)	Split on tab only	Split on tab or space
Score table, Chinese	5%	94%
Score table, English	43%	16%
Quote sheet, Chinese	5%	84%
Quote sheet, English	5%	24%

The better rule flips between the Chinese and English version of the score table. A script that consumes this text has to pick a rule before it sees the table. That doesn't make it worse than tesseract, since the two work differently, and I can't see why the separators fall where they do. I only looked at its copy and TXT output, so what I say is about that channel. It runs only in a desktop browser, doesn't read Korean, and numbers still need checking by eye.

What only the pixels know

Boxes don't contain everything. Ruling lines live in the pixels. Run straight on the bordered score table, tesseract found 1 of 63 cell texts; after I painted the lines white, 62 of 63. For a photo of a table taken at an angle, rotating the image was not enough on the borderless sheet: 0% to 11% after rotation, 86% to 92% after rotation plus a perspective fix. Those photos are my simulation, not real shots. The same simulated shots came out of the browser tool as one scrambled line each, and its page offers only 90-degree rotation, so I had no way to give it a hint.

That points to two stages. Pixel evidence such as lines and perspective belongs before recognition. Geometry from boxes belongs after it, where the code can see every box at once.

Slope is a number you get from all the boxes

In the middle panel the right end of each row has drifted from the left end, so the same row is cut in two and 9 rows become 18. The right panel subtracts an estimated slope from every y first, and 9 rows come back.

What I'd ask an engine to return

Boxes with confidence in input pixels, word height, and the skew estimate if it has one. Structure assembly then runs where thresholds can be tuned and failures told apart: a header glued into one string might be a recognition or a gap problem, and text can't say which.

I haven't tested a learned table-structure model, which could use cues that boxes lose. The samples are clean, English-only for tesseract, and no spreadsheet program was involved.

Why PDF image extractors return the stored picture, not the one on the page

Lank_M — Sun, 25 Oct 2026 08:01:52 +0000

Every extractor I pointed at my test PDF gave me back a rotated picture unrotated and a half-hidden picture whole. After three years of codec work I took that as the correct answer, but I wanted to be able to say why.

The file is one hand-written page with four lossless images. Each has four coloured corners and a big letter, so I can see which way it faces. A is hidden by a clip path, so the page shows only its left half. B is turned 90° counter-clockwise by the placement matrix. C is mirrored. D is a 16-colour palette image with /Decode [15 0], which swaps palette entries 0 and 15. I ran pdfimages 26.08.0, PyMuPDF 1.26.5, the decoded bitmap from pdf.js 4.10.38 in Chromium 149 (pdf.js has no extract call), and ImgIng (https://imging.ai/) in a desktop browser. One file, default settings. Sizes are pixels; pt is 1/72 inch.

Three tools stopped at the same place

On A, B and C, pdfimages, PyMuPDF and the pdf.js bitmap returned the stored pixels, the same SHA-256 on every tool: the whole 240×160 image for A, the unrotated one for B, the unmirrored one for C. D went differently. Reading its palette indexes as stored gives 566fb92e549e, yet all three tools returned the page's colours, 4b16acc5dcfa. They applied /Decode and ignored the clip and the matrix.

My reading is that it depends on where the instruction lives. /Decode sits in the image's own dictionary, beside its colour space. The clip (re W n) and the matrix (cm) sit in the page's content stream, around the operator that paints the image. The tools seem to decode the object and stop where the page starts placing it. That is a reading of four images, nothing I found documented.

One stored image can sit on a page four times

The strongest argument came from a second file: one image object painted four times, each under a different clip (a rectangle, a triangle, a circle, and a box that never touches it).

import fitz
pdf = fitz.open("clip-shapes.pdf")
pg = pdf[0]
stored = pg.get_images()
drawn = pg.get_image_info(xrefs=True)
cuts = [d for d in pg.get_drawings(extended=True) if d["type"] == "clip"]
print(len(stored), "stored,", len(drawn), "drawn,", len(cuts), "clips")

1 stored, 4 drawn, 4 clips

pdfimages -list prints four rows for that page, all object 5. The page shows 50%, 50%, 37% and 0% of the picture. An extractor that returned the visible part would have to return four images from one object, or quietly pick one. Returning the object is the only answer that doesn't depend on which placement you mean.

A 10-page Creative Commons newsletter (CC BY 3.0, via Wikimedia Commons) shows it from the other side: 36 rows in pdfimages -list, 32 distinct images, since one banner is painted on pages 2, 4 and 6. ImgIng returned 32 results.

The visible part would cost a dpi and an alpha channel

On A, the clip is 90 pt wide and the picture is drawn 180 pt wide for 240 pixels, so it is stored at 96 pixels per inch and the visible part is the left 120 columns. Cropped to 120×160, it matches a 96 dpi render of the page with an average error of 0.00 on a 0 to 255 scale. At 72, 150, 300 and 600 dpi the error is 0.98 to 2.51, from resampling. "What the page shows" depends on a dpi somebody has to choose, and extraction has none to choose.

The shape is the second cost: the circle exposes 37% of the picture, so a visible-part result would need an alpha channel. PyMuPDF reports each clip as a bounding box (scissor), and estimating from that gave 100% for the triangle (truth 50%) and 46% for the circle (truth 37%). Only rectangles came out right.

I don't know how these tools were designed, so this is an inference from the behaviour.

One image where ImgIng and the page disagree

On A, B and C, ImgIng returned the same pixels as the other three. On D it returned the stored palette, 566fb92e549e, so its colours are reversed against the page. A grey image and an RGB image carrying /Decode in a second file did match the page, which narrows the gap to a palette plus /Decode, in the 4-bit [15 0] form only; I haven't run the 8-bit [255 0]. My guess is that its palette path never reads /Decode.

One PDF per run, 0 results for a page with no images, ZIP entries named by number.

What I do with it

An extractor answers "which image objects does this file store". For the picture a reader sees, I read the placement (transform and clip in PyMuPDF, the matrix and clip operators in pdf.js) or render the page at a dpi I choose and crop.

What I can't answer is how often real files hide half a picture. A two-page public brochure has 9 placements and 20 clip entries, but I never matched clips to images.

Why a JPEG white background isn't 255: blocks, quantization tables and chroma subsampling

Lank_M — Sat, 24 Oct 2026 08:01:37 +0000

I wanted to know why a white background saved as JPEG stops being exactly 255. On one sneaker photo the drift split three ways. Quantization steps move even a flat white image, but only at low quality. At normal quality the drift lives in the blocks an edge crosses. And 4:2:0 chroma adds a coloured share. Amazon's US seller guide (viewed 2026-10-23) asks for RGB 255, 255, 255, so the last digit matters to someone.

The photo is a Wikimedia Commons shot of white sneakers on beige tile (JustinLiang522, CC BY-SA 4.0). I made the white PNG in ImgIng (https://imging.ai/) in a desktop browser: AI cutout, background set to white, exported at 1,280×1,707. I did not look into how it composites, only at what it exported. The export row lists WebP, PNG, AVIF, TIFF and GIF with no JPEG, so every JPEG below comes from Pillow 11.3.0 and numpy 2.0.2 on an Apple M4. "Background" means the 55.2% of pixels the cutout left transparent, all exactly 255 in the PNG.

Flat white only drifts at low quality

JPEG cuts the image into 8×8 blocks, turns each into 64 coefficients, divides every coefficient by an entry of a quantization table and rounds. The luma table's first row at quality 85 is 5, 3, 3, 5, 7, 12, 15, 18, with a largest entry of 36.

A flat white block has a single nonzero coefficient, the DC term, 8×(255−128) = 1016. At quality 85 that is divided by 5 and stored as 203, which by my arithmetic (not the decoder's own path) decodes to 254.875 and rounds back to 255. I swept a flat white 64×64 image over quality 1 to 100. Every setting from 46 to 100 came back all 255, while 20 of the 45 settings below 46 moved every pixel, to 254 in 14 of them and down to 248 at quality 5.

At normal quality the drift lives in edge blocks

Above that line a flat area is safe, so drift needs detail, and the simplest detail is one hard edge. In a 48×16 grey image, white left and black right, I slid the edge across the block spanning x = 24 to 31 and counted white-side pixels that were not 255. The second number counts those left of the edge block.

def strays(edge, q=85):
    a = np.full((16, 48), 255, np.uint8); a[:, edge:] = 0
    buf = io.BytesIO(); Image.fromarray(a).save(buf, "JPEG", quality=q)
    back = np.array(Image.open(buf))[:, :edge]
    return int((back != 255).sum()), int((back[:, :24] != 255).sum())

print([strays(24 + off) for off in range(8)])
# [(0, 0), (0, 0), (0, 0), (16, 0), (16, 0), (32, 0), (32, 0), (16, 0)]

An edge sitting on the block boundary leaves the white side alone, an edge inside the block cost 0 to 32 pixels at quality 85 depending on where it fell, and nothing outside the edge block ever moved. The real photo shows the same pattern at scale. At quality 85 with 4:2:0, 11.58% of the background pixels within 8 pixels of the shoe drifted, against 0.0162% beyond that.

In the zoomed pair on the right, the red specks form a ragged strip hugging the dark edge and the white further out has none; the left panel shows it following the whole outline. Photo by JustinLiang522, Wikimedia Commons, CC BY-SA 4.0, adapted.

White is a ceiling that hides most of it

Ringing swings both ways around an edge, but a decoder clamps at 255. To see how much that hides, I repainted the sneaker's background at a flat grey level and re-encoded at quality 85. At 255, 7,916 background pixels changed and none went up, by construction. At 200, 27,894 changed, 15,263 with a channel above 200 and 14,460 with one below, and a pixel can be in both groups. Grey 128 gave 28,392. White shows about 28% of the drift a mid-tone background would.

4:2:0 adds a coloured share

JPEG stores colour as two chroma planes. At 4:2:0 each chroma sample covers 2×2 pixels, so a chroma block spans 16×16 pixels. Of the 7,916 strays at 4:2:0, 6,284 are coloured, meaning R, G and B differ, like 254, 255, 253. At 4:4:4 the total falls to 3,501 and the coloured part to 1,458. The farthest stray sat 13 pixels from the subject at 4:2:0 and 6 at 4:4:4. That fits a luma block reaching at most 7 pixels and a chroma block up to 15, but I only counted, so the reach is my reading and not confirmed in the encoder.

A neutral grey square on white drifted by 250 pixels in both modes and none of them were coloured, so in that toy case chroma changed nothing.

What I could not explain

Grey-only strays rose from 1,632 to 2,043 when I switched to 4:4:4, and I have not traced why. An orange square on white drifted by 674 pixels at 4:2:0 and 575 at 4:4:4, nowhere near the photo's halving, so my toy case does not reproduce the effect.

Everything here is one photo and a few synthetic images through one Pillow build. Nothing took the sneaker background to 100%: quality 100 with 4:4:4 still left 0.052%. To check a pipeline I would count strays inside the 8-pixel band and beyond it separately: the far background should stay near 0.0162%, and the band is where a change of encoder shows up.

Budgeting browser memory for a 300-photo batch: the ZIP step added 830 MiB at the very end

Lank_M — Fri, 23 Oct 2026 08:01:53 +0000

I wanted a written memory budget for a page that re-encodes every photo in a folder before anyone on the team picks a save strategy. Most lines of it were easy. One only shows up in the last two seconds of the run, and one number I almost copied into it turned out to be the browser starting up. The numbers below come from desktop Chromium 149 on a 16 GB Mac and 300 synthetic 3024×4032 JPEGs in three nested folders. Every photo goes through createImageBitmap, a same-size OffscreenCanvas and convertToBlob as JPEG at 0.8. Memory means all browser processes added together, and MiB means 1024×1024 bytes.

The pixel line is the easy one

A decoded 3024×4032 photo is width × height × 4 bytes, 46.5 MiB. Decoding the whole folder first made that line grow with the folder (5,192 MiB at 100 photos; the 300-photo run was at 14,382 MiB 3.3 seconds in and I stopped it). A loop that releases the bitmap and zeroes the canvas before the next file keeps it at one photo's worth. That much is arithmetic. The two lines below took reading the samples.

The peak column was measuring startup

My summary table gave peaks of 668 MiB for the one-at-a-time loop, 653 MiB for writing each result as it finished, and 1,375 MiB for keeping all 300 results and zipping them at the end. Then I read the raw samples, taken about every 1.2 seconds rather than the 1 second I'd assumed. The 668 and the 653 were both the very first sample, 0.05 seconds in, before the loop had touched a photo. I haven't worked out what that startup memory is. It shows up in runs that do different work afterwards, so I don't charge it to the loop. During the loop, the version that throws results away sat between 111 and 192 MiB.

The high points at t≈0 are that startup sample, so read from the second sample on. Blue, the discard version, stays low and flat. Green, write each file now, climbs during the loop. Orange, keep everything for a ZIP, follows green almost exactly until the last two samples, then jumps. Purple is the same loop inside a Worker; its spike at about 1.2 s is a single sample I haven't traced. The test images are my own synthetic files.

Held results add about 1.43 MiB per photo

The 300 re-encoded JPEGs total 448,872,129 bytes, an average of 1.43 MiB each, and a ZIP built at the end needs every one of them alive until the end. To make that line visible I gave the loop a save step that reports what it still holds (mib formats bytes, kept is a plain array):

async function processWithLedger(fileList, sink) {
  let held = 0;
  for (const photo of fileList) {
    const frame = await createImageBitmap(photo);
    const rgbaBytes = frame.width * frame.height * 4;  // costs this whatever the file size
    const scratch = new OffscreenCanvas(frame.width, frame.height);
    scratch.getContext('2d').drawImage(frame, 0, 0);
    frame.close();
    const out = await scratch.convertToBlob({ type: 'image/jpeg', quality: 0.8 });
    scratch.width = scratch.height = 0;
    held += await sink(photo, out);                     // bytes the sink still holds
    console.log(photo.name, 'decoded', mib(rgbaBytes), 'held', mib(held));
  }
}
const keepForZip = async (photo, blob) => { kept.push(blob); return blob.size; };

Six of the test photos through keepForZip, first and last lines:

IMG_0001.jpg decoded 46.5 MiB held 1.5 MiB
IMG_0006.jpg decoded 46.5 MiB held 8.5 MiB

A second sink that writes each JPEG and returns 0 printed held 0.0 MiB on all six lines. The chart doesn't agree. In the 300-photo run that green line climbed from about 175 to 563 MiB, while the JS heap stayed near 2 MiB. The folder picker couldn't open in my test setup, so those writes went to the browser's origin private file system (OPFS) through createWritable(), the same call a real tool makes on a folder from showDirectoryPicker(). My guess is that the browser buffers the writes outside the heap. I haven't found where.

The ZIP step costs one to two archives at the end

In its last 2.4 seconds the ZIP run went 545 → 845 → 1,375 MiB, so 830 MiB on top of the loop, against a 428.1 MiB archive. The ZIP writer is my own store-only one, no compression. My guess is that the kept parts and the finished archive were alive together. The 100-photo run doesn't fit cleanly, though: its final jump was 163 MiB against a 142.2 MiB archive. At 1.2-second sampling both peaks could be higher, so I budget the ZIP step at one to two times the output size, growing with photo count rather than concurrency.

The budget I write down now

Startup, plus the photo in flight, plus, on a ZIP path, every output held through the loop and one to two archives' worth at the end. Writing as you go isn't free either: the OPFS run crept up to 563 MiB, it just never jumped. A Worker doesn't change the arithmetic. It dropped the main thread's worst timer delay from 8.5 to 2.6 ms, and apart from that one untraced 856 MiB sample about 1.2 s in, it ran at 160–229 MiB, the same range as the main-thread loop. According to MDN's compatibility data (2026-10-15), Firefox and Safari have no showDirectoryPicker, so on those browsers a page has to hand results back as downloads, one by one or as an archive.

As an outside reference I use ImgIng's batch compressor (https://imging.ai/). Watching it on 100 of these photos in Chromium 149, it saved each one into a new folder before starting the next, and in the WebKit and Firefox engine builds I had, not the release browsers, its save option offered only one-by-one downloads. Before shipping a ZIP fallback, run it on the largest folder you expect and read the samples from the final seconds, not the peak column.

In a frame-diffed GIF, ordered dither cost 15% more bytes and Floyd–Steinberg cost 91%

Lank_M — Thu, 22 Oct 2026 08:02:41 +0000

My first job was three years of codec work at an audio/video SDK company, and the rule I took from it is blunt: any stage that makes a still pixel come out differently in the next frame is a bug for inter-frame coding. Dithering a GIF can be that kind of stage. I'd also read that frame differencing halves a GIF. So I measured both claims on one real clip, and the answer depended on which dither I used.

Frame differencing saved nothing until I allowed loss

The clip is a cat flicking its tail, 320×240, 208 frames, a low-light phone video turned into a 3,728,810-byte GIF (Mateus2019 / Wikimedia Commons, CC BY-SA 4.0). I re-encoded it in Python 3.9 with Pillow 11.3 on an M4 Mac, using one shared 255-color palette and three layouts: full frames, change rectangles, and rectangles with unchanged pixels made transparent, keeping the smaller per frame. Sensor noise kills the lossless case. Only 13.7% of pixels keep their palette index from one frame to the next, and the best layout came out at 100% of full frames. Everything below uses a tolerance of 16: any pixel within 16 levels per channel of the previous frame copies it. That is lossy, and it dropped PSNR against the source, sampled on every fourth frame, from 44.53 dB to 33.00 dB. In exchange, 86.3% of pixels became identical and the diffed file fell to 25.2% of full frames at the same tolerance (about 43% of the lossless full-frame file, since tolerance also inflates the full-frame baseline). My LZW encoder is worse than the one that made the original file, so I only compare ratios within my own runs.

Floyd–Steinberg nearly doubled the diffed file

Dither is a switch that browser tools expose too. Before running my own encoder I opened the clip in ImgIng's animation workshop (https://imging.ai/) in desktop Chromium 149. With GIF output selected, its dither setting offers Floyd–Steinberg or off, off by default, next to a frame-diff versus full-frame option. How it orders dithering against the diff I can't tell from the outside. The workshop runs only in desktop browsers, and Safari can't use it to compress an existing animated GIF. In my own runs I kept the palette and tolerance fixed and changed only the dither, quantizing with Pillow's quantize(palette=...). Without dither the frame-diffed GIF was 3,138,114 bytes. Floyd–Steinberg made it 6,004,213, which is 91% bigger. An 8×8 ordered (Bayer) dither made it 3,597,688, only 15% bigger. At tolerance 8 the Floyd–Steinberg penalty was 44%.

Read the left panel first. Ordered dither keeps exactly as many identical pixels as no dither (86.3%), while Floyd–Steinberg drops to 73.8%, and the right panel's blue bars follow that loss. Sizes are in MB of 1024×1024 bytes. Chart from my runs on the cat GIF by Mateus2019 / Wikimedia Commons, CC BY-SA 4.0; the chart is shared under the same license.

Error diffusion moves pixels that did not change

Ordered dither adds a threshold that depends only on pixel position, so the same color at the same spot gets the same index every frame. Floyd–Steinberg pushes each pixel's rounding error right and down, so a pixel's index also depends on everything scanned before it, as long as there is rounding error to push. I measured that directly. In the loop below, stable holds the frames after the tolerance-16 freeze and to_index maps one frame onto the shared palette with the given dither.

for mode in ("none", "ordered", "fs"):
    idx = [to_index(f, mode) for f in stable]
    flipped = []
    for prev, cur, a, b in zip(stable, stable[1:], idx, idx[1:]):
        still = (prev == cur).all(axis=2)          # RGB identical to the previous frame
        flipped.append((a[still] != b[still]).mean())
    print(f"{mode:8s} still pixels whose index changed: {np.mean(flipped):5.1%}")

Averaged per frame, it printed 0.0% for no dither, 0.0% for ordered and 14.6% for Floyd–Steinberg. Then I nudged one pixel of frame 60 by 6 levels. Without dither or with ordered dither, one index changed. With Floyd–Steinberg, 65 changed, spread from x 34 to 54 and from that row down to y 92, never above it.

The large white shape is the part of the cat that actually moved, and it looks the same in all three panels. Compare the background: left and middle are mostly black, while the right panel is covered in white specks where nothing moved. Derived from the cat GIF by Mateus2019 / Wikimedia Commons, CC BY-SA 4.0, shared under the same license.

Ordered dither pays in image quality

At tolerance 16, PSNR was 33.00 dB without dither, 33.11 dB with Floyd–Steinberg and 27.78 dB with ordered. Its full-frame file was also the largest of the three, so the Bayer pattern costs bytes in every frame and frame diffing only hides that. I set its amplitude to 32 levels and never tuned it; a weaker pattern would likely win some PSNR back, but I haven't run it. I also can't explain why, on the unfrozen frame, the one-pixel nudge spread to only 4 pixels under Floyd–Steinberg.

Dither has to stay stable before diffing

One condition sits under all of the Floyd–Steinberg numbers. This clip turns out to use only 254 distinct colors, so my 255-color palette covers every one of them. When I mapped colors with an exact nearest-color search, Floyd–Steinberg had no error to spread and produced the same bytes as no dither. The 73.8% and +91% above come from Pillow's quantizer with this palette, which I assume picks colors approximately; I haven't read its source. So the penalty shows up when the palette can't hold the source colors or the color lookup itself is inexact, which I'd expect to be common with real footage in 256 colors, but it isn't automatic.

In my pipeline I now treat dithering as part of frame-stability design, decided before the diff stage. Noisy footage gets no dither or ordered dither, and Floyd–Steinberg stays on only for static images where nothing gets reused. Off by default, as in the workshop above, is the setting I would pick for noisy clips too. For your own encoder, run the still-pixel check above on two frozen frames; anything above 0% means some stage is not frame-stable.

The halo around a blurred video background is the dark-fringe bug from texture filtering

Lank_M — Wed, 21 Oct 2026 08:02:48 +0000

I zoomed into a blurred-background export from a browser video matting tool and found a dark ring around the speaker's head. My first suspect was the matte, and it turned out not to be the cause. At the graphics-tool company I worked at before, dark fringes around resized transparent PNG icons came in as bug reports every few months. This ring is the same bug in a different place: a blur filter is averaging pixels that belong to another layer. Both standard fixes from texture work carry over, and on one clip I measured how far each gets.

The ring is the person blurred into the background

I used ImgIng's video matting (https://imging.ai/) for the export, a Beta that runs in desktop Chrome or Edge and not on phones. I only saw its output, not its code. The clip is an 8-second, 478×850 sign language video from Wikimedia Commons (Sayvhior, CC BY-SA 4.0, signing by JudithNG12), one woman in a headscarf before a light curtain. I exported it with blur strength 18 (the default) and 40 in Chromium 149 on a desktop machine that had no GPU acceleration. In its blur-original-background mode the ring appears because what gets blurred is the original frame with the person still in it, so the dark of her clothes and skin spreads past her outline. To put numbers on it I compared brightness in rings outside her edge, on four frames, against an empty-curtain reference rebuilt from the clip itself; it covers 62.5% of the frame. Right at her edge, in the first 4 px, the background read 67.8 grey levels (0 to 255) darker than it should at strength 18, and 63.1 darker at 40. The visible part stretched about 16 to 32 px out at 18 and beyond 32 px at 40.

Filtered transparent textures get the same dark fringe

Take a sprite stored with straight alpha, where the fully transparent pixels still hold some colour, usually black. Scale it and the filter averages those invisible black pixels into the edge, leaving a dark outline that was never in the artwork. Background blur does the same thing with the layers swapped. The kernel should only see background, but it reaches across her edge and pulls her colour in. Real-time depth of field hits it too, where a sharp foreground leaks into the blurred background unless samples are weighted by depth. Texture pipelines settled on two fixes: premultiply, so excluded pixels carry zero weight, or bleed the edge colours outward into the empty area before filtering.

Both texture fixes work on video frames

I reproduced both with OpenCV on the same frames, taking the matte from a transparent export of the clip (WebM only in that tool). Here is the core, trimmed. It's a generic compositing order, not a feature of the tool.

# r is the blur strength, 18 or 40
keep = 1.0 - matte                                  # how much of each pixel is background
smear = cv2.GaussianBlur(img, (0, 0), r)            # blur everything, person included
num = cv2.GaussianBlur(img * keep[..., None], (0, 0), r)
den = cv2.GaussianBlur(keep, (0, 0), r)[..., None]
weighted = num / np.maximum(den, 1e-3)              # premultiplied-style blur
grow4 = cv2.getStructuringElement(cv2.MORPH_ELLIPSE, (9, 9))
fill_zone = cv2.dilate((matte > 0.02).astype(np.uint8), grow4)   # fill area grown 4 px
plate = cv2.GaussianBlur(cv2.inpaint(img_u8, fill_zone * 255, 9, cv2.INPAINT_TELEA), (0, 0), r)
out = img * matte[..., None] + plate * keep[..., None]     # sharp person on top

The weighted version is premultiplication written out: blur colour times weight, blur the weight, divide. Averaged over the four frames on the original matte, it left −0.1 to −1.6 grey levels across the rings at strength 18, and −1.3 to −3.3 at 40. Filling first, which is edge bleeding by inpainting, landed within ±1 at both strengths. I haven't pinned down where the weighted version's leftover comes from; at 40 it is still a few levels, which I would not ship as a regression baseline without knowing why.

Filling has to reach past the matte

Texture bleeding runs a few pixels past the visible edge, and the fill here needs that margin too. With a matte shrunk 2 px to a hard edge and the fill area taken straight from it, her outer 2 px stayed in the background, got blurred, and at strength 18 the 4 to 16 px rings came back at −14.1. Growing the fill 4 px past the matte brought them to +0.3. The plain blur-everything version sat at −15.4 on the original matte. Filling does cost an inpainting pass on every frame, which the weighted blur avoids.

Read the last group first: with the hard edge, the fill taken straight from the matte sinks almost as low as blurring everything, while the grown fill sits back at zero. Data: my own measurements on this clip, four frames.

A thin dark line is a different member of the family

My filled frames still show a very thin dark outline right on her edge. I read it as the other straight-alpha problem: edge pixels already contain the old background mixed into their colour, so the curtain or the dark wall rides along when she is pasted onto anything new. Removing it is colour decontamination, a separate step I didn't measure. So in a compositing pipeline I'd place it this way: the blur stage only ever receives background pixels, through weights or a fill, and decontaminating the edge is its own stage between matting and the final paste.

Falling back to WASM x265 cost 25 MB once and about 6x the encode time on every run

Lank_M — Tue, 20 Oct 2026 08:02:35 +0000

ImgIng's in-browser video compressor added H.265 export recently, and from the outside it splits into two paths. When the machine has a hardware HEVC encoder, the browser does the work and the job is done in seconds. When it doesn't and the source is already H.265, the page loads x265 compiled to WebAssembly and encodes inside the tab. I spent three years on codec SDKs before I moved to browser tooling, and people still ask me what a fallback like that costs as if it were one number. I measured this one on 2026-10-19 with no view of its code, and it turned out to be two bills that behave very differently: a download of about 25 MB that you pay once, and an encode that is about six times slower on every run.

I used the live build of ImgIng (https://imging.ai/) through its Chinese-language site, on a single Apple M4 machine running macOS 26.5 and Chromium 149. I don't own a machine without an HEVC encoder, so I made one by turning off hardware video encoding in Chromium. That simulates the condition. It is not a real low-end laptop. The source was a 60-second 1080p30 screen recording I generated frame by frame and converted to H.265 Main, 20,645,740 bytes, stiller and cleaner than a real recording. Preset "HD balanced", output MP4 H.265, one run per configuration.

The switch between the two paths lines up with what the browser reports. With hardware encoding on, VideoEncoder.isConfigSupported returned true for HEVC Main under all three hardwareAcceleration values. With it off, all three returned false, and the capability panel changed from native hardware to local WASM. In the normal build prefer-software also said true, but at about 6 seconds for 30 frames I wouldn't count that as a usable middle path, and the page doesn't seem to either.

The 25 MB download happens once

Nothing is fetched when the page opens. About 2.0 seconds after I pressed Start, the page requested ffmpeg-core.wasm, 25,357,446 bytes on the wire, which took about 5.1 seconds on that day's connection. An earlier HEAD request had reported 25,328,759 bytes, and I still haven't tracked down the 28 KB gap. A few small scripts came along, tens of KB in total, one of them an OPFS file-system shim. The glue script was requested 33 times and the worker script 32 times, every one after the first a cache hit with 0 bytes. My reading is that the multi-threaded build (directory core-lto-mt) starts workers that each load their own copy. After the run, two console lines showed what stayed behind:

await caches.keys();                        // ['imging-x264-high10-0.12.10-imging-2-mt-lto1']
(await navigator.storage.estimate()).usage; // 31334742

A second run on the same page made no wasm request, and neither did a third after a reload. The cache is named after x264 High 10, which matches the panel's note that the core is shared with that export, so whichever path runs first should pay the download for both. About 31 MB of site storage stays on the user's disk until it's cleared. Those download and storage figures are decimal, 1 MB = 1,000,000 bytes. The MB values in the table below are what the interface shows, where 1 MB = 1024×1024 bytes. A private window should fetch it again each time, which I didn't check.

The encode is where the time goes

Run	Time	Output	VMAF
Hardware HEVC	8.5 s	6,299,368 bytes (6.01 MB)	98.32
WASM x265, first run	55.5 s	6,005,135 bytes (5.73 MB)	97.97
WASM x265, same page again	53.8 s	5.73 MB	not scored
WASM x265, after a reload	76.9 s	5.73 MB	not scored

The first WASM row is from my earlier session. In the session that produced the next two rows, the first run took 56.5 seconds. The download accounted for about 5 of those 56.5 seconds. With nothing left to fetch, the second run still needed 53.8 seconds, roughly 6.3 times the hardware path. The cache buys back only those first few seconds. The run after a reload was about 20 seconds slower than the other two, and I don't know why yet. It's a single run, so I'm leaving it there. VMAF is libvmaf with outputs scaled back to 1080p. The WASM file came out 4.7% smaller and 0.35 points lower, which on this clip I'd call a draw.

Why only H.265 sources fall back

The panel's note for this path says x265 runs locally so the output keeps the source's codec, bit depth, resolution, frame rate and colour curves. Its job is keeping an H.265 file H.265. With hardware encoding off and an H.264 source, H.265 output shows as unavailable on this device and the tool points you to MP4 with H.264 or to WebM. With the hardware encoder, H.265 saved 19 to 30% over H.264 at the same preset on my two test clips. Spending 25 MB and six times the encode time to get that, for a file that still needs an H.264 copy for players without HEVC, is a poor trade. If it were my call, I'd draw the line in the same place. I didn't test 10-bit or HDR sources, and those are exactly the files the panel note says this path keeps intact.

If you're building a fallback like this, time the first download and the per-run encode separately, because only one of them goes away. Check caches.keys() after a run to see what stays on the user's disk. Two things are still open on my side: the 20-second slowdown after a reload, and how a real machine without an HEVC encoder behaves, as opposed to this one where I switched it off.

I exported a long PDF page at 300 DPI and got 131: the WebP 16383 cap

Lank_M — Mon, 19 Oct 2026 08:04:30 +0000

I had one PDF page that is 800×9000 pt. It's a test page I generated myself: thirty blocks of text, plus a BOTTOM-MARK line at the very end so I could tell whether anything got cut. I wanted it as a single tall image. I used ImgIng (https://imging.ai/), a browser-based PDF and image tool, in Chromium 149 on an Apple M4 Mac, and exported to WebP. At 300 DPI I got 1456×16380. At 216 I got 1456×16380. At 144, same again. All three files were 1,213,414 bytes.

No error and no warning. The result card just listed the size. So the first job was working out what resolution I actually had.

Effective DPI is width over page width

PDF measures in points, 72 to the inch. This page is 800 pt wide, which is 11.11 inches, and 1456 px divided by 11.11 in is 131. That's the effective DPI, whatever the dropdown said. The aspect ratio came out at 11.25, same as 9000/800, and the bottom mark was still there on row 16379. Nothing was cropped. The whole image had been scaled down evenly.

Where 131 comes from

At 216 DPI the page should be 2400×27000. A WebP file stores width and height in 14 bits each, so neither side can go past 16383. The output is 16380 tall, three pixels under. Shrink the page until its height fits and the width shrinks with it, down to 1456. Every DPI option above 131 hits that same wall, 144 included, which is why all three exports were byte-identical.

To check that the wall belongs to WebP and not to the tool, I exported the same page as JPG and PNG. At 144 DPI I got 1600×18000, a true 144. At 216 and 300 both formats landed on 2385×26832 and 2385×26834, about 215 effective DPI. So those formats go well past 16383 and stop somewhere else. From the sizes it looks like a total-pixel cap near 64 million, but that's my guess. I didn't find it documented.

One thing I can only report, not explain. When the same tool stitches several pages into one long image, JPG and PNG are also held under 16383. Eight A4 pages came out at 1446×16376 in both WebP and JPG, which is 175 effective DPI. I haven't seen the code, so I don't know why that mode follows the WebP limit for every format.

What the browser does if you export it yourself

If you build this in your own front end, the canvas is where you meet the limit. I asked three engines to export a 1786×20208 canvas as WebP and as JPEG, then decoded whatever came back:

async function exportedSize(w, h, type) {
  const c = document.createElement('canvas');
  c.width = w; c.height = h;
  c.getContext('2d').fillRect(0, 0, w, h);
  const blob = await new Promise(r => c.toBlob(r, type, 0.8));
  if (!blob) return 'null';
  const bmp = await createImageBitmap(blob);
  return `${blob.type} ${bmp.width}x${bmp.height}`;
}

Engine	WebP request	JPEG request
Chromium 149	image/webp 1786x16383	image/jpeg 1786x20208
Firefox 151	null	image/jpeg 1786x20208
WebKit 26.5	image/png 1786x20208	image/jpeg 1786x20208

Chromium is the quiet one. It hands back a valid WebP that is 16383 tall. An earlier run with a gradient and color bars showed the missing rows are cut off the bottom, not scaled. Firefox gives you null, which at least you can catch. WebKit switches the format to PNG and keeps the size, so blob.type is what to look at there. JPEG has its own ceiling too: Chromium returned 65500 rows when I asked for 65535.

Put the tool and the engines side by side and you get several ways to hit the cap without any error. Scaling keeps every line of content and costs resolution. Cropping keeps resolution and loses the bottom of the page. Swapping formats keeps both and changes what you ship. Back when I worked on codecs, the tickets that took me longest to close looked like this one: every call succeeded and the output was still wrong.

What I check now

Before exporting I divide 16383 by the total height in inches. That's the best DPI a WebP long image can reach: about 175 for eight A4 pages, about 70 for twenty. After exporting I divide the image width by the page width in inches and compare the two. In my own code I decode the blob and check that width, height and type match the request before saving. When they don't match, I split the pages into shorter runs instead of shipping a 23 DPI image of a 60-page document.

I compressed a signed PDF with five tools. Every signature broke or vanished

Lank_M — Sun, 18 Oct 2026 08:01:35 +0000

A lot of e-contract pipelines sign first and compress later. The signed file often carries scans or photos, so shrinking it right before archiving feels natural. I wanted to see what that order actually does, so I built a test file, ran it through five compression or rewrite tools, and checked every output with two validators. Short version: every tool rewrote the whole file, and every signature either failed or disappeared.

The test file is a one-page fictional agreement with an 1800×1200 synthetic photo, signed by pyHanko as adbe.pkcs7.detached with a self-made test root CA. It came out at 931,980 bytes. I validated with poppler's pdfsig 26.08.0 and pyHanko 0.33.0, both trusting only that test root. No real CA and no timestamps.

The signature covers two byte ranges

The signature dictionary had ByteRange [0 923749 931275 705]: 923,749 bytes starting at offset 0, then 705 bytes starting at offset 931,275. Add 931,275 and 705 and you get 931,980, the end of the file. The 7,526-byte gap in the middle is /Contents, where the signature value sits as hex. It can't hash itself, so it gets cut out. A validator concatenates the two ranges, runs SHA-256 over them, and compares the result with the signed digest.

So the signature is about bytes, not about how the page looks. Reorder the objects or recompress a single stream and the hash stops matching, even if every glyph on the page is identical. I spent years on video codecs, and my reflex on a checksum failure is to hunt for the broken frame. There is nothing to hunt here: after a full rewrite almost every byte has moved.

import hashlib, re, sys

pdf_bytes = open(sys.argv[1], 'rb').read()
m = re.search(rb'/ByteRange\s*\[\s*(\d+)\s+(\d+)\s+(\d+)\s+(\d+)', pdf_bytes)
lo, lo_len, hi, hi_len = (int(g) for g in m.groups())
signed_part = pdf_bytes[lo:lo + lo_len] + pdf_bytes[hi:hi + hi_len]
print(hi + hi_len == len(pdf_bytes), hashlib.sha256(signed_part).hexdigest()[:8])

On the original this prints True 040cd959. After a plain qpdf rewrite (930,748 bytes, ByteRange copied over unchanged) it prints False 571be5df. The regex only works while the ByteRange is stored as plain text. Once a tool packs objects into object streams, byte-level searching starts missing things.

All five tools rewrote the whole file

Tool	Output bytes	Signature dictionary	pdfsig	pyHanko
qpdf rewrite	930,748	kept, ByteRange copied	Illegal values in ByteRange array	INVALID
qpdf object streams	930,178	kept	Illegal values in ByteRange array	INVALID
Ghostscript /ebook	39,876	gone	no signatures	nothing to check
ImgIng, ebook preset	64,903	kept, ByteRange still ends at 931,980	Illegal values in ByteRange array	INVALID
iLovePDF, recommended	37,513	gone	no signatures	nothing to check
PDF24, default	50,877	kept, ByteRange copied	Illegal values in ByteRange array	INVALID

Every output went from two %%EOF markers to one, and none of them started with the original bytes. For ImgIng I used its in-browser PDF compressor at https://imging.ai/ on the ebook preset, in Chromium 149 on an Apple M4 Mac. Its output still declares a range ending at byte 931,980 inside a 64,903-byte file. Ghostscript and iLovePDF removed the signature field entirely. I think that case is worse. A reader can warn about a broken signature, but there is nothing to warn about once the signature is gone. I didn't check what Acrobat or Foxit actually display.

An appended edit still validates

The way to change a signed file without breaking the signature is an incremental update: new objects, a new xref table and a new %%EOF go after the old end of file, and the original bytes stay untouched. The signed file already had two %%EOF markers because pyHanko's signing step is itself an incremental update.

I appended three more revisions: a second signature, a text annotation written with pypdf, and a pyHanko edit to the page content stream that adds a line of text. All three still began with the original 931,980 bytes, the covered-range hash stayed 040cd959, and pdfsig said "Signature is Valid" for each one.

The content edit is the one that matters. pdfsig only added "Not total document signed". pyHanko diffed the revisions and returned ILLEGAL_MODIFICATIONS; for the second signature it returned ACCEPTABLE_MODIFICATIONS. My understanding is that pyHanko judges post-signature revisions against PDF's modification rules (DocMDP and FieldMDP), while pdfsig only checks the bytes. A valid hash tells you the signed bytes are intact. It tells you nothing about what came after them.

One result I can't fully explain. pyHanko also flagged the annotation as illegal ("unexplained xrefs"), which looks like its default policy not recognizing the way pypdf appends annotations. I haven't tried that file in Acrobat.

Compression can't take the incremental route anyway. An incremental update has to keep every original byte, so the old image streams stay where they are and the file can only grow.

What I do now

Compression happens before signing, and a signed file never goes into a compressor. When a signed PDF comes in, I check whether the last ByteRange ends at end-of-file. If it doesn't, there are revisions after the signature, and a "Valid" from a byte-hash checker isn't enough. That file goes through a validator that diffs revisions.

Counting colors stops telling screenshots from photos after one JPEG save

Lank_M — Sat, 17 Oct 2026 08:01:49 +0000

I wanted an upload pipeline to pick compression settings by content: palette PNG for screenshots, lossy JPEG or WebP for photos. The obvious classifier is a unique-color count, since a screenshot has a few hundred colors and a photo has hundreds of thousands. That held up right until I fed it a screenshot that had already been saved as JPEG once, which is how a lot of screenshots actually arrive.

The setup

Eight images, all measured on an M4 Mac with sharp 0.34.5 for encoding and NumPy for the math. Two screenshots I rendered myself at 1280×800: a fake Chinese meeting-notes page and a fake order table with colored status badges. Two photos from Wikimedia Commons, scaled to 1280 wide and kept lossless: a misty lake by Jakub Fryš and a fruit stall in Arequipa by Josep M. Gracia, both CC BY-SA 4.0. Two 413×579 portrait JPEGs, also from Commons, cropped to ID-photo proportions. Then each screenshot saved once more as JPEG quality 80. That is a small sample, and none of the numbers below are meant as accuracy figures.

Where the color count broke

Lossless, the count looks perfect: 174 and 1,402 colors for the screenshots, 119,846 and 634,115 for the photos. After one JPEG save at quality 80, the order table jumped to 21,500 colors. The blue-background portrait JPEG sits at 26,827. Same order of magnitude, so no threshold separates them.

The reason is how JPEG works. It transforms and quantizes 8×8 blocks and halves chroma resolution, so every sharp edge picks up ringing. A table full of lines and colored badges is nothing but sharp edges, and each one spawns a fringe of new in-between colors. Each new color covers only a few pixels, but there are a lot of them. The meeting notes only went from 174 to 2,360, because black text on white gives chroma little to smear.

What survived the JPEG save

So I stopped asking how many colors there are and asked how concentrated they are. A screenshot is mostly one background plus a handful of text colors, and JPEG noise does not move the big flat areas. Two numbers did the job:

def color_concentration(img_path, top_n=16):
    px = np.asarray(Image.open(img_path).convert("RGB"), dtype=np.uint8)
    packed = px.astype(np.uint32) @ np.array([65536, 256, 1], dtype=np.uint32)
    _, hist = np.unique(packed, return_counts=True)
    top_share = np.sort(hist)[-top_n:].sum() / packed.size
    repeat_right = np.mean(packed[:, 1:] == packed[:, :-1])
    return len(hist), top_share, repeat_right

The share of pixels covered by the 16 most common colors was 0.920 and 0.954 for the lossless screenshots and still 0.838 and 0.745 after JPEG. All four photos landed between 0.039 and 0.135. The fraction of pixels identical to their right neighbor told the same story: 0.740 and 0.786 for the JPEG screenshots, at most 0.260 for any photo. I also tried a Sobel strong-edge ratio. It barely moves under JPEG (0.1408 vs 0.1396 on the text page), but a busy photo and a sparse UI only differ by about 3x (0.0222 for the fruit stall, 0.0692 for the table), so I would only use it as a tiebreaker.

Why the direction of the mistake matters

Sending a photo to a 256-color palette costs real bytes: both photos came out 2.5 to 3.8 times larger than JPEG quality 80. On the lake's sky, turning dithering off produced flat steps of color, and turning it on traded the steps for grain. The fog in the same photo showed no bands at all, which I read as one hue only needing 256 steps along a single axis.

I used ImgIng (https://imging.ai/) in Chromium 149 as a reference point and just read its auto-detection label for eight images: the four originals plus both portraits at 413×579 and at full size. Both screenshots went to an 8-bit PNG preset. The lake, both small portraits and the full-size blue-background portrait were labeled photos at WebP quality 75. Two photos were labeled screenshot/UI: the fruit stall and a 2996×4200 portrait original. They stayed WebP and only got quality 84 instead of 75. No screenshot was labeled a photo.

The next part is my reasoning, not a measurement. A screenshot pushed through photo settings would get the gray speckles around text that I saw in the JPEG versions, and people notice that right away. A photo on the screenshot side only costs bytes, as long as that side never forces it into a palette, and the numbers above show how many bytes a palette can cost. So if I were tuning such a classifier, I would let uncertain images lean toward the screenshot label but give them a middle tier that stays lossy at a higher quality. From the outside, the quality-84 result looks roughly like that.

If you have a classifier like this, rerun it on screenshots that were re-saved as JPEG, and add a few detail-heavy photos to the test set before trusting the threshold.

A Web Worker fixed the freeze, not the wait: two checks for in-browser AVIF encoding

Lank_M — Fri, 16 Oct 2026 08:02:27 +0000

You wire up an "Export as AVIF" button. You click it, the spinner you added stops mid-turn, the cancel button ignores you, and about a second later a file shows up. Two fixes get proposed almost immediately. The first is to move the encode into a Worker, because then it will be faster. The second is to ship the multi-threaded build, because that one is always faster. I built a test page and timed both before agreeing to either. Neither held in the form it is usually stated.

The page needs its own encoder for a plain reason. AVIF is an image format built on the AV1 video codec. canvas.toBlob(cb, 'image/avif') is the call that should turn a canvas into an AVIF file, and in Chromium 149, Chrome 155 and Firefox 151 it handed me a PNG with no error. Only WebKit 26.5 gave back an AVIF. So you bring your own encoder, the code that turns raw pixels into a compressed file. I used @jsquash/avif 2.1.1, which is libavif v1.0.1 compiled to WebAssembly (WASM), a binary format the browser runs next to your JavaScript. My input was a lake photo from Wikimedia Commons by Jakub Fryš (CC BY-SA 4.0), scaled to 1738×1150 (about 2 MP), at the library defaults of quality 50 and speed 6. Everything ran on one Apple M4 Mac, and every millisecond below belongs to that machine.

Start with the Worker claim. The main thread is the one thread that runs your JavaScript, handles clicks and paints the page, and a Worker is a second thread you can hand a job to. To measure a freeze, I logged the longest gap between two animation frames while the encode ran. requestAnimationFrame asks the browser to call you right before the next paint, so a long gap means nothing was painted in between.

let prev = performance.now(), worstGap = 0;
const watch = () => {
  const now = performance.now();
  worstGap = Math.max(worstGap, now - prev);
  prev = now;
  requestAnimationFrame(watch);
};
requestAnimationFrame(watch);

With the page idle, the worst gap sat between 17 and 25 ms. In Chromium 149 the encode took 762 ms on the main thread, and the worst gap was also 762 ms. In a Worker the same encode took 766 ms and the worst gap was 22 ms. Chrome 155 gave 776 and 775 ms, WebKit 26.5 gave 816 and 830 ms. Each cell is a single run, so I read nothing into which of 762 and 766 is larger.

Red bars are the freeze with the encode on the main thread, green bars are the same job in a Worker. The grey encode times on the left barely differ.

A Worker is a second checkout lane opened for one overloaded cart. The cart takes as long to scan, but everyone behind it keeps moving. So when a proposal says "Worker, therefore faster", I ask which complaint it answers. A frozen page, yes. A long wait, no, and the plan needs a second idea.

That second idea is usually the multi-threaded build, which spreads one encode across several threads. At speed 6 it delivered: the 2 MP photo went from 696 / 696 / 673 ms to 327 / 324 / 323 ms in Chromium 149, and Chrome 155 and WebKit 26.5 were also 2 to 3 times faster. Then I changed speed, libavif's effort setting, where higher means quicker. At speed 8 the single-threaded build took 163 ms and the multi-threaded one 174 ms. At speed 10 it was 103 against 149, so "always" broke on the first parameter I touched. I did not look into why. I also never measured image quality at 8 and 10, so this is not advice to raise the setting.

The multi-threaded build also has a deployment condition. The page must be cross-origin isolated, a state it enters when the server sends two response headers:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

My test server sent both. What the build does without them I did not test, and I would want that gap closed before approving it.

To see how a shipped tool handles the loading side, I used ImgIng (https://imging.ai/) in Chromium 149 only, one run per image size. The request log comes from its Chinese-language site, and I watched from outside without reading its code. It fetched avif_enc_mt.wasm, the multi-threaded build, at 1,135,337 bytes over gzip. The fetch began the moment I selected AVIF in the format grid, before I pressed Convert. Its wait times run from the click to the finished state, a different stopwatch from my encode() numbers, so I am not comparing the two.

This is the English interface right after AVIF is selected. The tile carries an "On-demand WASM" badge, and the bottom note says the browser cannot encode the format natively. I never pressed the "Load encoder" button beside it.

In a design review I now write these as two line items. "Does not freeze" is answered by where the encode runs. "Is faster" is answered by which build at which speed, and gets re-measured whenever either changes. Still open: the missing-headers case, why threads stop paying off at speed 8, and any hardware other than this one M4. No phones, no Windows.