Vishal.dev
Back
◀ ▶ ASCII · LIVE@#%S?*+;:,.@#%S?*+;:,.@#%S#%S?*+;:,.@#%S?*+;:,.@#%S?%S?*+;:,.@#%S?*+;:,.@#%S?*S?*+;:,.@#%S?*+;:,.@#%S?*+?*+;:,.@#%S?*+;:,.@#%S?*+;*+;:,.@#%S?*+;:,.@#%S?*+;:+;:,.@#%S?*+;:,.@#%S?*+;:,;:,.@#%S?*+;:,.@#%S?*+;:,.:,.@#%S?*+;:,.@#%S?*+;:,.@,.@#%S?*+;:,.@#%S?*+;:,.@#.@#%S?*+;:,.@#%S?*+;:,.@#%@#%S?*+;:,.@#%S?*+;:,.@#%SEXPORT
Frontend

ASCII Studio — Browser ASCII Art Studio

A browser-native studio that converts images, GIFs, and videos into animated ASCII art in real time — with luminance mapping, charset presets, appearance controls, and exports to PNG, video, React component, ZIP, and clipboard.

Next.jsTypeScriptReactCanvas APIMediaRecorder APITailwind CSS
60fps
Live preview
5+
Charset presets
6
Export formats
30MB
Source limit

Domain Knowledge

What problem this project solves

ASCII conversion is a sampling problem: downsample the source to a coarse grid, compute per-cell luminance, and map brightness to characters. Making it interactive in the browser requires a real-time canvas pipeline, requestAnimationFrame playback for video sources, and an offscreen-canvas path that keeps the main thread responsive for 30MB+ sources.

Architecture

How the system is structured

The conversion pipeline lives in ascii-converter and ascii-export modules: resolve source dimensions, downsample to the ASCII grid on an offscreen canvas, compute BT.601 luminance, map to the charset with invert/threshold offsets, build the text frame with optional per-cell RGB, then render preview/export with appearance settings. Playback uses requestAnimationFrame; video export uses MediaRecorder.

Data Model

Schema design and data flow

Stateless client-side pipeline — no persistence. Source, charset, and appearance settings compose the current studio state, and export targets derive directly from that state.

Key Challenges

Hardest problems encountered

The hard parts were keeping video conversion smooth at 60fps while users scrub frames, honoring the 30MB upload guardrail without breaking large assets, and generating truly embeddable React component exports rather than static snapshots.

Scaling Strategy

How the system grows

Everything runs client-side, so there is no server to scale — performance is managed by the offscreen canvas, efficient luminance passes, and level-of-detail in rendering.

Security

Defense-in-depth approach

All media processing happens locally in the browser — no uploads to a server, no third-party processing, and no user data leaves the device.

Failure Handling

Resilience and recovery

Unsupported source types and oversized uploads are rejected with clear feedback; MediaRecorder availability is feature-detected with MP4/WebM fallbacks.

Observability

Monitoring and debugging

Debug overlays for the live conversion grid, plus frame-rate monitoring during video playback.

Trade-offs

Engineering decisions and alternatives

Canvas API over WebAssembly for portability. Client-side processing over a server pipeline for privacy and zero infrastructure. MediaRecorder over ffmpeg for in-browser video export.

Architecture Decisions

Key choices and what was rejected

Decision
Chosen
Rejected
Processing
Client-side Canvas pipeline
Server-side processing
Exports
MediaRecorder video + React component
PNG only
Luminance
ITU-R BT.601 coefficients
Simple averaging

Senior-Level Topics

Concepts this project explores

Image ProcessingLuminance MappingCanvas PerformanceMediaRecorder APIBrowser-Native Workflows