Import a RIEGL project (.riproject / .PROJ)

This walkthrough covers importing raw RIEGL scanner data — a project directory straight off a V-Line instrument — without going through RiSCAN PRO first.

Two on-instrument layouts are supported, and Phytograph tells them apart by what is inside the folder rather than by its name:

Layout	Written by	What it carries
.riproject	Older instruments (e.g. VZ-1000)	Scan positions only; no registration
.PROJ	Newer instruments (e.g. VZ-2000i)	Scan positions plus the instrument's own registration

The import path is otherwise identical: same menu item, same picker, same decoding. The one behavioral difference is that a .PROJ's scans can land already aligned — see Which frame the points land in.

If your data has already been through RiSCAN PRO or RiPROCESS, you don't need this: export to LAS/LAZ or E57 and use the ordinary import path. This feature exists for the case where the processing software isn't in the loop at all.

What this needs, per platform

RIEGL's RiVLib — the only library that can read .rxp — ships for Windows and Linux, not macOS. What that costs you depends on which you run:

	What you need
Windows	The RiVLib download, and nothing else. It runs natively.
Linux	The RiVLib download, and nothing else. It runs natively. x86_64 only — RIEGL publishes no arm64 build.
macOS	The RiVLib download and Docker Desktop, because there is no macOS build of RiVLib to run — Phytograph runs the Linux one in a container.

On Windows and Linux one optional extra buys you the sky/miss shell — see No-return shots need a C++ compiler (Windows and Linux). Everything else works without it.

Before you start: install RiVLib

RiVLib is proprietary. Its license forbids redistribution, so Phytograph cannot ship it — you download it yourself with your own RIEGL account, and Phytograph reads it from wherever you put it. Nothing is copied into the app.

WindowsmacOSLinux

1. Sign in to RIEGL's members area and download the x86_64-windows build of RiVLib — the 64-bit one, and the full package rather than a runtime-only variant. RIEGL ship several builds per release; a 32-bit library, or one carrying only the DLLs, has all the right filenames and Phytograph will tell you which is wrong when you select it.

2. Extract it to:

   %LOCALAPPDATA%\Phytograph\rivlib
   

   You want the folder that directly contains bin/, include/ and lib/ — not lib/ itself. Paste that path into File Explorer's address bar to create or open it.

   Why that folder

   Phytograph looks there on its own, so extracting to it means you can skip the Settings step entirely. Anywhere else works too — you just have to point at it by hand.

3. Open Settings (++ctrl+comma++) and check the badge beside RIEGL RiVLib folder reads RIEGL ready. If you extracted somewhere else, click Choose… and select the folder first.

4. If the badge does not turn green, the checklist below the setting names the missing piece:

   Checklist line	What to do
   ✗ RiVLib folder	Choose the extracted folder (the one with bin/, include/, lib/). Phytograph looks for lib\scanifc-mt-s.dll inside it.
   ✗ No-return (sky) shots	Optional — see below. Scans import without it.

There is no Docker, no image to build, and nothing to rebuild after a Phytograph update.

1. Sign in to RIEGL's members area and download RiVLib Part 1 for x86_64-linux-gcc9. The download page offers Parts 1–3 and several compiler versions (gcc 5, 7, 9, 11, 13); Part 1 for gcc 9 is the only combination Phytograph can use. Parts 2 and 3 are not needed.

   Why the Linux build on a Mac?

   The library runs inside a Linux container, so it is the Linux build that matters — not your Mac's architecture. The container is linux/amd64 regardless of whether you have Apple silicon.

   Why gcc 9 specifically

   RiVLib is distributed per compiler ABI, and the container it runs in is pinned to a matching one (Debian bullseye, glibc 2.31). A build for another gcc version will be accepted when you pick the folder — the checklist only looks for lib/libscanifc.so — and then fail later, when the reader tries to load it. If an import fails with a loader error mentioning GLIBC or libstdc++, you have the wrong build: download the gcc 9 one and point Phytograph at it instead.

2. Extract it. You want the folder that contains bin/, include/ and lib/ — not lib/ itself.

3. In Phytograph, open Settings (++cmd+comma++) and find RIEGL RiVLib folder. Click Choose… and select that folder.

