How to enhance resolution of image for a slide diagram

A slide diagram and a screenshot fail the same way: the blocks are the type. Sharpen the screenshot if the letters are the thing you need to read.

I had a diagram on the tool because a producer asked how to enhance resolution of image enough for a title slide. The file was a screenshot. The boxes were flat. The words were the point, and several of them were already only a handful of pixels tall.

The deck was 1920 by 1080. The handout was a different problem, 13 inches wide, and somebody had written 300 ppi in the margin of the brief. Both targets were larger than the diagram sitting inside the capture. I treated them as two jobs that happened to start from the same pixels. That distinction saved the words. The first attempt, which ignored it, did not.

TL;DR. The diagram lived in a 1440 by 900 screenshot and the useful part measured 860 by 480. A 1920-wide slide needed a bit more than twice that width. A 13-inch handout at 300 ppi needed more than four times the width. A photographic upscale smoothed the boxes and rewrote labels, including a ghost arrow and a letter that was not in the source. I redrew the boxes as shapes, retyped every word I could still read, and used a 2× pass only on a cropped icon that contained no text. Pixel count can go up. Invented type cannot ship.

The capture, measured before I touched it

The file name was flow-review-capture.png. It was 1440 by 900, 8-bit, sRGB, 412 kilobytes. Nothing about those numbers says the diagram is 1440 pixels wide. The browser chrome is in the file.

I measured the regions at 100 percent, which on this file means one screen pixel per file pixel, not a fit-to-window view. The tab strip was 74 pixels tall. The address bar and bookmark row together were another 88. A vertical scrollbar ate 16 pixels on the right. The diagram's outer border started at x 184, y 210 and ran 860 by 480. I wrote those numbers on the job sheet before I cropped. I have cropped the wrong rectangle often enough to want the ink.

Inside the border there were six boxes, two diamonds, a dashed return path, and a legend. The largest box was 210 by 92. The smallest diamond was 74 by 74. Body labels looked like a 13-pixel font. I measured the cap height of the word "queue" at 9 pixels. The counter of the letter e was an opening about 2 pixels wide. A footnote under the legend was gray, and its caps were 7 pixels. I could not read three words in that footnote at 100 percent. At 200 percent I could read two of them and I was guessing the third. Guessing is not a restoration.

The producer had a display that runs at double density. The screenshot tool had captured logical pixels, not the doubled framebuffer. I know that because a circular avatar in the page chrome was 32 pixels across, and the same avatar in the live page was specified at 32 CSS pixels. If the capture had been a device-pixel grab, that avatar would have been near 64. I assumed the opposite for the first hour. I told myself the type was 26 pixels tall and therefore safe to enlarge. It was 13. The mistake was mine, and it made the later failure look like a surprise instead of an arithmetic result.

What people mean by enhancing a diagram

On a photograph, resolution talk usually means the edge of a cheek, a brick, a wire. On this file it meant something narrower. Could the boxes stay smooth on a 1920-wide slide, and could a person in the back row read the same words the author wrote?

Those are separable. Smoothness is a drawing problem. I can rebuild a rectangle. Words are a transcription problem. A model that has seen many photographs will continue edges that were typical in photographs. A letter is an edge with a correct answer. The model does not have the font, the spelling, or the author's intent. The AI image upscaler is honest about that when you watch a label instead of a sky. I still ran it, because the producer had already run a phone app and wanted to know why my answer was slower than the app.

There is a longer note on pixel count versus a resize in how to increase the resolution of an image, and a companion on changing the number people confuse with size in how to change the resolution of an image. I am not repeating those here. This job turned on type.

The pass I had to throw away

I cropped to 860 by 480 and sent that crop through a 4× upscale. The output was 3440 by 1920. On a thumbnail it looked like a gift. The boxes were smoother. The arrowheads looked pointed. The pale blue fills had a gentle shading that the original, which was flat, never had.

Then I read it.

The word "latency" gained a dark blob on the right of the y, like a second letter that had failed to form. The word "queue" lost the tail of the q and the counter of the e closed up, so at slide size it read as "oueu" until I squinted. A 2-pixel arrow shaft became a wedge between 7 and 9 pixels wide with a darker rim on one side. The dashed return path, which had been 6-pixel dashes and 5-pixel gaps, turned into a caterpillar of uneven dots. The legend swatch, 18 by 18 pixels of flat hex, became a mottled tile.

None of that is a small defect in a diagram. A diagram is a claim. If the label is wrong, the smooth box makes the wrong claim look official. I put the 4× file in a folder called rejected and left it there so I would not "tidy it a little" later. Tidying a hallucinated letter is how a wrong word ships.

I also tried the same crop on the pixelated photo tool, because the arrow diagonals were stair-stepped and I wanted to see the stairs in isolation. The stairs softened. The letters did the same thing they had done at 4×. That tool is the right place to judge a photographic stair. It is the wrong place to finish a flowchart. Seeing the failure on a slider was still useful. The producer could watch "latency" break without my narrating it.

