<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Pro Headshot Generator</title>
    <description>The latest articles on DEV Community by Pro Headshot Generator (@proheadshot).</description>
    <link>https://dev.to/proheadshot</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4238100%2Fb56376e4-f29f-4abf-a33c-3cd40105383c.png</url>
      <title>DEV Community: Pro Headshot Generator</title>
      <link>https://dev.to/proheadshot</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/proheadshot"/>
    <language>en</language>
    <item>
      <title>A burned-in watermark is a repair problem, not a crop problem</title>
      <dc:creator>Pro Headshot Generator</dc:creator>
      <pubDate>Thu, 12 Nov 2026 14:09:51 +0000</pubDate>
      <link>https://dev.to/proheadshot/a-burned-in-watermark-is-a-repair-problem-not-a-crop-problem-5ebd</link>
      <guid>https://dev.to/proheadshot/a-burned-in-watermark-is-a-repair-problem-not-a-crop-problem-5ebd</guid>
      <description>&lt;p&gt;Most advice about removing a logo from a video assumes the logo sits in a corner you do not need. The suggestion runs: crop the frame, scale it back up, and the problem disappears along with a strip of the picture. That works exactly once. The moment the overlay drifts toward the centre of the frame, or the subject's shoulder passes behind it, cropping stops being an option and the work becomes something else: you have to reconstruct the pixels that were covered.&lt;/p&gt;

&lt;p&gt;That distinction is worth taking seriously, because it decides which tools can help you at all.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the overlay actually destroys
&lt;/h2&gt;

&lt;p&gt;A watermark replaces real image data. Take the CapCut end-card logo: underneath it there was a piece of background — a wall, a curtain, a continuation of the same shirt — and that piece no longer exists in the file you exported. Nothing recovers it exactly. What a repair model can do is produce a plausible continuation that matches the surrounding texture, lighting and motion closely enough that a viewer stops noticing.&lt;/p&gt;

&lt;p&gt;Two properties of video make that harder than a still image. First, the covered region moves: a fixed logo sits over different background content on every frame, so each frame is a separate reconstruction that has to agree with its neighbours. Second, video is compressed, and compression noise around the repair site is far more visible than the repair itself. A patch that looks flawless on a single frame can shimmer on playback, which reads as damage even when the pixels are individually correct.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why an automatic detector is the wrong default
&lt;/h2&gt;

&lt;p&gt;Tools that claim to find the logo for you are optimising for a case that rarely holds. Overlays from different CapCut versions, templates, aspect ratios and export settings do not look alike, and a detector tuned on one family of end-cards silently misses others. Worse, when a detector is wrong it is confidently wrong: it repairs a patch of untouched footage and leaves the actual logo in place.&lt;/p&gt;

&lt;p&gt;Marking the region by hand avoids both failure modes, and it takes about two seconds. You drag a box over the overlay, then give that box a time range — the logo may only appear in the last four seconds, and repairing thirty seconds of clean footage around it is pure risk with no benefit. The time range is the part most tools skip, and it is the difference between a surgical fix and a smeared frame.&lt;/p&gt;

&lt;h2&gt;
  
  
  The processing location question
&lt;/h2&gt;

&lt;p&gt;There is a second decision that rarely gets discussed: where the frames go. Uploading a video to a server means the footage — and whatever else is in frame — leaves your machine, sits in a queue you cannot see, and is stored for a period you did not choose. For client work under an NDA, or footage of people who did not agree to be processed by an unknown third party, that is a real cost.&lt;/p&gt;

&lt;p&gt;Running the model in the browser inverts the trade. The first run has to download the weights, so it is slow, and it needs a reasonably modern browser with enough memory for the resolution you are working at. In exchange, the video, the audio and the inference all stay local, and the tool keeps working after the page has loaded even if the connection drops.&lt;/p&gt;

&lt;h2&gt;
  
  
  What the free tier does and does not do
&lt;/h2&gt;

&lt;p&gt;The tool handles one video at a time up to 50 MB and 30 seconds, with the export's short edge capped at 720 pixels — enough to fix a clip you are about to post, not enough to deliver a client master. It accepts MP4, M4V, MOV and WebM, and offers two restoration options: one targets compression noise around the repaired area, the other tries to recover sharpness lost to a soft source. Batch queues sit behind the paid tier.&lt;/p&gt;

&lt;h2&gt;
  
  
  The obvious caveat
&lt;/h2&gt;

&lt;p&gt;Removing a watermark from footage you did not create is not a technical question with a clever answer. The overlay exists to mark where the video came from, and stripping it from someone else's work is the same act whether the tool runs on a server or in your browser. The legitimate use is narrower and duller: your own export, your own footage, an overlay you did not ask for and cannot turn off.&lt;/p&gt;

&lt;p&gt;If you want to see how the box-and-time-range approach behaves on one of your own clips, it is at &lt;a href="https://videowatermarkremover.online/" rel="noopener noreferrer"&gt;CapCut Watermark Remover&lt;/a&gt;. It is an independent tool, unaffiliated with CapCut, and it works on footage you own or are authorised to edit.&lt;/p&gt;