4. The badge beside it should turn to RIEGL ready. If it doesn't, the checklist below the setting names the missing piece:

   Checklist line	What to do
   ✗ Docker running	Start Docker Desktop and reopen Settings. If the line says the docker command was not found, install Docker Desktop's CLI tools instead — the daemon may already be running
   ✗ RiVLib folder	Choose the extracted folder (the one with bin/, include/, lib/)
   ✗ Reader image up to date	Click Build reader image — a one-time step; the image is ~300 MB on disk once built

   The image is always built locally from your own RiVLib copy; it is never downloaded pre-made, because publishing it would mean redistributing RiVLib.

   After a Phytograph update the badge may read RIEGL update pending. That is not something you need to act on: the reader inside the image travels with the app, so an update can leave the image a version behind, and your next import rebuilds it first — a second or two, since only the reader layer changes and Docker already has the rest cached. It works offline. If you would rather not wait mid-import, Rebuild reader image in Settings does it now.

1. Sign in to RIEGL's members area and download RiVLib Part 1 for x86_64-linux-gcc9. The download page offers Parts 1–3 and several compiler versions (gcc 5, 7, 9, 11, 13); Part 1 is the only part Phytograph uses.

   Why gcc 9 rather than a newer one

   This build needs only glibc 2.17 and up, so it loads on essentially any current distribution — it is the safe choice, not a restriction. A build for a newer gcc works too, but only if your system's libstdc++ is at least that new, and when it isn't the failure is a loader error mentioning GLIBC or libstdc++ rather than anything that names RiVLib.

   x86_64 only

   RIEGL publishes no arm64 Linux build, so .rxp import is not offered on aarch64 machines. Phytograph says so rather than accepting a folder it cannot use.

2. Extract it to:

   ~/.local/share/Phytograph/rivlib
   

   You want the folder that directly contains bin/, include/ and lib/ — not lib/ itself. For example:

   mkdir -p ~/.local/share/Phytograph
   tar xf rivlib-2.15.5-x86_64-linux-gcc9.5.0.tar.gz \
     -C ~/.local/share/Phytograph
   mv ~/.local/share/Phytograph/rivlib-2.15.5-x86_64-linux-gcc9.5.0 \
      ~/.local/share/Phytograph/rivlib
   

   Why that folder

   Phytograph looks there on its own, so extracting to it means you can skip the Settings step entirely. Anywhere else works too — you just have to point at it by hand. If you set XDG_DATA_HOME, Phytograph looks under that instead.

3. Open Settings (++ctrl+comma++) and check the badge beside RIEGL RiVLib folder reads RIEGL ready. If you extracted somewhere else, click Choose… and select the folder first.

4. If the badge does not turn green, the checklist below the setting names the missing piece:

   Checklist line	What to do
   ✗ RiVLib folder	Choose the extracted folder (the one with bin/, include/, lib/). Phytograph looks for lib/libscanifc.so inside it.
   ✗ No-return (sky) shots	Optional — see below. Scans import without it.

There is no Docker, no image to build, and nothing to rebuild after a Phytograph update.

No-return shots need a C++ compiler (Windows and Linux)

A laser shot that hits nothing is not stored in the .rxp as a point at all. Phytograph recovers those shots and places them on a far-field shell — they are what Leaf Area Density measures transmission against, and they are typically 30–45% of a scan.

Reading them means using a C++ class from RiVLib rather than its plain C interface, and that cannot be done from Python alone. So a small helper is compiled once, on your machine, from your own RiVLib copy. That needs a C++ compiler:

WindowsLinux

Install the free Visual Studio Build Tools and select the Desktop development with C++ workload. (A full Visual Studio with that workload works too.)

RIEGL ships the class Windows needs only as a static library, which their license does not let us distribute pre-built — so even in principle this could not ship ready-made.

Install a C++ compiler:

sudo apt install g++          # Debian/Ubuntu
sudo dnf install gcc-c++      # Fedora/RHEL

Here the class is inside libscanifc.so itself, so nothing of RIEGL's is linked into the helper — but the result is tied to the exact libstdc++ and RiVLib copy it was built against, so it still has to be built here rather than shipped.

If the helper fails to build or load, the message says so and the scan still imports. The usual cause is a RiVLib built for a newer gcc than your system's libstdc++; the x86_64-linux-gcc9 build avoids it. You can also point Phytograph at a specific compiler with PHYTOGRAPH_CXX=/usr/bin/g++-11.

Nothing else to do on either: the next import builds it, in about two seconds, and caches the result until you change RiVLib or update Phytograph.

