DEV Community: Ray Lin

Upscaled 2K and re-generated 2K are not the same file

Ray Lin — Mon, 24 Aug 2026 03:59:03 +0000

Two video APIs both advertise a 2K output. You send the same prompt to each, you get back two files with identical dimensions, and your billing line item looks roughly the same. They are not the same product, and the difference is visible in one place: small text.

The two pipelines

Path A — post-hoc super-resolution. The model generates at its native resolution. A second network then scales the frames. ESRGAN, a diffusion SR pass, a temporal-consistency variant, it doesn't matter which. What matters is that the upscaler sees pixels and only pixels. It never saw your prompt. It has no idea the scene was supposed to contain a shop sign, so it does the only thing an interpolator can do: it makes edges confident. A blurry six-pixel-tall word becomes a crisp six-pixel-tall word that spells something else.

Path B — conditioned re-generation. The low-resolution result goes back into the same model along with the original conditioning — prompt, reference images, whatever produced it the first time — and the model generates again at the higher resolution. Nothing is interpolated. The second pass knows the sign reads OPEN because the conditioning still says the sign reads OPEN.

Both produce a file with the same pixel dimensions. Only one of them can recover information that was never in the low-resolution frames.

How to tell which one you actually bought

You don't need the vendor to tell you. Two tests, both cheap.

Test 1: put legible text in the scene. Generate at the low resolution, then at the high one. Look at the same word in both.

If it's an upscaler, the high-res glyphs are a sharpened version of the same wrong shapes. The error is preserved and then rendered crisply. This is the tell — interpolation cannot invent a letter that wasn't there, so it commits to the smudge it was given.
If it's a re-generation, the text is simply different. Often correct, sometimes wrong in a new way, but not a cleaned-up copy of the previous mistake.

Test 2: diff the motion. An upscaler operates frame by frame, or over a short temporal window. Frame 40 of the high-res clip corresponds exactly to frame 40 of the low-res one. A re-generation is a fresh sample: same intent, same composition, but the micro-motion drifts — a hand lands a few milliseconds off, the hair moves differently.

So: if your high-resolution render has frame-for-frame identical motion to your preview, you bought an upscaler. That's not a criticism, it's just a different product, and it should be priced like one.

The part nobody puts in the docs

Re-generation is not strictly better, and treating it as a free upgrade will break a pipeline.

The trade-off is exact frame correspondence. If you are building anything that previews at low resolution and then commits at high resolution — an editor with a scrubbing timeline, a batch job that picks a thumbnail frame index, an approval workflow where a human signs off on the cheap render — an upscaler is the thing you want. Your frame 40 stays frame 40. With re-generation, the clip your reviewer approved is not the clip you ship. Same shot, different take.

I've watched a team lose two days to this. They rendered previews, had a client pick an in-point by frame number, then rendered final at high resolution and cut on that number. The final motion had drifted maybe 80 ms. The edit landed mid-blink on every take.

The rule I'd write down: preview-then-commit workflows want deterministic upscaling; one-shot delivery wants re-generation. Decide which one you are before you pick the model, not after.

Cost follows the pipeline, and per-second pricing hides it

Most of these APIs bill per output second, with a different rate per resolution. That framing quietly conceals which pipeline you're on, because an upscale pass and a full second forward pass have wildly different compute costs but can be sold at similar-looking per-second rates.

Worth doing the arithmetic yourself before committing to a length. On the model I've been testing most, the high-resolution path runs roughly 60% above the base rate per output second, which is consistent with a real second pass rather than a bolt-on upscaler — someone has written up what a 2K clip actually costs once you multiply that out across a realistic set of takes, including the failed ones. The failure rate matters more than the rate card, and almost nobody models it.

A concrete example of the difference

MiniMax H3 is the clearest implementation of Path B I've found, mostly because it's documented as such rather than left ambiguous: the 768P result is fed back through the model along with the original context and generated again at 2K. The site I pulled the pricing from also puts the same frame down both paths side by side, which is the comparison every vendor should publish and almost none do.

There's an architectural consequence worth noting for anyone planning to self-host: if the high-resolution stage is a separate hosted component, downloading the base weights gets you the low-resolution path and nothing else. Your local output will be correct and will not match the hosted result, and you'll spend a while assuming you configured something wrong.

What to ask a vendor

Four questions. Any vendor running a real re-generation path can answer all four in one sentence; any vendor running an upscaler will get vague on the second one.