I keep that generated sample for the stair-step conversation. It is not the client's diagram. It is a flat scene with a frame, a sun, three bars, and a figure, enlarged so the edges break into squares. I show it when someone says the only problem is "resolution," and I need a picture of squares that is not their unreleased slide.

Labels I refused to guess

The footnote

The footnote was the trap. Two words were readable at 200 percent: "draft" and "internal." The third word was four or five characters, gray on a blue-gray box, and the stems were broken by the screenshot's resampling. I could have made a confident wrong reading. I have done that on a scan of a caption, once, on a family name, and the print went out with the wrong name. I wrote to the producer instead.

They replied with the source. It was an export from the drawing tool, PNG, 1720 by 960, text still drawn as text at export time, not as a screenshot of a browser. The footnote read "draft, internal only." The word I would have guessed was not "only." I am writing that down because the cost of asking was one email, and the cost of not asking would have been a handout that lied.

The legend and the arrow

Even with the source in hand, I checked the screenshot against it. Someone had edited the screenshot's page after an earlier export. One box label in the capture said "retry budget" and the older export said "retry count." The capture was the newer claim. I retyped from the capture where the capture was readable, and from the export where the capture was not, and I marked the one conflict in the margin of the slide for the producer to confirm. They confirmed "retry budget." A model would have averaged those two phrases into a third phrase that nobody wrote.

Resample, redraw, or stop

I still needed pixels for the slide, so I tried the honest resamples on a single word, "queue," cropped tight at 86 by 22 pixels.

Nearest neighbor to 4× kept every stem the color it was. The letters were exact and ugly, little stacks of blocks. Bicubic to 4× turned the black stems into ramps. A stem that had been 18, 18, 240 across three pixels became a slope of roughly 30, 90, 160, 210, 240. The letter went gray. Lanczos kept a bit more snap and added a light halo around the stems, about one output pixel, which on a bright projector bloomed into a glow.

None of those resamples created a better letter. They created a larger letter-shaped blur, or a larger letter-shaped stair. The stair was the truthful one. The producer did not want the stair on a title slide, and I agree with that taste, as long as we do not buy smoothness by inventing spelling.

So I redrew. I sampled the fills with an eyedropper. The dark boxes were about hex 1F4E79. The pale fills were about hex E7EEF7. The alert diamond was about hex F4C7A1. I rebuilt the rectangles and diamonds as native shapes in the slide file, at the slide's own coordinates, with 2-point strokes where the original stroke had been 2 pixels. I retyped the labels in a gothic the producer already used in the deck, at 18 points, which is large enough to read and which has nothing to do with the 9-pixel caps in the screenshot. The words match. The font does not, and I said so. Matching a font you cannot identify is another way to fake precision.

The dashed path I drew as a real dash, 8 point dash, 6 point gap, instead of painting the caterpillar from the upscale. Dash patterns are decisions. I copied the counts from the source export, not from the screenshot, because the screenshot had already aliased the gaps.

A table of the versions

I keep a small table on these jobs so a later request of "just make it bigger" has to point at a row. Widths are the diagram, not the whole screenshot.

Version	Pixel size	What happened to the word queue	Ship
Screenshot crop	860 by 480	Readable, 9-pixel caps, stair on the diagonals	Source of truth for words
Drawing-tool export	1720 by 960	Clean stems, one outdated label	Use for shapes, confirm labels
Bicubic 2×	1720 by 960	Gray stems, still the right letters	No
Photo upscale 4×	3440 by 1920	Extra blob, closed counters, ghost arrow	No
Redraw plus retype	Vector on a 1920 slide	New type, same words, flat fills	Yes, after the label check

The handout row is not in that table because it never deserved its own pixels. Once the diagram was vector on the slide, the handout was a PDF export. Asking a PNG to become 13 inches at 300 ppi would have meant 3900 pixels across. 3900 divided by 860 is about 4.5. That is the jump that ate the letters. Vector does not take that jump. It draws the stroke at the output resolution of the rip.

The only pixels I let a model touch

There was one icon, a cylinder meaning a database, 64 by 64, sitting outside the type. No letters. I cropped it with 8 pixels of margin so I would not clip the highlight, and I ran 2× only.

The 2× result was 128 by 128. The ellipse stayed an ellipse. A highlight that had been a 3-pixel dash stayed a single dash. I dropped it into the redrawn box at 64 points wide, which is the size it occupied before, so I was not using the extra pixels to make a bigger claim. I was using them so the ellipse would not stair on the projector.

I tried 4× on the same icon out of curiosity. The highlight doubled, a second streak appeared along the bottom curve, and the cylinder gained a vertical seam. That seam is a common invention on rounded graphics. It looks like shading. It was not in the 64-pixel original. I did not use the 4× icon. Extra scale is not a moral good. It is a larger bet.