</description>
      <category>video</category>
      <category>webdev</category>
      <category>productivity</category>
      <category>design</category>
    </item>
    <item>
      <title>Turning Phone Photos into Business Portraits: What We Learned Building a Browser-Based Headshot Tool</title>
      <dc:creator>Pro Headshot Generator</dc:creator>
      <pubDate>Wed, 11 Nov 2026 01:41:56 +0000</pubDate>
      <link>https://dev.to/proheadshot/turning-phone-photos-into-business-portraits-what-we-learned-building-a-browser-based-headshot-tool-4oo2</link>
      <guid>https://dev.to/proheadshot/turning-phone-photos-into-business-portraits-what-we-learned-building-a-browser-based-headshot-tool-4oo2</guid>
      <description>&lt;p&gt;A studio headshot used to mean booking a photographer, travelling to a studio and waiting days for retouching. For a developer updating a LinkedIn profile before a job search, or a five-person startup that needs a team page, that workflow is out of proportion to the need. They want one good portrait, not a photoshoot.&lt;/p&gt;

&lt;p&gt;We built &lt;a href="https://proheadshotgenerator.com/" rel="noopener noreferrer"&gt;Pro Headshot Generator&lt;/a&gt; to collapse that into a single browser session. This post is about the engineering and product decisions behind it — the parts that were harder than expected, and what we would do differently.&lt;/p&gt;

&lt;h2&gt;
  
  
  The constraint that shaped everything
&lt;/h2&gt;

&lt;p&gt;We fixed two limits early: four input photos, one output session. Not because the model could not take more, but because the user could not supply more. Most people have a handful of usable phone photos. Asking for twenty turns a two-minute task into an afternoon of scrolling through camera roll folders.&lt;/p&gt;

&lt;p&gt;Four photos is enough to pin down facial structure while staying inside what someone can find on their phone in under a minute. It also bounds the compute per request, which matters when you price by credits instead of by subscription.&lt;/p&gt;

&lt;h2&gt;
  
  
  Outfit, scene and pose are separate controls
&lt;/h2&gt;

&lt;p&gt;The first version had one "style" dropdown: business, casual, creative. It tested badly. Users did not want a style, they wanted to fix one specific thing — "the jacket is wrong" or "I want a plain background".&lt;/p&gt;

&lt;p&gt;So we split the controls into outfit, scene and pose, each selected independently. The cost is a larger option matrix and more combinations to render. The benefit is that the interaction now matches how people actually describe what they want.&lt;/p&gt;

&lt;p&gt;The lesson: when users keep asking for a small variation of a preset, the preset is the wrong abstraction.&lt;/p&gt;

&lt;h2&gt;
  
  
  Preview before committing
&lt;/h2&gt;

&lt;p&gt;Generation is neither free nor instant, so the flow renders a preview before the final output. Users can re-pick the outfit or scene and preview again without spending a full generation.&lt;/p&gt;

&lt;p&gt;This changed perceived speed more than any backend optimisation. Wall-clock time did not drop. The feedback loop did.&lt;/p&gt;

&lt;h2&gt;
  
  
  Output format is a product decision, not a detail
&lt;/h2&gt;

&lt;p&gt;We ship single images and ZIP archives. The ZIP is not a technical nicety — it is what recruiters and agencies asked for. They process portraits in batches, and downloading forty files one at a time is exactly the friction that sends someone back to a photographer.&lt;/p&gt;

&lt;p&gt;Resolution works the same way. A portrait gets used as a 200px avatar and in a printed conference programme. Rendering only for the screen looked fine in demos and failed in real use.&lt;/p&gt;

&lt;h2&gt;
  
  
  Browser-first, and deliberately unremarkable underneath
&lt;/h2&gt;

&lt;p&gt;Upload, selection, preview, crop and download all run in the browser. No install, no plugin, no desktop app.&lt;/p&gt;

&lt;p&gt;We kept the stack boring on purpose. The interesting part of a tool like this is the interaction model, not the framework. The people who benefit most are often in markets where studio photography is expensive or hard to schedule, and they are usually on mid-range hardware and unreliable connections.&lt;/p&gt;

&lt;h2&gt;
  
  
  What we would do differently
&lt;/h2&gt;

&lt;p&gt;Two things.&lt;/p&gt;

&lt;p&gt;First, we priced by credit packs from day one, with no free tier. That was right for unit economics and wrong for discovery: people want to see one output before they pay. We are still working out the right way to offer a sample.&lt;/p&gt;

&lt;p&gt;Second, we under-invested in the crop step. Cropping sounds trivial until you watch someone frame the same portrait for three different platforms. It deserves its own pass.&lt;/p&gt;

&lt;h2&gt;
  
  
  The takeaway
&lt;/h2&gt;

&lt;p&gt;The constraint that helped most was refusing to add a fifth input photo. Every feature request we declined made the core flow shorter.&lt;/p&gt;

&lt;p&gt;If you are building something in this space, Pro Headshot Generator is live at &lt;a href="https://proheadshotgenerator.com/" rel="noopener noreferrer"&gt;proheadshotgenerator.com&lt;/a&gt;. Feedback welcome.&lt;/p&gt;

</description>
      <category>ai</category>
      <category>webdev</category>
      <category>productivity</category>
      <category>design</category>
    </item>
  </channel>
</rss>