Without it, scans still import — points, reflectance, amplitude, deviation, returns, timestamps, GNSS and registration are all unaffected. What you lose is the sky shell, so the cloud has no Miss points under the Hit/Miss color scheme and Leaf Area Density has nothing to work from. Settings shows this as its own checklist line rather than a failure, and an import that skipped them says so.

macOS is unaffected: the container carries its own compiler.

Import a project

Either:

• File → Import → RIEGL Project (.riproject / .PROJ)… and pick the project folder, or
• drag the project folder onto the viewer.

Phytograph reads the project's metadata and opens a picker listing every scan position:

• Point count — approximate. A .riproject shows a lower bound (≥) from probing the start of each file; a .PROJ shows an estimate (~) from the file size, because it needs to decode nothing at all. The exact count appears after import.
• Sweep — the commanded field of view, e.g. 30–130° × 0–360°.
• Instrument — e.g. VZ-1000, VZ-2000i.
• Placement — for a .PROJ being imported registered, how that position is placed: registered, prior only, or no pose (see below). For a .riproject, GNSS ✓ / no GNSS instead, since that is what decides where its points land.

A small plan view shows the layout — from the surveyed poses where the project has them, and from the GNSS fixes otherwise — so an implausible layout is visible before you commit to the import.

Both layouts open quickly

A .PROJ states everything in small JSON sidecars, so a 24-position project lists in about a second. A .riproject hides its GNSS inside the point stream, so previewing one means decoding the start of every position — but only until that position's GNSS and orientation records appear, which is typically within the first few thousand points. A 19-position .riproject lists in about a second too. The first read of a project that isn't in the operating system's file cache is slower.

Every readable position is selected already, so untick the ones you don't want and click Import. The header checkbox toggles them all at once — it reads Deselect all while everything is selected, and Select all otherwise.

Positions that couldn't be read are listed but not selectable, grayed out with the reason shown inline.

Start small

Import takes tens of seconds per position, and point counts run to millions — a full-dome VZ-1000 position in our testing was ~13 M points and ~760 MB in memory, though this varies with the survey's field of view and angular resolution. Import one or two positions first to check the data is what you expect.

You can cancel a running import from the progress dialog. Canceling discards the whole import — including positions that had already finished — so nothing half-imported is left in the scene. An import that somehow runs past an hour is stopped automatically.

A position that fails is a different matter: it is skipped and the rest of the import carries on, with the closing toast naming the position and the reason. So a single bad position no longer costs you the whole run.

What you get, and what you don't

Which frame the points land in

A .riproject is never registered

Raw scanner data from an older instrument carries no alignment — that is what RiSCAN PRO produces. Each position is recorded in its own frame, with the scanner at its origin.

Where a position has a GNSS fix, Phytograph places it at that fix's offset from the project centroid. This is a starting point, not a registration: the instrument's built-in GNSS is meters-accurate, not survey-grade. Use it to seed ICP registration, which refines the alignment properly.

The centroid is the whole project's, not just the positions you ticked, so a position lands in the same place whether you import it on its own or alongside the rest. That means you can import positions in separate batches and they will still line up with each other.

Where a position has no fix, it imports at the origin — so several such positions will sit on top of one another until you register them.

…but it can still be leveled

Even without registration, the scanner recorded which way was down. A V-Line instrument writes its dual-axis inclinometer into the scan, and that reading is genuinely precise: checked against RiSCAN PRO's own transforms on two separate projects, it agrees to within a few hundredths of a degree.

The picker therefore offers Level using the onboard inclination sensor, which is on by default. It rotates each position upright using its own tilt reading — typically 1–3°, occasionally 4°, depending on how carefully the tripod was leveled.

This matters more than it sounds. Ground segmentation, DEM generation and any slope measurement all assume the cloud is plumb. A 3° tilt displaces a point 50 m away by about 2.6 m vertically, which is enough to bend a "ground" surface that should be flat.

Leveled is not aligned

Leveling fixes tilt and nothing else. It does not rotate scans to north and it does not align them to each other — you still need ICP registration for that.

The instrument does record a compass heading, and Phytograph deliberately ignores it. Measured against RiSCAN's transforms it was 10–14° wrong, and the scanner's own confidence figure did not predict the error — a reading claiming 0.22° accuracy was 14° out. A heading that wrong is worse than none, because it looks aligned.

Positions that recorded no usable tilt simply import unleveled; the picker says how many, and the rest are still leveled.

What the Scans panel's tilt row means

It reports the tilt the cloud has, not the reading the inclinometer took — so it answers "is this cloud plumb?", which is the question the rest of your workflow depends on.