Is the high-resolution output conditioned on the original prompt, or only on the low-resolution frames?
Is frame n of the high-resolution render the same moment as frame n of the low-resolution one?
Is the high-resolution stage the same model or a separate one?
If I self-host, do I get both stages?

The answers determine whether "2K" in your invoice means resolution or means detail. They're not the same thing, and only one of them survives contact with a shop sign.

Upscaled 2K and re-generated 2K are not the same file

Ray Lin — Fri, 21 Aug 2026 17:14:28 +0000

The two pipelines

Both produce a file with the same pixel dimensions. Only one of them can recover information that was never in the low-resolution frames.

How to tell which one you actually bought

You don't need the vendor to tell you. Two tests, both cheap.

Test 1: put legible text in the scene. Generate at the low resolution, then at the high one. Look at the same word in both.

If it's an upscaler, the high-res glyphs are a sharpened version of the same wrong shapes. The error is preserved and then rendered crisply. This is the tell — interpolation cannot invent a letter that wasn't there, so it commits to the smudge it was given.
If it's a re-generation, the text is simply different. Often correct, sometimes wrong in a new way, but not a cleaned-up copy of the previous mistake.

The part nobody puts in the docs

Re-generation is not strictly better, and treating it as a free upgrade will break a pipeline.

The rule I'd write down: preview-then-commit workflows want deterministic upscaling; one-shot delivery wants re-generation. Decide which one you are before you pick the model, not after.

Cost follows the pipeline, and per-second pricing hides it

A concrete example of the difference

What to ask a vendor

Four questions. Any vendor running a real re-generation path can answer all four in one sentence; any vendor running an upscaler will get vague on the second one.

Is the high-resolution output conditioned on the original prompt, or only on the low-resolution frames?
Is frame n of the high-resolution render the same moment as frame n of the low-resolution one?
Is the high-resolution stage the same model or a separate one?
If I self-host, do I get both stages?

The answers determine whether "2K" in your invoice means resolution or means detail. They're not the same thing, and only one of them survives contact with a shop sign.

The duration your video API accepts is not the duration it renders

Ray Lin — Fri, 21 Aug 2026 15:38:33 +0000

A sequence I cut to a music bed was three frames out at the first transition,
nine at the second, and by the sixth segment nothing lined up with anything. I
had asked every generation for ten seconds. Every generation had returned a
file that was not ten seconds.

Nothing in the API said so. The request took duration: 10, returned 200,
and produced an MP4 whose container duration was 8.708. No warning field, no
note in the response body, and — the part that actually cost me the afternoon —
no mention of it on the docs page I had read three times.

This is a general property of latent video models rather than a bug in one
provider, and once you know the shape of it you can handle it in about twenty
lines. Here is the shape.

Seconds are the wrong unit

A video diffusion model does not work on frames. It works on a compressed
latent tensor, and the compression is temporal as well as spatial: a causal 3D
autoencoder folds a run of input frames into a single latent frame.

Because the encoder is causal, the first frame is kept whole and everything
after it is compressed in groups. With a temporal stride of s, a clip of F
frames becomes

latent_frames = (F - 1) / s + 1

which only divides evenly when F ≡ 1 (mod s). Frame counts that miss that
condition get padded or truncated, so implementations pick the nearest legal
count and render that instead.

Stack a second constraint on top — many of these models generate in fixed
blocks of latent frames rather than one at a time — and the set of renderable
lengths collapses into a short arithmetic progression:

F = head + block · n          n ∈ ℕ

Every legal duration is one of those F values divided by the frame rate.
Nothing between them is reachable. duration: 10 is not a request. It is a
hint that gets snapped to a grid you were never shown.

What the snapping does to users

Three separate problems, and only the first is obvious.

The output is not the length you promised. Your UI said 10s, the file is
8.708s, so your UI lied. Not by much, and not in a way anyone notices on one
clip.

The error compounds. Nobody makes one clip. They make six and cut them
together. Six segments each 1.3 seconds short is eight seconds of drift, which
is the difference between "cuts on the beat" and "re-render the sequence."

Your cost estimate is wrong in the direction that generates tickets. These
APIs bill per second of output. Estimate from the requested duration, let the
model render a longer legal block, and you have quoted one number and charged
another. Users find that one on their own.

Quantise on the way in, not on the way out

The fix is to stop treating duration as a free variable at the edge of your
system. Resolve it to a legal value before anything is displayed, priced or
persisted.

type Grid = { fps: number; block: number; head: number; min: number; max: number };

