Skip to content
LidarKit

Point cloud to orthophoto

Turn the colour your points already carry into a georeferenced image. Runs on your machine — no upload, no fixed size limit.

Drop a LAS or LAZ file to grid

or choose a file

DEM and orthophoto as GeoTIFF · nothing leaves your machine

No upload. Processing runs in a Web Worker on your device — this app has no server component and no upload endpoint. How it works

What it is actually doing

A coloured point cloud already contains a picture of the site; it is just stored as several million individual samples rather than as a grid of pixels. This imposes a grid on it, averages the colour of the points that fall in each cell, and writes the result as a georeferenced image.

The same pass can produce a surface model from the same cells, which is the reason to do it here rather than in two steps: an orthophoto and a DSM built from one grid line up exactly, pixel for pixel, with no resampling between them. Tick both on the DEM page and you get both.

What it is not

It is not an orthomosaic. An orthomosaic is built by projecting the original photographs onto a surface, so its detail comes from the camera — centimetres per pixel, regardless of how many points the cloud holds. This is built from the points, so its detail comes from the point spacing. Where the cloud is dense the two look surprisingly close; where it is sparse this one is visibly blockier, because it is showing you exactly as much as was measured.

What it is good for: a base map that matches the cloud exactly, a drape for a terrain view, a quick look at a site without opening anything large, and any case where the photographs are not available any more but the cloud is.

Things worth anticipating

  • Building edges are soft. A cell at the edge of a roof contains both roof points and facade points, and the average of the two is the colour it gets. This is the cost of averaging rather than taking the topmost point, and it is a much smaller cost than the speckle the alternative produces.
  • Overhangs win. Anything above the ground contributes its colour to the cell it is over, so tree canopy covers the ground beneath it, exactly as it would in a photograph taken from above.
  • Gaps are transparent, not black. Cells no coloured point landed in carry alpha zero. Software that ignores the alpha band will show them as black, which is worth knowing before assuming the image has a hole burnt in it.
  • Noise and withheld points are dropped first, so a flagged bad return cannot contribute its colour either.

Check it before you use it

The image is shown in place before anything is downloaded, and the hillshade from a surface model can be laid over it if you build one at the same time — which is the fastest way to tell a real feature from a colouring artefact. Coverage is reported as a percentage, so a cloud that is patchier than it looked in 3D shows up as a number rather than as a surprise later.

Frequently asked questions

What does it need from my file?
Per-point colour. That means point data record format 2, 3, 7 or 8 — the formats with RGB fields. (Format 10 carries RGB too, but pairs it with waveform data, which is rejected before anything runs.) Drop in a file without colour and the option is disabled with the format it actually has, rather than producing a grey image. Clouds from Metashape, RealityCapture, Pix4D and most modern drone LiDAR carry colour; older airborne LiDAR frequently does not.
Is this the same as an orthomosaic from photogrammetry software?
No, and the difference is worth being clear about. An orthomosaic is built by resampling the source photographs onto the surface, so its resolution comes from the imagery. This is built from the colour attached to the points, so its resolution comes from the point density — one cell, one average colour. It is the right product when the cloud is what you have, when you want an image that lines up exactly with a DSM built from the same points, or when you want a base map without going back to the original photographs. It will not match an orthomosaic for sharpness.
Why does it average the colour instead of taking the topmost point?
Because the topmost point is one measurement, and one measurement per cell speckles badly wherever density drops to a point or two — and a single mis-coloured return becomes a whole visible pixel. Averaging costs a soft edge where a facade meets a roof, and buys an image that does not have to be explained. The geometry is unaffected either way: the surface model still takes the maximum.
What happens where there are no points?
Those cells are written transparent, using a proper alpha band that GDAL and QGIS recognise as a mask. Colour is never interpolated. A Laplace fill across a hole in imagery looks like smeared paint, whereas a transparent hole reads correctly at a glance as nothing was seen here.
My colours come out too dark, or washed out. Why?
LAS stores colour in 16-bit fields, and writers disagree about how to use them: some scale to the full 16-bit range, others put ordinary 8-bit values in unscaled. Which one a file did is decided here from the brightest sample in the whole cloud, so one convention is applied consistently across the survey rather than per tile. If the result still looks wrong, the cloud's own colours are worth checking in the viewer first.
What does the output look like as a file?
A tiled, Deflate-compressed, four-band 8-bit GeoTIFF — red, green, blue and an unassociated alpha — with 256×256 tiles, the horizontal predictor, and the source file's coordinate system. GDAL reports the fourth band as a per-dataset alpha mask, so transparency survives into anything that reads it.

Related tools

Learn more