If you are judging a photographic stair rather than a cylinder, the note on how to make a pixelated image clear is the one that matches hard squares. This diagram had hard squares on the arrows and still was not that job, because the squares contained spelling.

Checks before a diagram leaves the tool

I wrote these on a card after the "latency" failure. I read them off the card. Memory is how the blob ships.

• Crop chrome first, and write down the crop origin, so a second pass starts from the same rectangle.
• Read every label at 200 percent before any enlarge. If you cannot read it, stop and ask. Do not let a preview invent a reading.
• Count arrow shafts in pixels. If a shaft is 1 or 2 pixels, a photo model will fatten it and may twin it.
• Sample flat fills. If the output fill is no longer flat, the model shaded a decision that was a single color.
• Overlay the output on the original at 50 percent opacity, scaled to match. Wander the overlay with the arrow keys. A ghost stroke shows up as a dark/light pair.
• Retype from the readable original. Do not trace the upscale.
• Keep the rejected upscale in the folder. Deleting it is how you repeat it on the next slide.

The overlay is the check I skipped on the first pass. When I did it later, the ghost arrow sat 3 output pixels beside the real shaft, close enough that a glance called it anti-aliasing. It was a second shaft. Anti-aliasing does not form a second arrowhead.

Slide size and print size are different masters

The slide file is 1920 by 1080 because the projector is that grid, not because 1920 is a quality setting. Placing a redrawn vector into that grid is not an upscale. Placing the 860-pixel crop into that grid and letting the presentation app stretch it is an upscale, done by whatever resample the app uses on export, often at the moment you are no longer looking.

I exported a PDF of the handout and opened it at 100 percent of the print size. The labels were the words I typed. The strokes were the weights I set. I also exported a PNG of the slide at 1920 and looked at it on the same projector the venue uses, a 3500-lumen unit in a room with uncovered windows. The pale blue hex E7EEF7 nearly disappeared. That was contrast, not resolution. I darkened the fill to hex D3E0F0 for the projector version only, and I left the handout on the original sampled blue, because the handout is ink on paper and the paper is not a sunlit wall. Two masters. I used to deliver one PNG and call it finished. The sunlit wall taught me otherwise, on a different deck, when a yellow note became white and the speaker improvised around a missing caution.

Color, and the afternoon I blamed the wrong thing

The screenshot was sRGB. The handout PDF was converted by the printer's preset to a coated profile I did not pick. The pale boxes went a little duller, and a thin red stroke, hex C0392B, went brownish. I almost "enhanced" the PNG to fight that shift, which would have meant contrast and saturation on top of a file that was already the wrong kind of file. The shift was the profile. I soft-proofed, nudged the red stroke toward a slightly hotter RGB so it would survive the conversion, and left the pixel dimensions alone. Not every disappointment in a diagram is a resolution disappointment. I write that because I have sold an upscale as a cure for a profile problem, and the upscale added texture to flat color while the profile problem remained.

What I delivered, and what I kept back

The delivery was the slide file with native shapes, the retyped labels, the 2× cylinder, and a PDF handout. I also delivered the 1720 by 960 drawing-tool export, untouched, and a one-page note that said the footnote came from that export, the "retry budget" label came from the screenshot, and the 4× upscale was rejected because it rewrote "latency."

I did not deliver a giant PNG. I did not deliver a file whose labels were smoother than the author's. The producer asked, once, whether the giant PNG could be a backup "in case the shapes break." Shapes break less often than invented letters. I sent the rejected PNG only inside a zip named do-not-print, which is petty and which worked. They printed the PDF.

The hours on the sheet were three and a half, of which about forty minutes were the failed upscale and the overlay, and about an hour was waiting for the source file. The rest was redrawing twelve boxes and proofing. If the source had arrived first, the tool time would have been the proof, not the rescue. Next time a diagram arrives as a screenshot, the first sentence I send is a request for the drawing file. Enhancement is what you do when that request fails and the words are still readable. It is not the first move.

A second slide that almost got batched in

The same deck had a map screenshot, 600 by 400, with street names. I nearly dropped it into the same 4× queue. Street names are worse than flowchart labels. They are small, they are proper nouns, and a wrong letter is a wrong place. I left the map at its native size in a corner of the slide with a caption that said the map was a reference crop, not a wall graphic. The speaker could point. Nobody in the third row was going to read "Elm" off a rebuilt texture, and I was not going to let a model propose "Elm."

That is the whole policy I want on the card. If the mark is a letter, a numeral, a unit, or an arrow that changes a meaning when it fattens, the model does not get the crop. If the mark is a cylinder, a photograph, a texture with no correct spelling, a 2× trial is a fair test, and the slider decides. The diagram job felt like a resolution job because the brief used the word resolution. It was a transcription job that happened to be short of pixels.