Our pictures next to real photos of the Moon
We draw a patch of the south pole under the exact Sun of a real photo taken by NASA's Lunar Reconnaissance Orbiter, then compare the two. Drag the slider to see for yourself.
About 1 km across · drag to compare · photo credit: NASA/GSFC/Arizona State University
What we found
Passes all three checks- Large landforms match. Fine surface texture does not, because NASA's terrain data is coarser than the photo.
- Brightness matches the real photo closely.
- The main shadows line up. Their edges differ, because a Sun this low casts soft shadow edges.
Tested at one site under one Sun so far. More sites and lighting are next, and every custom dataset ships with its own comparison.
Request a dataset for your siteHow we knowthe scores, the photo, the render settings and the method
The three scores
Structural similarity (SSIM)
0.275How much of the photo's local structure the render reproduces, 7×7 window on a common stretch. 1 is identical. Limited by real sub-5 m texture the DEM cannot contain.
Brightness histogram distance (EMD, I/F)
0.00092Earth mover's distance between the render's and the photo's brightness distributions, after scaling the photo so the sunlit means match. 0 is identical; measures shape, not absolute level.
Shadow-mask overlap (IoU)
0.235Intersection over union of the geometric shadow label and the shadow seen in the photo. Shadows are small here, so this is a regression guard rather than a quality score.
These are the renderer's own numbers from its first honest run; the thresholds were set from that run and may only get stricter. Thresholds: services/renderer/validation/thresholds.yaml. Valid pixels: 39,102 of 40,000.
The photograph
- Product
- SHACKRDGE02_M139797542_350CM
- Source image
- M139797542L
- Taken
- 2010-09-22 12:24 UTC
- Incidence
- 88.55°
- Emission
- 1.69°
- Phase
- 88.79°
Angles are for the centre of the full NAC frame; the render uses the Sun computed with SPICE at this tile.
The render
- Sun
- 144.1° SE, 1.17° up
- Sun from
- SPICE (LT+S)
- Sun disk
- 0.53°
- Albedo
- 0.2
- Samples
- 64 per pixel
- Engine
- Cycles, Blender 4.0.2
The terrain
- Elevation
- LOLA 5 m/px
- Horizons
- LOLA, 80 km context
- Shadow (geometry)
- 542 px
- Photo no-data
- 898 px
Where the shadows agree
The shadow label is computed from geometry alone: a horizon march across 80 km of terrain with the Sun as a 0.53° disk. The photo's shadow is every pixel darker than half the sunlit median, plus pixels the NAC stereo pipeline could not map (it fails in deep shadow). The overlap of the two is the IoU above.
- Shadow in both437 px1.09%
- Shadow in the label only105 px0.26%
- Shadow in the photo only1,321 px3.30%
Most disagreement is shadow seen only in the photo: 898 of those pixels are holes the stereo pipeline left, and the rest sit around shadow edges, where a half-degree Sun 1.2° above the horizon casts a wide penumbra that the label must call yes or no. Shadows cover only about 1.4% of this tile at this time, so one site and one Sun is a regression guard, not a verdict on realism.
What the numbers mean, honestly
The brightness distribution is right once the photo's unknown calibration scale is removed (the photo is scaled so the sunlit means match). That does not validate the absolute albedo of 0.2; that needs a calibrated reflectance image, which is next.
SSIM of 0.27 is low in absolute terms, and expected: the elevation model is interpolated from laser altimeter tracks (effective resolution of tens of metres) while the photo has real texture at every scale. It measures how much of the photo's structure a terrain-only render carries, which is the right number to publish next to a dataset.
Not covered yet: perspective cameras, albedo variation, the synthetic fine-detail texture (off for this comparison), the Hapke model, other Sun azimuths and other sites.
Method and review: the full report is renderer-validation-shackrdge02-2026-10-11.md, and the method is in render-validation.md.