DEV Community: Tover Wu

Why Upscaling the Wrong Video File Makes Quality Worse: A Source-First Diagnostic Workflow

Tover Wu — Fri, 07 Aug 2026 05:06:06 +0000

Disclosure: I work on PixelatedFix and have a commercial interest in video-quality diagnostics. The workflow below starts with source recovery, corrected exports, and lossless transfer because those options are preferable to processing a damaged copy.

A request to “make this video 4K” often arrives without the information that matters most: which file are we looking at?

The file might be:

the camera original;
an editor export;
a copy downloaded from a messaging app;
a platform rendition selected by a player;
or a screen recording of that rendition.

Those files can show the same scene while containing very different evidence. If you upscale the smallest or most compressed copy first, you preserve its defects inside a larger frame and add another encode. The output may be 3840×2160, but it is still derived from the wrong generation.

The better first question is:

What is the earliest, least-damaged file that still exists?

This article turns that question into a practical decision tree.

Start with a four-file incident

Imagine a client sends you final-video.mp4. It is 1280×720, motion breaks into blocks, and text edges shimmer.

After asking where it came from, you discover four related files:

Label	How it was obtained
A	Camera original from the recording device
B	Export from the editing timeline
C	Download from a messaging app
D	Screen recording of soft browser playback

Do not compare A directly with D and call everything between them “compression.” Compare adjacent steps:

A: capture -> B: export -> C: transfer -> D: playback observation

Your goal is to find the first boundary where the visible defect appears.

Decision 1: Do you have more than one generation?

If the answer is no, stop making historical claims.

You can say:

The earliest surviving file already contains the defect.

You cannot yet say:

The camera, editor, messaging app, or platform caused the defect.

Search for an earlier copy before processing:

the recording device or camera card;
the editor’s media folder;
cloud storage with version history;
the original transfer link;
another recipient who downloaded the file differently;
the platform upload before it was transcoded.

Recovering a clean source is the only option that can restore the samples that were never present in the compressed copy.

If multiple generations exist, label them by origin rather than by names such as final-v7-real.mp4.

Decision 2: Did the dimensions change?

Use FFprobe to collect a compact report:

ffprobe -v error \
  -select_streams v:0 \
  -show_entries stream=codec_name,width,height,avg_frame_rate,pix_fmt,bit_rate \
  -show_entries format=duration,size,bit_rate \
  -of json \
  input.mp4

Run the same command for every generation.

Suppose the reports show:

A  3840x2160  HEVC  46 Mb/s
B  3840x2160  H.264 21 Mb/s
C  1280x720   H.264  2 Mb/s

The major resize happened between B and C. That makes the transfer path the first place to investigate.

It does not prove that B is visually perfect. It tells you where the largest measurable change occurred and which adjacent pair deserves matched-frame inspection.

Also look for an upward change. A 720p attachment exported later as 4K has more output pixels, not more captured detail. Upscaling cannot reverse the fact that the 4K samples disappeared before the enlargement.

Decision 3: Did the codec or bitrate change without a resize?

Dimensions can remain constant while quality falls.

A platform or application may transcode 1920×1080 H.264 into another 1920×1080 H.264 file at a much lower bitrate. The resolution label remains “Full HD,” but gradients, motion, hair, water, foliage, and small text may degrade.

Treat bitrate as supporting evidence, not a universal score:

different codecs have different efficiency;
scene complexity changes the required rate;
variable-rate encoders spend data unevenly;
some containers do not expose a reliable stream bitrate.

If bitrate is missing, approximate the average from file size and duration:

bits per second ≈ file size in bytes × 8 / duration in seconds

Use the approximation only within the same lineage. It is not a fair way to rank unrelated videos.

Decision 4: Does the defect exist in matched native frames?

Players introduce variables:

display scaling;
hardware decoding;
color management;
adaptive-stream selection;
post-processing;
browser zoom;
and temporary low-quality renditions.