/** Legal frame counts are head + block·n, clamped to the provider's range. */
export function legalFrames(g: Grid): number[] {
  const out: number[] = [];
  for (let n = 0; ; n++) {
    const f = g.head + g.block * n;
    if (f > g.max) break;
    if (f >= g.min) out.push(f);
  }
  return out;
}

export function quantise(seconds: number, g: Grid) {
  const target = Math.round(seconds * g.fps);
  const frames = legalFrames(g).reduce((best, f) =>
    Math.abs(f - target) < Math.abs(best - target) ? f : best,
  );
  return { requested: seconds, frames, seconds: frames / g.fps };
}

Then three rules for the resolved value:

Show it instead of the requested one. The number in the duration control
should change to the number you are going to get, at the moment the user picks
it. A slider that snaps is honest. A slider that accepts anything and rounds
in private is not.

Price it. frames / fps × rate, from the resolved frames. Never from the
requested seconds.

Store it on the job. When somebody asks why their six clips do not add up,
you want the answer in a column, not in a reconstruction.

The test that would have caught this on day one

The bug was reachable from an integration test I had simply not thought to
write:

it("returns the duration it promised", async () => {
  for (const requested of [4, 5, 6, 7, 8, 9, 10]) {
    const job  = await client.create({ prompt: "a still grey card", duration: requested });
    const meta = await ffprobe(await client.download(job.id));
    expect(meta.duration).toBeCloseTo(job.resolvedDuration, 2);
  }
});

Note what it asserts. Not that the file matches the request — that is a
test you cannot pass and should not want to — but that it matches what the API
told you it resolved to. That is a contract you can hold a provider to, and
if the provider returns no resolved value at all, the absence is itself the
finding.

Running the loop is also the cheapest way to discover the grid empirically.
Seven requests, ffprobe on each, and you have the progression whether or not
anyone documented it.

Get the grid before you design around a number

For anyone about to build on one of these APIs:

Find the frame rate and the block size. They are often in the model card even when they are missing from the API reference.
Enumerate the legal durations once, at build time, and ship the list.
Check whether any legal duration is a whole number of seconds. There may be exactly one. If your product ever cuts to music, that value is the only sensible default you have.

That last point is not hypothetical. On the model I work with daily, the block
arithmetic is tight enough that across its entire published 4-to-15 second
range precisely one setting comes out even — and it is not a number anyone
would think to type. Someone
worked the progression out frame by frame and showed why only one lands on a whole second,
which is ten minutes well spent if you are about to pick a default your users
will inherit.

The general lesson is smaller than the arithmetic: when a generative API
accepts a continuous parameter the model can only satisfy discretely, the
rounding is part of the contract. Ask where the grid is before you let a
number reach your UI.

I help run minimax-h3ai.video, an independent
third-party interface for MiniMax H3. Not affiliated with MiniMax. Everything
above is checked against the published docs and linked where it isn't.

A GeoGuessr Decision Tree for Country-Level Photo Clues

Ray Lin — Fri, 14 Aug 2026 12:04:31 +0000

I maintain a photo-location tool, so I am biased toward software. That bias is useful only when a result can be checked. A country guess without the observations behind it is difficult to debug or trust.

Competitive GeoGuessr players use a compact decision procedure: discard impossible countries, prefer standardized clues, and stop when the frame is underdetermined. The same workflow helps when you are checking a photo someone sent you.

Start with information, not visual drama

Look for driving side, road-marking conventions, bollards and roadside hardware, plate geometry, and script class. These clues are often constrained by standards or geography. Terrain, architecture, and vegetation are useful tie-breakers, but they cross borders easily.

A tiny roadside post can carry more country-level information than a mountain dominating the frame. Record what is actually visible; do not infer letters, colors, or traffic direction hidden by blur.

An inspectable decision tree

def country_hypotheses(frame):
    candidates = all_countries()
    if side := visible_driving_side(frame):
        candidates &= countries_using(side)
    if lines := classify_road_markings(frame):
        candidates &= regions_with(lines)
    if bollard := classify_bollard(frame):
        candidates &= countries_with_bollard_profile(bollard)
    if plate := classify_plate_geometry(frame):
        candidates &= countries_with_plate_pattern(plate)
    if script := classify_script(frame):
        candidates &= countries_using_script(script)
    return rank_with_soft_clues(candidates, frame)

The output should be a shortlist plus the observations that changed its ranking. A single country name is not an explanation and cannot be falsified.

Matching versus inference