Imported	Panel shows	Because
Leveled	roll 0° · pitch 0° (level)	The tilt was rotated out of the points
Unleveled	the measured tilt, e.g. roll 1.32° · pitch 2.97°	The points kept it

The row is always shown, so 0° (level) is a statement rather than a gap. Leveling does not discard the measurement — it is what produced the rotation, and it stays with the scan.

If you want the angular model to describe the instrument as it physically sat on the tripod (which is what LAD wants — see below), import unleveled.

A .PROJ usually is, but only partly

A newer instrument registers on board as it goes, and stores the result per position. Phytograph uses it by default: the scans land already aligned, in a frame whose +Z is true up and +Y is true north, so the ground is level and no ICP is needed between them.

Registration routinely fails for some positions, so the picker reports each one:

Badge	Meaning
registered	Placed by the project's own registration result — accurate to millimeters
prior only	Registration failed here. Placed from the scanner's inclinometer, compass and GNSS instead — accurate to about a meter. Refine with ICP.
no pose	No position information at all (an aborted acquisition). Imports at the origin

The summary under the list says how many of each you are about to get, and the toast after the import repeats it. In one 24-position orchard project we tested against, 8 positions registered and 15 fell back to the prior — a normal outcome, not a fault.

Keeping scanner-local coordinates instead

The picker offers Keep scanner-local coordinates for a .PROJ. Ticking it imports every position unregistered, exactly as a .riproject behaves.

This exists for Leaf Area Density. LAD models a scan as an origin plus a θ/φ sweep, with no scanner tilt. In the scanner's own frame that description is exact. Once a scan is rotated into the project frame, the instrument's real tilt off plumb — under 2° in our reference project — is no longer represented, and the LAD raster carries that much error.

So: leave it unticked for a leveled, mutually-aligned scene, which is what almost every workflow wants. Tick it when you are running LAD on a single position and want the angular model to be exact.

Sky/miss points are recovered exactly

An .rxp file stores only returns — a shot that hits nothing is absent rather than flagged — so the miss rays have to be recovered separately. Phytograph reads them from the scanner's own record of every laser shot, which means each miss carries its true beam direction rather than one inferred from the scan grid. On a typical scan they are a large fraction of the data (about 46% of shots on our reference position).

They are placed 20 km along their beam, the same far-field shell every other Phytograph importer uses, and flagged with is_miss — so they are hidden by default, excluded from the bounding box, and available to Leaf Area Density, which needs them for its Beer's-law transmission term.

To see them, turn on Show sky/miss points for the scan.

On Windows and Linux this needs a C++ compiler

Reading these shots uses a C++ class from RiVLib, so a small helper has to be compiled once on your machine — see No-return shots need a C++ compiler (Windows and Linux). Without it the scan still imports, but with no sky shell at all, and Leaf Area Density has nothing to measure transmission against. Phytograph says so at import rather than leaving you to discover it later. macOS is unaffected: the container carries its own compiler.

What does come through

Field	Notes
Position (x, y, z)	Registered into the project frame, or scanner-local offset by the GNSS fix
Reflectance	dB relative to a white diffuse target; drives the default coloring
Amplitude	dB
Deviation	Pulse-shape distortion measure
Target index / count	Per-pulse return numbering, for multi-return analysis
Scan parameters	Sweep and resolution from the position's .pat (.riproject) or .scn (.PROJ) file
Scanner heading and tilt	.PROJ only, when imported registered: recovered from the pose
Instrument	Named by the file, and used for the scan's marker. The V-Line models have their own entries (VZ-400i, VZ-1000, VZ-2000i); another VZ is marked as RIEGL VZ-series rather than being labeled as a model it isn't

The scanner also records a set of instrument-diagnostic scalars — Background Radiation, Echo Type, Waveform Available, Pseudo Echo, SW Calculated Target, PPS Locked and Mirror Facet. These describe how the scanner arrived at a return rather than the surface it hit, so the import wizard lists them with Import unticked: they are left out by default, keeping the scan lighter and the color-by picker readable. Tick any of them in the wizard to carry them through — useful when you are separating real returns from multiple-time-around artifacts, or auditing GNSS timing on a moving platform. Columns your particular instrument never populates (a VZ-1000 records no background radiation) are not listed at all.

Multi-return numbering is derived by grouping returns that share a pulse timestamp. If that grouping ever disagrees with the scanner's own echo classification, the toast shown when the import finishes says how many positions were affected, and those two columns should not be trusted for multi-return work on those scans — the points themselves are unaffected.