Extract the same timestamp from adjacent files instead:

ffmpeg -ss 00:00:07.500 -i A-camera.mov \
  -frames:v 1 -vsync 0 A-007500.png

ffmpeg -ss 00:00:07.500 -i B-export.mp4 \
  -frames:v 1 -vsync 0 B-007500.png

ffmpeg -ss 00:00:07.500 -i C-shared.mp4 \
  -frames:v 1 -vsync 0 C-007500.png

Keep the extracted frames at native dimensions. If you need equal-size comparison images, create separate scaled copies and label the scaling operation.

Test more than one scene:

fine texture with slow movement;
fast movement or a camera pan;
a dark gradient, smoke, water, hair, foliage, or small text.

A clean paused portrait can hide the failure that appears during motion.

Choose the remedy from the first bad boundary

Once you identify the first bad adjacent pair, the next action becomes much clearer.

A differs from B: fix the export

Inspect:

timeline resolution;
proxy attachment;
export dimensions;
frame-rate conversion;
codec and rate-control settings;
repeated intermediate encodes;
color-range and transfer metadata.

Re-export once from A with corrected settings. Do not enhance B while A remains available.

B is clean, but C differs: fix the transfer

Send B as a file or through a download path that preserves the original bytes. Disable media optimization when the application offers that option.

Do not ask the recipient to upscale C if you can simply deliver B again.

A, B, and C are clean, but D looks soft: fix playback

Check:

whether higher-quality platform renditions have finished processing;
which stream the player selected;
whether the decoded frame is being enlarged;
whether data-saving mode is active;
whether the browser or operating system is scaling the display.

A soft playback session does not automatically justify another master encode.

The earliest surviving file is already damaged: test bounded repair

When no cleaner source exists, restoration or upscaling becomes a fallback rather than source recovery.

Use a short representative segment first. Judge the same frames and motion before processing the full duration. Watch for invented text, plastic skin, ringing, oversharpened edges, temporal flicker, and repeated texture.

For a practical checklist covering this limited case, I maintain a source-first pixelated video diagnosis guide. The diagnostic principles are useful without using the product, and a clean source or corrected export should still take priority whenever one exists.

Avoid three common false conclusions

“The 4K file must be the best source”

Stored dimensions describe the output grid. They do not reveal whether the grid came from original samples or an enlarged 720p derivative.

“The platform damaged the upload”

Prove that the uploaded master is clean and the downloaded or decoded rendition differs. A screen recording alone cannot establish this.

“AI enhancement recovered the original”

Enhancement can generate a plausible result. It cannot prove that generated pores, letters, hair, or texture match the lost source.

Use generated detail as an output choice, not historical evidence.

Write a conclusion someone else can reproduce

A useful incident note names the first observed boundary and respects the limits of the evidence:

“The messaging download is the first available generation with reduced dimensions and motion blocking.”
“The editor export preserves dimensions but introduces a different frame cadence.”
“The uploaded master matches the local export; only the selected playback rendition is soft.”
“Every surviving file contains the defect, so its point of origin cannot be determined.”

Store the filenames, hashes, FFprobe output, commands, timestamps, matched frames, and tool versions together.

The key idea is simple:

Do not improve the file until you know why it needs improvement.

Find the earliest clean generation, fix the boundary that caused the loss, and only process a damaged derivative when recovery, re-export, and retransmission are no longer possible.

Why Video Looks Blurry in the Browser: A Frontend Debugging Checklist

Tover Wu — Thu, 06 Aug 2026 08:32:23 +0000

A video can be perfectly sharp in a local player and still look soft, blocky, or unstable inside a web page. When that happens, replacing the asset or increasing the bitrate is often premature. The browser may be displaying a lower-resolution rendition, stretching the element beyond its decoded dimensions, selecting a different source, or dropping quality because of playback conditions.

This checklist separates those causes with evidence you can collect in the browser.