Reverse-image matching asks whether this frame, or a lookalike, appears in an index. It is strong for famous buildings and widely published scenes, but a generic street can produce a plausible image from another country. Scene inference reads road conventions, scripts, hardware, terrain, and built form. It works when the exact frame has never been indexed, but should become less specific as clue density falls.

Use matching for leads and inference for a falsifiable shortlist. Verify candidates against an independent map, street image, or second visible clue. Two tools agreeing is not proof if both copied the same weak signal.

Whichever tool you use, the property to insist on is that it names the clues behind each candidate. That is the design constraint behind the photo location checker I work on: it returns a ranked shortlist with the visual reasoning attached rather than a single pin, which is the only form of output you can actually argue with.

Stop before false precision

Use three independent anchors before calling a country likely. A script classification, a road-marking convention, and a roadside hardware profile are stronger together than three details from one sign. Stop at a region when there are no independent anchors. Indoor scenes without windows, heavily cropped screenshots, generated images, and generic suburbia can be structurally underdetermined. Showing that uncertainty is better engineering than inventing a precise pin.

What to log

Record provenance, metadata status, visible clues, output granularity, and why the candidate was accepted or rejected. Keep result screenshots and note the date because indexes and model versions change.

Disclosure: I work on Where Is This Place, one of the tools in this space. Its outputs are candidates, not facts, and this article describes a verification workflow rather than a claim that any single tool is always correct.

15 OSINT Tools Every Investigator Should Actually Open — In Order

Ray Lin — Tue, 04 Aug 2026 14:40:20 +0000

Installing more OSINT tools rarely fixes an investigation. Opening the right tool at the wrong stage can still waste an afternoon.

The mistake I see most often is starting with the largest possible sweep. Someone has a username, so they run three username enumerators. Someone has a domain, so they open Shodan before checking the site itself. Someone has a photo, so they upload it to every reverse-image engine and treat zero results as a dead end.

The useful unit is not a list of tools. It is an order of operations. Each stage should either answer the question cheaply or produce a better input for the next stage.

The order matters more than the list

My default workflow has six stages:

Preserve the source and define the claim.
Read what is still inside the file.
Check whether the artifact has already been published.
Read the visible evidence when matching fails.
Pivot into usernames, emails, domains, and infrastructure.
Preserve the chain of evidence.

The stages are deliberately asymmetric. A photo may stop at stage four. A domain investigation may begin at stage five. Maltego is useful only after you have enough entities to graph. Hunchly is useful before you think you need it.

Stage 0: preserve before searching

Before opening a tool, write down the claim you are trying to support. “This looks like Lisbon” is not the same claim as “this image was captured on Rua da Conceição.” The second claim requires street-level evidence and a much stronger chain.

Save the original file, record where it came from, hash it if the case matters, and work on a copy. Publicly reachable data is not automatically appropriate to publish. Decide who will review the conclusion before you collect a pile of screenshots no one else can audit.

Stage 1: ask the file first

1. ExifTool should get the first turn for images and media files. If GPS survived, you have file evidence rather than an inference. Camera model, capture time, editing software, and embedded thumbnails can also explain how the file moved.

Where it stops: screenshots never had camera GPS, and most social platforms strip metadata. “No EXIF” is not evidence that a photo is fake or untraceable. It only closes one lane.

I also use a small offline parser for batch triage when I only need to know which JPEG or PNG files still carry coordinates. The important property is local execution: the source image should not leave the machine just to answer a metadata question.

Stage 2: check whether it already exists

2. Google Lens, 3. TinEye, and 4. Yandex Images overlap, but they do not answer the same question.

Lens is strong on objects, text, and visually similar scenes. TinEye is better for exact copies, edits, and publication history. Yandex can surface regional matches the others miss. A useful reverse-search pass checks all three, changes the crop, and searches both the full frame and distinctive details.

Where they lie: a zero-result screen feels final. It is not. It says the engine did not find a match in its index. It says nothing about whether the image is genuine, new, private, cropped, or simply poorly indexed.

Operational note: every upload gives a third party the image. That may be acceptable for a public-domain case and unacceptable for source material.

Stage 3: read the frame

5. Visual-clue geolocation begins where reverse search ends. Instead of matching a copy, it works from what is visible: script and signage, road markings, traffic direction, plate shape, architecture, terrain, vegetation, utilities, weather, and shadows.

This stage is slower because every clue must be separated into observation and inference. “The curb is painted black and white” is an observation. “This is probably Singapore” is an inference. Mixing them makes a confident story easy to write and hard to falsify.

