Measure the space around the text

Once the original lettering is erased, we use OpenCV connected components to look for a light, closed region around the detected text. An area touching the page edge is rejected. This keeps white space between panels from being mistaken for the inside of a bubble.

An oval is usually narrower at the top and bottom. For each line, we find the horizontal span common to all pixel rows that line will occupy and let the lettering use 84% of it. If a line spans rows whose common width is 100 pixels, its text budget is 84 pixels. A middle line with 140 pixels available gets about 118 pixels. Those figures illustrate the layout rule.

Choose breaks after measuring words

We measure text with Pillow’s font metrics and compare possible breaks for a given number of lines. If two breaks fit, the renderer favours the one that leaves less uneven space across the available widths. That gives the wide middle of a bubble room for more text and helps avoid a short word stranded on the final line.

There are still cases where the bubble-aware layout steps aside. A sound effect over artwork may have no closed region to measure. If detection finds several separate text regions in the same bubble, we keep the upstream placement for those regions. Both are useful cases to include in a lettering review alongside a clean oval bubble.

If you are testing a manga translation pipeline, keep the translated sentence and font fixed and compare only the wrapping. On a narrow bubble, check the smallest line, the space around the outline, and the placement of the longest word. The full typesetting walkthrough shows the intermediate layouts using the same example.

AI was used to draft and localize this article from the project’s implementation and published examples.

I kept the full image for the picker and gave selected Face Swap presets a second rectangle: the part of the image that should reach the model. Here’s what changes when that rectangle is applied before the resize.

The 16:9 canvas says little about the face size

One of our portrait assets is 384 × 576 pixels. The upload preparation uses a 1280 × 720 canvas. With a proportional fit, the height is the limiting dimension, so the image fills 480 pixels of the canvas width. That leaves 400 pixels of padding on each side.

The first Face Swap preset takes the top 72% of that image. The retained source height is about 415 pixels. When fitted on the same canvas, that rectangle is about 667 pixels wide. Any feature fully inside the retained area, including the face, is drawn about 1.39× as wide as it was in the whole-image fit. This figure comes from the resize geometry. It measures the image sent for conditioning. Model quality would need a separate output test.

Crop first, then fit

A preset stores [x0, y0, x1, y1] as fractions of the source dimensions, so the same rectangle works when a preset is re-exported at a different resolution with the same composition. The browser converts the fractions to pixels, fits the rectangle proportionally, and centers it on an opaque canvas. The nine-argument form of drawImage() takes a source rectangle and a destination rectangle in one call.

const sx = x0 * bitmap.width;
const sy = y0 * bitmap.height;
const sw = (x1 - x0) * bitmap.width;
const sh = (y1 - y0) * bitmap.height;
const scale = Math.min(1280 / sw, 720 / sh);
const w = sw * scale;
const h = sh * scale;
ctx.fillStyle = "white";
ctx.fillRect(0, 0, 1280, 720);
ctx.drawImage(bitmap, sx, sy, sw, sh, (1280 - w) / 2, (720 - h) / 2, w, h);

Keep the cues the feature needs

A head-only crop can remove clothing that helps define a character. Keeping the neckline and shoulders gives Face Swap more context, while Try-On keeps the whole image so the garment stays visible. Uploaded Face Swap references are also fitted whole, which makes the crop you choose before upload important. Presets can use their stored frame or the full source. The appropriate frame depends on what you expect the output to preserve.

To reproduce the geometry, use the same portrait twice. Fit the whole source first, then fit its top 72% to the same canvas. Compare the width of a facial landmark in the two prepared images. For a live test, hold the webcam position and lighting fixed, then alternate the two references. Look at the face and clothing separately. If you’re picking your own image, here are the reference-photo checks I use before opening the camera.

AI assistance was used to draft and edit this article from the implementation, preset asset, and public documentation.

That gap turned into a separate engineering problem. The model had already done its job. I still needed to get the right frames to the software people use to record, stream, or join a call.

OBS gave me a useful first version

For recording or streaming, OBS can capture a window. Point it at the browser studio, crop the scene to the processed output, and select your microphone in OBS. That gives someone a way to use the result without installing a separate LiveFaceSwap desktop app. If they need the composed scene in a call, OBS Virtual Camera can expose that scene as a camera source.

I kept that route because it uses the studio that’s already running. It also gives people control over the rest of their scene. The tradeoff is that you’re capturing part of a window. Change the layout or resize the window and you may need to adjust the crop. If you want the output to show up as a named camera that another app can pick directly, you need an operating system integration.

One studio, with a second place for the frames to go

I kept the web studio inside an Electron shell. It uses the same live processing and account as the website. The extra piece is a small bridge that only exists inside the desktop app. During a live session, that bridge reads frames from the processed output and passes them to a native helper. A Windows Media Foundation camera source can then present those frames to another app as LiveFaceSwap Camera.

The split is useful for debugging. The studio decides what the video looks like. The bridge moves those pixels. The Windows camera source makes them available as a device. If the preview looks fine but OBS can’t find the camera, I can start with registration and device selection instead of changing the model or its prompts.

There’s a simple way to catch one common setup mistake. Put an obviously different effect on the processed feed, then compare the two panes in the studio with the OBS preview. If OBS matches the raw pane, check which camera source you selected before spending time on AI settings. The microphone stays a separate input, so you can check it independently.

A small bridge can still move a lot of data

The current bridge targets 1280 × 720 at 30 frames per second. At four bytes per pixel, that’s roughly 111 MB per second of raw pixel data at the target cadence, before copies or other overhead. That’s the nominal size of the local handoff, not an internet speed requirement or a measured frame rate.

That calculation shaped a choice in the implementation. The renderer allows one frame submission at a time. If a submission is still outstanding when the next tick comes around, it skips that tick. The native pipe also tells the sender when to wait for it to drain. In live video, an old frame loses value quickly. A queue that faithfully delivers every frame can make a camera feel further and further behind.

There’s also a difference between a helper process starting and the helper being ready to accept frames. The controller waits for an explicit ready message before sending video. I can test that handshake and the binary frame format with a fake child process. Those tests catch errors at the boundary between JavaScript and native code. They don’t tell me whether a particular Windows machine will list the camera in OBS.

What I can verify separately

I think about the check in three steps now:

1. Does the original webcam preview move?
2. Does the processed preview move independently, with the effect applied?
3. Does the receiving app show that processed feed, with the expected microphone selected?

Each step narrows down where to look. A black browser preview can point to permissions or a busy webcam. A moving original preview with no processed video sends me to the live session. A healthy processed preview with no camera in the receiving app sends me to the capture or device path.

The browser capture route is documented, and the native route is available as an unsigned preview for Windows 11 22H2 or later on x64. I’m treating device discovery and live output in each receiving app as separate compatibility checks. That’s one of the more useful lessons from this build: I can make the demo work without having tested the place someone actually wants to use it.

OBS documents both the window capture source and OBS Virtual Camera. For the project-specific steps, see the LiveFaceSwap OBS setup guide.

If you’ve shipped a virtual camera, what check caught the most real-world bugs for you: clean-install device discovery, repeated start/stop, or letting the video run long enough to see whether it falls behind?

Disclosure: This article was drafted by an AI agent from the project's source code and development notes. The project owner reviewed the draft and approved publication.