1. Compare decoded dimensions with rendered dimensions

The HTML width and height of a video element are not the same as the dimensions of the decoded stream. The browser exposes the intrinsic frame size through videoWidth and videoHeight after metadata loads.

const video = document.querySelector('video');

video.addEventListener('loadedmetadata', () => {
  const rect = video.getBoundingClientRect();

  console.table({
    source: video.currentSrc,
    decodedWidth: video.videoWidth,
    decodedHeight: video.videoHeight,
    renderedWidth: Math.round(rect.width),
    renderedHeight: Math.round(rect.height),
    devicePixelRatio: window.devicePixelRatio,
  });
});

If a 640×360 stream is rendered at 1280×720 CSS pixels, the page is asking the browser to enlarge every decoded pixel. On a high-density display, the physical display requirement can be larger still. That softness is a scaling problem, not proof that the source file was damaged.

Do not “fix” it by setting width: 100% without checking the container. Responsive layouts can silently make a low-resolution preview fill a large desktop card.

2. Inspect the source the browser actually selected

A <video> element can contain several <source> elements, a poster, a Media Source Extension stream, or a URL changed by application state. The file you expect is not necessarily the file being decoded.

Start with:

const video = document.querySelector('video');
console.log(video.currentSrc);
console.log(video.networkState, video.readyState);

Then open the Network panel, filter by media, and reload. Check the final request URL, redirects, response size, content type, cache status, and whether range requests return 206 Partial Content. A thumbnail MP4 or preview rendition can have the same filename stem as the master while containing far fewer pixels.

For adaptive streaming, inspect the manifest and the active rendition rather than assuming the player chose the highest one. Bandwidth estimates, viewport size, data-saver settings, startup strategy, and buffer health can all influence selection.

3. Rule out CSS distortion

Aspect-ratio mistakes can look like blur because the browser resamples the image unevenly. Compare the decoded ratio with the rendered ratio:

const video = document.querySelector('video');
const rect = video.getBoundingClientRect();

const decodedRatio = video.videoWidth / video.videoHeight;
const renderedRatio = rect.width / rect.height;

console.log({ decodedRatio, renderedRatio });

Use object-fit intentionally:

.video-frame {
  aspect-ratio: 16 / 9;
  overflow: hidden;
  background: #000;
}

.video-frame > video {
  width: 100%;
  height: 100%;
  object-fit: contain;
}

contain preserves the full frame and may add empty space. cover fills the box but crops. Neither creates detail. Avoid assigning width and height values that force a ratio unrelated to the stream.

Also inspect transforms. A parent with transform: scale(...) can produce an extra resampling step, especially during animation. Test the element at an integer size with transforms disabled before blaming encoding.

4. Separate a soft poster from soft playback

The poster image is a separate asset. A low-resolution poster stretched across a large player may look poor until the first decoded video frame appears. Conversely, a sharp poster can hide a low-resolution stream until playback begins.

Record the state at three moments:

poster before playback;
first decoded frame;
a difficult moving section after the buffer stabilizes.

Do not compare a designed poster with a random compressed motion frame. They answer different questions.

5. Observe decoded frames, not only playback time

requestVideoFrameCallback provides information when a new frame is presented. It helps distinguish a stalled or repeatedly presented frame from smooth decoding.

const video = document.querySelector('video');
let previousPresentedFrames = 0;

function inspectFrame(now, metadata) {
  const droppedSinceLastCheck =
    metadata.presentedFrames - previousPresentedFrames > 1;

  console.log({
    mediaTime: metadata.mediaTime,
    presentedFrames: metadata.presentedFrames,
    expectedDisplayTime: metadata.expectedDisplayTime,
    possibleGap: droppedSinceLastCheck,
  });

  previousPresentedFrames = metadata.presentedFrames;
  video.requestVideoFrameCallback(inspectFrame);
}

video.requestVideoFrameCallback(inspectFrame);