The practical rule is three independent anchors. A transit logo, a language fragment, and a road design can support each other. Three details all derived from one sign do not.

When metadata is gone and the image was never indexed, I use a photo location finder that shows its reasoning as a candidate generator, then verify the suggested place independently. The clue list matters more than the pin.

Where this stage stops: generic interiors, plain forests, heavy filters, night shots, and frames without readable text or infrastructure. “Not enough evidence” is a valid result.

Stage 4: pivot from the surrounding identity

If the case contains a username or email, the next five tools earn their turn.

6. Sherlock is a fast username sweep. 7. Maigret goes wider. 8. WhatsMyName is useful when signal quality matters more than coverage. 9. Holehe checks whether an email is registered with supported services. 10. Have I Been Pwned gives breach exposure context.

Treat every username hit as a lead, not a finding. A site returning HTTP 200 does not prove the account belongs to the target. Open the page, compare profile details, dates, avatars, writing style, and linked identities.

This is also the stage most likely to expose the investigation. Username and email tools may query live services. Some services log requests, rate-limit them, or notify account holders.

Stage 5: infrastructure only when infrastructure exists

11. theHarvester collects public emails, subdomains, and hosts. 12. Shodan indexes exposed services. 13. Censys is strong for certificates and asset pivots.

These tools are excellent when the case includes a company, domain, IP address, or certificate. They are theater when the only input is a street photo. Do not create an infrastructure stage just because the tools are familiar.

Where they lie: large result sets look like progress. Most of the work is still entity resolution, scope checking, and eliminating stale infrastructure.

Stage 6: hold the case together

14. Maltego CE becomes valuable when relationships no longer fit in a few browser tabs. Use it to represent entities and provenance, not to make weak connections look authoritative.

15. Hunchly captures and timestamps pages during research. That makes it the least glamorous tool on this list and one of the most important. Pages change. Accounts disappear. A conclusion that cannot be reconstructed later is a note, not evidence.

A compact comparison

Tool	Best input	What it returns	Common failure
ExifTool	Original file	Metadata and GPS	Nothing after stripping
Google Lens	Image or crop	Similar objects and pages	Visually similar wrong match
TinEye	Published image	Copies and edits	New or unindexed image
Yandex Images	Image or crop	Regional visual matches	Uneven regional coverage
Visual-clue geolocation	Unindexed photo	Ranked place candidates	Thin evidence looks precise
Sherlock	Username	Candidate profiles	HTTP false positives
Maigret	Username	Wider candidate set	More noise
WhatsMyName	Username	Curated service checks	Narrower coverage
Holehe	Email	Registration signals	Rate limits and live queries
HIBP	Email	Known breach exposure	Triage, not attribution
theHarvester	Domain	Hosts, emails, subdomains	Noisy and stale data
Shodan	IP or domain	Internet-exposed services	Not a people or image tool
Censys	Certificate or asset	Infrastructure pivots	Scope confusion
Maltego CE	Resolved entities	Relationship graph	Graphs amplify bad inputs
Hunchly	Browsing session	Captured evidence trail	It preserves; it does not find

Three habits that keep the result defensible

First, write observations before interpretations. If you cannot quote the raw clue without naming a place, you probably wrote an inference.

Second, attempt falsification. Take the leading candidate and look for something that should be present but is not. A candidate that survives an attempt to break it is stronger than one you only tried to confirm.

Third, record the tool and version. Search indexes, models, and datasets change. “Google found it” is not reproducible enough for an editor, incident review, or court filing.

FAQ

Are free OSINT tools enough?

Usually, if the workflow is narrow. Paid products buy coverage, speed, collaboration, or proprietary datasets. They do not remove the need to verify identity and provenance.

How accurate are AI geolocation tools?

There is no useful global number. Accuracy depends on the dataset, geography, image quality, and whether the claim is country-, city-, or street-level. Ask what the number was measured on and treat every candidate as a hypothesis.

Do OSINT tools alert the target?

Some can. Passive archives and local metadata tools generally do not. Username sweeps, email-registration checks, and anything touching the target's infrastructure may appear in logs or trigger controls.

The toolkit is the easy part. The difficult part is knowing which question each tool can answer, when it has earned its turn, and what evidence would prove your favorite candidate wrong.

Disclosure: I work on the image-geolocation tool linked above. The other tools are included because they occupy different stages of the workflow; there are no affiliate links.