The histogram is not unimodal
An EMCCD detector operated at high electron-multiplication gain (the regime that is used for twilight imaging, fast cadence work, and lucky-imaging) produces a pixel-value histogram on a flat field that is bimodal. There is a tall peak at zero (pixels that recorded zero photons during the exposure) and a long, multiplication-noise-broadened tail at non-zero values (pixels that recorded one, two, or more photons). The mean of this distribution at any single pixel is a poor description of what is in the data; the distribution itself is what carries the information.
Every image-restoration method that has been trained on Gaussian noise assumes — implicitly through its L2 loss, or explicitly through its forward model — that the noise distribution around the underlying truth is symmetric. Poisson noise in the few-count regime is not symmetric. Multiplication-noise-broadened Poisson noise is doubly not symmetric. This is not a theoretical concern; it is the reason BM3D and DnCNN produce smoother-looking outputs that fail by 3-4% on photometric calibration.
Replace the loss, not the architecture
Photon's architecture is, structurally, an entirely standard variational autoencoder. The change is the reconstruction loss: instead of an L2 distance between predicted intensity and observed pixel value (which is what a standard VAE uses; equivalent to a Gaussian likelihood), we evaluate the Poisson log-likelihood of the integer-valued observation against the network's predicted intensity, with a per-pixel multiplication-noise correction folded into the variance using the detector's known gain. The KL term against the latent prior is unchanged.
This is, conceptually, a small change — one term in the loss function. It is in practice a large change in behaviour: the network can no longer reduce its loss by predicting a smoothed-out intensity field that happens to have low L2 against the observed counts. The Poisson likelihood penalises predictions that are far from the integer-valued observations in a way that is asymmetric, and the network is forced to learn a representation that respects photon-count statistics.
The 1.7× number, with proper caveats
The headline benchmark is 1.7× effective gain over BM3D at g = 200, with a photometric bias of +0.3% (BM3D's photometric bias at the same gain is +3.1%). The detail that matters: this is at g = 200, on the partner-site EMCCD, on a calibrated star field. At lower electron-multiplication gain the advantage narrows. At g = 100 Photon is 1.4× over BM3D; at g = 50 (a regime where the read noise begins to dominate over photon shot noise) Photon and a self-supervised Gaussian baseline are roughly equivalent and Photon is no longer worth the integration cost.
We say this in the dispatch because it would be easy to publish "1.7× over the state of the art" as a headline and leave the gain dependence in a supplementary figure that nobody reads. Photon is a regime-specific tool. If your detector is not operated at g ≥ 100, the dispatch you should be reading is somebody else's.
Where Photon is in production today
Two partner observatories have Photon in their nightly pipelines. One uses it as a twilight-calibration denoiser before flat-fielding; the other uses it inside a lucky-imaging stack targeted at close binary companions. Both installations are partner-hosted — Photon ships as a Docker image with a deterministic CUDA build, the partner runs it on their own GPU, and we keep an on-call window for the first month after integration goes live. A third observatory is currently evaluating Photon against an in-house solution; we have no opinion on the outcome of that evaluation until they share it with us.
The validation notebook reproduces every figure in this dispatch end-to-end on a single A100 in under twenty minutes. The notebook ships with the model release; the model release is on the Data page with the appropriate citation pattern.
The regimes Photon is honestly bad at
Long-exposure CCD imaging in the read-noise-limited regime is the obvious one — the Poisson likelihood overpenalises a network that should be matching a roughly Gaussian noise model, and you will get worse results than a vanilla L2-trained DnCNN. The crossover point on the partner-site detectors is around g = 50 to g = 75; below that, classical denoisers win and Photon should not be used.
Source deblending is the less obvious one. Photon is a denoiser, not a deblender. Two overlapping point sources in the input frame will come out denoised but still overlapping; the photometry will be improved but the astrometry of the unresolved pair will still be wrong. A deblending step (PSF fitting, source extraction with confusion handling) needs to sit upstream of Photon if your science case is in a crowded field.
Finally, time-domain reconstruction across a sequence of frames — pulling sub-pixel motion out of a fast-cadence stack — is something we have explored on a research basis and have not yet released. It is the obvious next step for Photon and is on the engineering roadmap, but it is not in the current release and we do not want a partner to deploy the current release expecting it to do something it cannot.
The temptation in image-restoration work is to optimise the metric an automated leaderboard reports. The temptation in operational deployment is to optimise the metric a tired instrument scientist actually looks at on a Tuesday morning. The two metrics are not the same and we should stop pretending they are. — Solstice engineering desk · Dispatch 2026-03-09
If you operate EMCCD at high gain
The fastest path to deciding whether Photon fits is the validation notebook. Email with the detector, the gain, and a representative calibration frame; we will tell you honestly whether it is worth your time.
Open contact →