This is not a complete dropped-frame detector, but it gives you presentation evidence tied to actual frames. Pair it with browser media diagnostics and performance profiling. A high-resolution stream that misses presentation deadlines can look worse in motion than a stable lower-resolution stream.

6. Test at matched timestamps and sizes

Visual comparisons become misleading when one version is paused on a clean frame and another is captured during motion. Choose timestamps containing fine texture, faces, text, gradients, and fast movement. Display every candidate at the same CSS dimensions and zoom level.

Check both still frames and motion. Still frames reveal blocks, ringing, banding, and lost texture. Motion reveals flicker, crawling edges, unstable faces, and texture boiling. A single attractive screenshot cannot prove temporal quality.

When testing enhancement, include an ordinary high-quality resize as a baseline. The enhanced result should remain better across several scene types and during playback, not only look sharper on one selected frame.

7. Verify the file before changing the player

If possible, download the exact media response and inspect it outside the browser. Compare it with the expected export using a tool such as FFprobe:

ffprobe -v error \
  -show_entries stream=index,codec_name,width,height,r_frame_rate,avg_frame_rate,pix_fmt,color_space,color_transfer \
  -show_entries format=duration,size,bit_rate \
  -of json browser-response.mp4

If the response itself has fewer pixels or a different codec than expected, the problem is upstream of rendering. If the response is correct but the page is soft, focus on rendition selection, CSS sizing, transforms, playback state, or device constraints.

8. Use a source-first decision tree

A useful order of operations is:

confirm currentSrc;
record decoded dimensions;
record rendered dimensions and device pixel ratio;
inspect CSS ratio, object-fit, and transforms;
inspect the exact network response;
compare matched moving evidence;
inspect the downloaded response outside the browser;
recover a cleaner source or re-export only when the evidence points upstream.

This avoids enhancing a low-quality preview when a clean original exists, re-encoding a correct file to solve a CSS problem, or increasing bandwidth when the player is choosing the wrong rendition.

For a broader artifact and source-lineage workflow, the PixelatedFix video-quality diagnostic guide covers source recovery, export checks, transfer copies, and stop conditions before enhancement.

Disclosure

I work on PixelatedFix, a browser-based video restoration and upscaling product. The linked resource is our own. This article deliberately puts source verification, rendering checks, and correct delivery before enhancement; it does not claim that software can recover detail that was never captured.

Reusable bug-report template

When reporting blurry browser video, include:

page URL and build version;
browser, operating system, and device;
currentSrc;
decoded and rendered dimensions;
device pixel ratio;
exact timestamp and playback state;
screenshot plus a short moving capture;
response URL, status, size, and content type;
expected source metadata;
whether transforms or adaptive streaming are active.

That report gives engineering teams enough evidence to reproduce the failure instead of debating subjective screenshots.

A Codec-First Workflow for Debugging Pixelated Video

Tover Wu — Wed, 29 Jul 2026 13:48:29 +0000

“The video looks pixelated” is not a diagnosis. It is a symptom that can be introduced at four different stages:

the camera or screen recorder captured too little detail;
an editor exported an undersized or over-compressed file;
a messaging or video platform created a lower-quality rendition; or
the player selected a low-quality stream while the master remained intact.

Those cases need different fixes. Upscaling a clean master because a browser showed a temporary 360p rendition creates more work and another lossy generation. Raising the export resolution on an already damaged source only produces larger blocks.

This tutorial builds a repeatable, codec-first workflow for locating the first bad generation before changing anything.

1. Preserve every generation

Start with copies, not edits. Keep these files when they exist:

01-camera-or-screen-recording.mp4
02-editor-export.mp4
03-uploaded-or-shared-download.mp4
04-player-capture-for-reference-only.mp4

Do not overwrite the earliest file. A downloaded social-media copy may have a smaller frame, lower bitrate, different frame rate, and a second or third round of compression. Treat it as evidence, not as the new master.