This is the right path for multi-return LAD

Importing the project directly preserves every echo. Going through a PTX export from RiSCAN PRO does not: PTX stores one point per grid cell, so each pulse is collapsed to a single echo and the per-pulse columns above are lost. That biases LAD high (Kent and Bailey, 2024) and does so silently — the re-imported scan is genuinely single-return, so nothing downstream can warn you. If you must go through an intermediate file, use a structured .e57. See Single- vs multi-return scans.

That same toast says how the scans were placed — how many were registered, how many came from a prior and still want ICP, or that they are unregistered altogether.

Because the project records where the instrument stood at each position, an import into an empty scene also places the scene origin — the pivot the view orbits about — at the average of those scanner positions, rather than at the middle of the point cloud's bounding box. Snap to scanner in the Scene Origin panel moves it onto any single position, and Reset to scene center puts it back on the bounding box.

Troubleshooting

"RIEGL .rxp import needs an x86_64 machine." : RIEGL publishes no arm64 build of RiVLib, so raw .rxp cannot be read on an aarch64 Linux machine at all. Export to LAS/E57 from RiSCAN PRO or RiPROCESS instead.

"RIEGL .rxp import is not available on this platform." : Phytograph found no way to run RiVLib here. Export from RiSCAN PRO or RiPROCESS instead.

"Docker is installed but not responding." (macOS) : Start Docker Desktop. The badge re-checks on its own within a few seconds. If it is already running, the daemon itself has wedged — quit Docker Desktop fully and reopen it, or use its Troubleshoot → Restart button. You will never see this on Windows or Linux — RiVLib runs natively there and Docker is not consulted at all.

"No lib/libscanifc.so under …" (macOS, Linux) or "No lib\scanifc-mt-s.dll under …" (Windows) : The chosen folder isn't a RiVLib root. Pick the level containing bin/, include/ and lib/. The platforms need different downloads, not just different folders: Windows needs x86_64-windows; Linux and macOS both need the x86_64-linux-gcc9 build — Linux because it runs it directly, macOS because it runs it in a container.

"No-return (sky) shots cannot be read". (Windows, Linux) : Install a C++ compiler and re-import — the free Visual Studio Build Tools with the Desktop development with C++ workload on Windows, g++ on Linux. See above. Scans imported before you install it have no sky shell and need re-importing to gain one; the points themselves are unaffected.

Windows: "this RiVLib has no lib\scanlib-mt-s.lib". : You have a runtime-only or partial download — the DLLs are there, so points, reflectance, GNSS and registration all work, but the library the sky-shot helper is built from is missing. Download the full RiVLib package and select it again. Nothing else changes; the import still runs, just without a sky shell. Windows only: on Linux that class lives inside libscanifc.so, so there is no second file that can be missing.

"…is a 32-bit x86 build" / "…is an ARM64 build" / "…is not a valid Windows library" / "…is not a valid Linux shared library". : RIEGL ship several builds per release and it is easy to take the wrong one. Phytograph checks the library's own header when you select the folder, so these are caught before you import rather than partway through.

- **Windows** needs the **64-bit (`x86_64`)** Windows build.
- **Linux** needs the **`x86_64` Linux** build, and the machine must be
  x86_64 too — RIEGL publishes no arm64 build, so Phytograph reports an
  aarch64 machine as unsupported rather than accepting a folder it could
  never load.
- **macOS** needs the **`x86_64` Linux** build — *not* an ARM one, even on
  Apple silicon. The container is `linux/amd64` regardless of your Mac; the
  architecture that matters is the library's, not the machine's.
- "not a valid … library" means the file is not a usable library at all,
  which almost always means a download that stopped early.

Re-download the right build and select the folder again.

macOS or Linux: the folder is accepted but the import fails with a GLIBC or libstdc++ error. : The one mis-download Phytograph cannot catch up front. A gcc 11 or 13 build is a perfectly valid x86_64 library; what makes it unusable is symbol versioning the loader only resolves at run time. Download Part 1 for x86_64-linux-gcc9 and re-select it.

The rule differs slightly between the two. On **macOS** gcc 9 is *required*,
because the container is pinned to a matching glibc. On **Linux** it is the
safe floor rather than a mandate: a newer build works if your own
`libstdc++` is at least as new.

