Step 7 — Show HN (OPERATOR-GATED — do not post without an explicit go)

Discovery plumbing (secondary). This page makes the service findable by someone already searching; it does not replace pipeline work (page 00). Do it once; no paid tier, listing or upgrade (hard rule 6).

Why gated: timing and readiness matter more than the venue. Evidence from our own teardowns: launch threads did NOT drive conversion for the APIs that won (Firecrawl's Show HN scored 23 points); the demo being keyless and instantly runnable is what converts. So this fires only after Steps 1–6 are live, and only when the operator says go.

Do this (on go)

  1. Use the company HN account (aged accounts do better; if none exists, create one now and let it age — that is itself a step worth doing early).
  2. Post using the prepared title + URL + first-comment below, verbatim. Show HN rules require the thing to be tryable "without barriers such as signups" — our no-account endpoint is the entire pitch, so the submitted URL is the demo, not the homepage.
  3. For the first 3 hours, answer every technical question honestly and per claims discipline (the first comment already states what is and is not validated — stay inside it).

Artifact

Date Account Thread URL Points @24h

Prepared title, URL and first comment (paste verbatim)

Embedded verbatim from docs/discovery/submission_drafts/show_hn_draft.md — the in-repo file is the source of truth.

Draft — Show HN post

DRAFT ONLY. Nothing has been posted. The operator posts. R10 venue 5.

Do not post this until the demo is genuinely ready. HN's own rule: "If your work isn't ready for users to try out, please don't do a Show HN." You get one credible shot and a dead Show HN is public and permanent. The precondition is the Hugging Face Space live and warm, or at minimum the curl path verified from a machine that has never called the API.

Do not solicit upvotes. It is against the rules and HN's anti-abuse software discards the votes anyway.


Why we qualify natively

HN requires "something you've made that other people can play with" and asks that it be tryable "without barriers such as signups or emails." That rule is what kills most B2B API launches on HN. It is precisely the thing /public/reconstruct satisfies. This is a native Show HN, not a Show HN with an asterisk — and the title should spend that advantage, not bury it.

Title

Show HN: Reconstruct a digital hologram over HTTP, no signup

Alternates if that reads long:

Show HN: A holographic reconstruction API you can call without an account
Show HN: Upload a hologram, get quantitative phase back – no account needed

URL field

The Hugging Face Space URL (something a reader can click and immediately use). If the Space is not live, use https://api.apertureapi.com/llms.txt — it is the one page that is both immediately readable and immediately actionable. Do not point the URL field at a landing page; HN explicitly rules out "sign-up pages" and reading material as off-topic.

First comment (post immediately after submitting)

Author here. A digital hologram is one intensity frame recording the
interference between light scattered by an object and a reference beam — the
depth and phase information is in the fringe pattern, not the brightness. This
service numerically propagates that field back to the object plane with
angular-spectrum wave propagation and returns quantitative amplitude and phase,
which is a measurement of optical path length rather than a picture. No learned
model anywhere in the path.

You can run it right now without an account. It's a two-step call because the
anonymous path is gated by an HMAC-signed form token rather than an API key:

  TOKEN=$(curl -sS https://api.apertureapi.com/public/form_token \
    | python3 -c 'import sys,json;print(json.load(sys.stdin)["token"])')
  sleep 4
  curl -sS -X POST https://api.apertureapi.com/public/reconstruct \
    -F "form_token=$TOKEN" -F "file=@hologram.tif" \
    -F "wavelength_um=0.635" -F "pixel_pitch_um=1.85" \
    -o reconstruction.zip

The token is bound to IP and User-Agent and has a minimum dwell, so mint and
submit from the same client and don't race it.

Three constraints worth stating up front, because they shape the whole design:

1. It runs on a 2-core / 4 GB box shared with everything else. So anonymous
   submissions are centre-cropped to 1920x1080, and the pipeline does a memory
   preflight and returns 507 with an estimate when a request won't fit, rather
   than being OOM-killed mid-reconstruction. A kernel kill returns no HTTP
   response at all and takes any concurrent request down with it, which is a
   much worse failure than a refusal. Crop rather than downscale, by the way —
   decimation aliases the carrier fringes in an off-axis hologram and destroys
   the phase you came for.

2. Determinism is a contract, not an aspiration. Quantitative arrays stay
   float64; float32 is allowed only for display rasters and filter kernels.
   Every run emits a quality_report.json with explicit pass/warn/fail bands per
   metric, and metrics the system can't establish — absolute height accuracy,
   per-pixel uncertainty, repeatability/gauge R&R — come back as
   "not-yet-established" with a null value instead of a number we'd have to
   defend.

3. The honest state of validation. The strongest artifact behind this is a
   reconstruction of a hologram from an independent published dataset (UTIRnet,
   Zenodo record 8059636 — data we didn't generate). That dataset ships two
   independent ground-truth reconstructions, and their agreement with each
   other caps what any method can score on it. We reach 98.6% of that ceiling
   (NCC 0.9675 against the dataset's GS ground truth; ceiling 0.9809). Overall
   quality band is "warn", driven by SNR at 14.2 dB and background phase RMS at
   0.092 rad — and that's a genuine reading, not a formality.

   The caveat belongs in the same breath: that hologram is simulated and the
   object is a simulated resolution target. It's independent and anyone can
   re-run it, but it's synthetic. The calibration end-to-end artifacts are
   weaker still — closed-loop synthetic, where the hologram is generated by the
   same forward model the optimizer fits, which proves the plumbing converges
   and nothing about accuracy against a real object. There is no
   physical-target validation artifact yet. If you see an accuracy or
   throughput number attached to this project that doesn't name a committed
   file, it isn't backed.

The other thing you can do without an account: calibration. If you don't know
your rig's true pixel pitch and wavelength — most DIY setups don't — photograph
a cheap catalog object (an M1.6 hex nut, a prepared salt slide; see
/calibration/targets), send that frame alongside your sample, and the optimizer
fits your real parameters against the object's parametric digital twin before
reconstructing. Nothing is persisted for anonymous callers. One honest
limitation there: wavelength and propagation distance are degenerate in the
forward model over a narrow range, so recovered pitch is far tighter than
recovered wavelength. That's optics, not a bug, and the committed artifacts
show it.

Happy to go into the propagation math, the quality-band design, or why the
memory envelope ended up driving so many API decisions.

What not to do in the thread

Verifiable artifact when executed: the HN item URL, plus the first comment visible under it with no edits that soften the validation caveats.


Buyer pages to pair with this page: workflow fit · reproducibility bundle · validation docket. Pipeline stages and KPIs: page 00.