If you have only one file, record where it came from. “Saved from Messages” is useful provenance. “video-final-final2.mp4” is not.

2. Probe the files before watching them

Use ffprobe to collect the stream and container facts that a file browser usually hides:

ffprobe -v error \
  -select_streams v:0 \
  -show_entries stream=codec_name,profile,width,height,pix_fmt,avg_frame_rate,r_frame_rate,bit_rate \
  -show_entries format=duration,size,bit_rate,format_name \
  -of json \
  01-camera-or-screen-recording.mp4

Run the same command for every generation. Save each JSON result next to its video.

The useful questions are comparative:

Signal	What a change can indicate
Width × height fell	A smaller rendition or export was created
Frame rate changed	Frames may have been dropped or duplicated
Overall bitrate collapsed	Stronger compression probably entered here
Codec changed	The file was transcoded, even if the dimensions match
Duration changed	Trimming, variable-frame-rate handling, or a bad remux may have occurred
Pixel format changed	Chroma or bit-depth information may have been reduced

Bitrate is not a universal quality score. A static slide and handheld night footage do not require the same number of bits. It is still a strong clue when two generations contain the same scene and one has a dramatic bitrate drop.

3. Normalize the comparison

Comparing two players side by side is surprisingly unreliable. They may use different scaling, color management, hardware decoding, or playback quality.

Extract frames at the same timestamp instead:

mkdir -p frames

ffmpeg -ss 00:00:07.500 \
  -i 01-camera-or-screen-recording.mp4 \
  -frames:v 1 -vsync 0 frames/source-007500.png

ffmpeg -ss 00:00:07.500 \
  -i 02-editor-export.mp4 \
  -frames:v 1 -vsync 0 frames/export-007500.png

Choose at least three scene types:

a still or slow section with fine texture;
a fast-motion section;
a dark or noisy section.

Compression failures often hide in a paused bright frame and become obvious during motion. A single attractive thumbnail is weak evidence.

When the dimensions differ, scale both extracted frames to the same display size for visual inspection, but keep the originals too. Scaling is part of the experiment and should not be confused with recovered detail.

4. Locate the first bad generation

Use the earliest pair where the symptom changes.

The camera file is already blocky

The loss occurred at capture or before you received the file. Look for low recording bitrate, digital zoom, poor light, sensor noise, an undersized screen recording, or a file that was already downloaded from another platform.

A clean re-export cannot restore discarded camera detail. Restoration or enhancement may reduce visible block boundaries and create a more usable enlargement, but it cannot reconstruct the exact texture that was never recorded.

The camera file is clean but the editor export is blocky

The export path is the best place to fix the problem. Check:

whether the timeline resolution matches the intended output;
whether the export accidentally used a low-bitrate preset;
whether frame-rate conversion introduced duplicates or cadence problems;
whether a proxy or preview file was exported instead of the original media; and
whether the file was encoded twice.

Re-export once from the clean source. Avoid passing the damaged export through another encoder.

The local export is clean but the uploaded version is blocky

Do not repair the clean local file. Wait for the platform’s higher-quality renditions, select the intended playback quality, and compare the exact same moment again.

If a downloaded platform copy is smaller or has a much lower bitrate than the local export, that difference is expected evidence of a delivery transcode—not proof that the master needs upscaling.

Only the editor preview is blocky

Many editors lower preview quality to keep playback responsive. Render a short test segment and inspect the saved file outside the editor before changing the project or source.

5. Use objective metrics carefully

If two files are frame-aligned and represent the same image sequence, SSIM can help detect a change:

ffmpeg \
  -i 01-camera-or-screen-recording.mp4 \
  -i 02-editor-export.mp4 \
  -lavfi "[0:v]setpts=PTS-STARTPTS[ref]; \
           [1:v]setpts=PTS-STARTPTS[dist]; \
           [ref][dist]ssim=stats_file=ssim.log" \
  -f null -