Linux: the scan imports, but says the sky-shot helper could not be built or loaded. : The points are all there; only the sky shell is missing. Either no C++ compiler was found (sudo apt install g++), or the helper was built but could not load — usually a RiVLib for a newer gcc than your libstdc++, or, in a packaged build, a system compiler newer than the one Phytograph ships libraries for. Pick the x86_64-linux-gcc9 RiVLib, or name a specific compiler with PHYTOGRAPH_CXX=/usr/bin/g++-11 and re-import.

"Docker is not running" while Docker Desktop is clearly up. : Two different bugs produced this, both fixed. In builds before v0.68.0 the probe forked the backend process; with the LiDAR and PROJ libraries loaded the forked child crashed before it could run docker, which read as "Docker absent" (and macOS reported as "Python quit unexpectedly"). In builds before v0.88.0, an app launched from Finder or the Dock inherited macOS's bare startup PATH, which contains neither /usr/local/bin (Docker Desktop's CLI) nor /opt/homebrew/bin (Homebrew's) — so Phytograph could not find the docker command even with the daemon running perfectly. Neither restarting Docker nor restarting Phytograph helped; launching the app from a terminal did, which is the workaround on an older build. Phytograph now looks in the standard install locations directly, and says "The docker command could not be found" when the command really is absent, rather than blaming the daemon.

"The docker command could not be found." (macOS) : Docker Desktop either isn't installed, or is installed without its command-line tools. Install it, or open Docker Desktop → Settings → Advanced and enable the CLI tools / default Docker socket so docker is installed to /usr/local/bin. This is a different message from "Docker is installed but not responding", which means the daemon itself is stopped or wedged — start or restart Docker Desktop for that one.

Building the reader image fails with error getting credentials … "docker-credential-desktop": executable file not found in $PATH. (macOS) : Fixed after v0.93.0. Phytograph found the docker command by its full path, but docker then looks up its credential helper by name on the same bare startup PATH, and that fails whenever Docker has to contact a registry. Docker Desktop's per-user install hits this most often, because it puts both programs in ~/.docker/bin. Status checks never contact a registry, so Docker showed as ready. The error only appeared when the reader image was built, which Phytograph also does by itself after an update changes the reader. Phytograph now makes the helper visible to the docker processes it starts. On an older build, run sudo ln -sf ~/.docker/bin/docker-credential-desktop /usr/local/bin/ and try again.

macOS: the import is slower than RiSCAN PRO, or than the same scan on Windows or Linux. : Expected. RiVLib runs natively in those cases; on macOS it runs under x86 emulation inside a container. Phytograph also builds a level-of-detail octree either way so large scans stay interactive, and that octree build — not reading the scan — is the larger half of the time on every platform. For scale, one 23 M-point VZ-1000 position takes roughly half a minute end to end on Windows, of which about ten seconds is RiVLib decoding the .rxp and the rest is building the octree.

Dropping the folder does nothing / files are rejected one by one. : Make sure you are dropping the .riproject folder, not its contents. A folder of loose .rxp files is not a project.

The picker opens but lists no scan positions. : Positions are found by looking for sub-directories named ScanPos… (.riproject) or ScanPos….SCNPOS (.PROJ) — the layouts RIEGL's V-Line instruments write. A project organized any other way isn't recognized. A position whose folder exists but holds no .rxp is skipped rather than listed as broken.

"The RIEGL reader image is out of date and updating it automatically failed." : Phytograph normally rebuilds a stale reader image by itself at the start of an import, so you only see this if that rebuild failed — most often because Docker stopped between the check and the build. Start Docker Desktop and try the import again, or click Rebuild reader image in Settings to see the build's own error.

A .PROJ imports, but the scans are not aligned. : Check the badges in the picker. If they say prior only, the instrument's own registration failed for those positions and they are placed to about a meter; run ICP to refine them. Also check you did not leave Keep scanner-local coordinates ticked.

The import finished, but fewer positions arrived than I selected. : A position that fails is skipped rather than taking the whole import with it, and the closing toast names the first one and why it failed. Common causes are a full disk — the octree cache is written under your user profile and a large project can add tens of gigabytes — and a position the reader could not decode. Re-running the import rebuilds only the missing positions; the ones that already converted are served from the cache and come back in seconds.

A .PROJ holds .rdbx files — are those used? : No. Phytograph reads the .rxp beside them. The .rdbx is RIEGL's processed cloud and would need a second licensed library to open, and it does not contain the no-return shots that Leaf Area Density depends on.