This only makes sense when the inputs are aligned. A crop, a one-frame offset, a color-range difference, or a frame-rate conversion can dominate the score.

Also, a higher SSIM value does not guarantee that one version looks better. Sharpening may create halos; denoising may erase skin texture; AI enhancement may generate plausible but incorrect detail. Use metrics to support a controlled visual comparison, not to replace it.

6. Test the smallest useful segment

Once you know where the damage began, make a short, lossless-trimmed test when the container and keyframes permit it:

ffmpeg -ss 00:00:05 -i damaged-source.mp4 \
  -t 00:00:08 -c copy diagnostic-sample.mp4

If stream copying starts at the wrong visual point because of keyframe placement, create a short controlled transcode and document the settings instead:

ffmpeg -ss 00:00:05 -i damaged-source.mp4 \
  -t 00:00:08 \
  -c:v libx264 -crf 16 -preset slow \
  -c:a aac -b:a 192k \
  diagnostic-sample.mp4

Run any restoration, denoise, or upscale experiment on that segment first. Compare moving footage at the final display size. Look specifically for:

blocks that became smoothed but not truly detailed;
ringing around high-contrast edges;
unstable texture between frames;
waxy faces or foliage;
altered text, logos, or UI elements; and
a file-size increase without a visible benefit.

Only process the full video after the short test survives those checks.

A compact decision table

Earliest bad version	Best first action
Camera/original	Preserve it; test realistic cleanup on a short segment
Editor export	Re-export once from the clean source with suitable settings
Shared/downloaded copy	Transfer the original instead of repairing the copy
Platform rendition	Wait for processing and verify playback quality
Editor preview only	Judge a saved test export outside the editor

The main idea is simple: fix the stage that introduced the loss. Resolution alone is not quality, and another encode is not automatically a repair.

Disclosure and further example

I work on PixelatedFix, so I have a commercial interest in this problem. I wrote this workflow to put source and export diagnosis before product use. If the earliest remaining file is genuinely compressed or low-resolution, the PixelatedFix pixelated-video guide shows the same “find the first bad generation” decision with visual examples and states the limits of enhancement. If a clean original still exists, use that instead.

The best result is often not a smarter upscaler. It is finding the clean file one generation earlier.

I built an open-source voice input layer that works across desktop apps

Tover Wu — Tue, 14 Jul 2026 12:49:26 +0000

I’m Tover, the solo developer behind OpenTypeless.

I started building it because I kept running into the same mismatch: voice tools were becoming smarter, but using them still meant leaving the app I was working in, opening another window, copying the result, and pasting it back.

I wanted voice input to feel like an input layer instead:

Press a global shortcut
Speak naturally
Release the shortcut
Get polished text directly in the app that already has focus

The project is now open source under the MIT license: github.com/tover0314-w/opentypeless

What OpenTypeless does

OpenTypeless runs on macOS, Windows, and Linux. It supports four related workflows:

Dictation: turn rough speech into clear text and insert it at the cursor
Selected-text editing: highlight text in any app, then rewrite, shorten, expand, or change its tone by voice
Translation: translate selected text into a switchable target language
Ask Anything: ask a one-shot voice question without opening a separate chat window

The latest release, v1.1.49, also adds active-app-aware writing.

The same spoken thought should not be formatted the same way everywhere. An email may need a greeting and complete paragraphs. A chat reply should be shorter. A document can be more structured. A technical tool should preserve code, identifiers, and concise wording.

OpenTypeless detects the active application locally and maps it to an internal category and writing style. The current website ships with 71 app profiles. Raw window titles and document contents are not sent as app context.

Other parts I have added over time include:

multiple shortcuts for different workflows
99-language support
multiple speech-to-text and OpenAI-compatible LLM providers
BYOK configuration
a local custom dictionary
correction rules
dictionary import and export
voice intent routing for English, Simplified Chinese, and Traditional Chinese

The AI API was not the hardest part

The difficult work has been the desktop “last mile.”

A voice input tool has to coordinate several fragile things at once:

global hotkeys
microphone permissions
accessibility permissions
app focus
selected-text capture
reliable text insertion
clipboard backup and restoration
timing differences across operating systems
failure recovery when one step is slow

A result can be linguistically perfect and still feel broken if it appears in the wrong window, replaces the wrong selection, or leaves the clipboard changed.

That has shaped the way I think about the product. Model quality matters, but trust is built through hundreds of small desktop behaviors that users should never have to notice.

Privacy boundaries

OpenTypeless is BYOK and supports multiple providers, so users can choose how speech recognition and text processing are handled.

The local app stores app mappings, dictionary entries, and correction rules. For app-aware writing, the configured LLM receives an internal app category and approved style metadata — not raw window titles or the contents of the document you are editing.

I want these boundaries to stay understandable. “AI-powered” should not become an excuse for silently collecting more context.

Honest limitations

This is still an indie project.

Windows builds may trigger SmartScreen because I do not yet have a code-signing certificate. Desktop permissions and text insertion can also behave differently across apps and operating systems, so I am still improving reliability and setup guidance.

I would rather state those limitations clearly than hide them behind polished launch language.

Why I open-sourced it

Voice input sits unusually close to a person’s operating system, microphone, clipboard, and writing. I think users should be able to inspect what the tool does, choose their own providers, report edge cases, and change the behavior when the defaults do not fit.

Open source also makes the project better. Many of the most useful fixes come from people trying it in apps and languages I do not use every day.

If this problem sounds familiar, I would genuinely value blunt feedback — especially about latency, insertion reliability, the privacy model, and whether app-aware polishing feels useful rather than over-engineered.

Try it: opentypeless.com
Source code: github.com/tover0314-w/opentypeless

If you test it, please tell me which operating system and app you used. Those details are far more useful to me than a generic “looks good.”

Day 0: I want to kill the pain of making slides — an indie dev’s starting point with Nano Banana Pro

Tover Wu — Mon, 22 Dec 2025 08:16:34 +0000

Today is Day 0 (Dec 22, 2025). I’m starting a 10-day public build log to document one thing:
How I’m using Nano Banana Pro to turn “making PPTs” from a slow, messy craft into a repeatable, productized workflow.
I’m not a designer. I’m not a consultant who lives in decks. I’m an indie developer who can ship code and build products — but every time I need slides, I fall into the same black hole:layout, visuals, and style consistency.

The real pain isn’t writing content — it’s making it look like a deck
If you’ve ever built a product pitch, a demo deck, or a talk, you probably know this pattern:
The outline takes 30 minutes
Then you lose 3 hours to font sizes, spacing, colors, and image hunting
And somehow it still looks “stitched together,” not cohesive Content is thinking. Visual consistency is operations.

Slides need rules — a system — not just effort:
the same constraints, the same visual language, and the same layout logic across pages.

What I’m building: DrawPPT — from outline to a deliverable deck in minutes
I’m building DrawPPT with one goal:Make it possible for non-designers to consistently produce decks that look professional, structured, and visually unified — and exportable as PPTX.

Not “a deck that exists.”
A deck that feels like it was made by one system, not assembled at 2am.
Why I’m betting on Nano Banana Pro: slides don’t just need images — they need layout + readable text

Here’s the key insight:
In slides, images aren’t decoration. They often carry the structure.
Title pages / section dividers that set the tone
Infographics: process, comparison, timeline, funnel
Chart styling: making data pages feel “on brand”
Icons / illustrations: a consistent visual language
And all of these have a hard requirement:
Text inside visuals must be readable, and composition must be intentional.

That’s why I’m betting on Nano Banana Pro — because it’s optimized for producing usable assets, not just pretty images. For PPT use cases, “text clarity + layout awareness” is everything.
What you’ll see in the next 10 days: from “looks good” to “fits into PPTX”