Label one volume. Publish the record with it.
Nitsor is a 3D annotation tool for CT and MRI that runs in a browser, with a log underneath it. A group of two or three can register a volume, label it, have a second person accept the work, and cut a release that a reviewer can check without downloading the scans. The scans stay in your own storage, on your own grant.
Me 163 V5 · projection
256 cubed samplereal scan
What a research group gets
A record you can cite
Every label is saved as one event that names its author, the version of the label list in force, and what it came from. A release ties those events to the data with a hash chain, so a reader can check the record without your scans.
A second reader in the log
Agreement between two people is usually the claim a paper rests on. Here the disagreements stay in the record instead of being smoothed away, and a change reads in millimetres and counts.
No per-person cost
Read-only accounts are free and unlimited, so a supervisor, a collaborator at another lab and a reviewer can all look without a licence conversation. Nothing is charged per label or per study.
Cone-beam CT, and the spacing that trips tools up
Cone-beam scanners fire a cone of X-rays through the sample and catch it on a flat panel, rather than sweeping a thin fan slice by slice. Dental scanners, lab micro-CT benches and most small-animal rigs work this way. The output usually arrives as DICOM, and the workspace treats it as any other volume.
The catch is spacing. In a cone-beam study the distance between slices is often different from the distance between pixels inside a slice. A tool that assumes the two match will draw a shape that looks right and measures wrong. The import keeps the acquisition details, including the spacing along each axis, so a distance on screen is a real distance in millimetres.
We would still rather check your geometry with you than promise it works. Bring one series to the call and we will read the header together and say what we see.
- Arrives as
- DICOM, from your storage
- Kept on import
- spacing per axis, acquisition settings
- Measured in
- millimetres, from the header
- Read from
- your storage, by signed byte range
- Comes out as
- a release, with the log and hash chain
The cone-beam scans we test against
Forty-two walnuts were scanned on the FleX-ray cone-beam bench at Centrum Wiskunde en Informatica in Amsterdam, and published for machine-learning research. Each walnut was scanned on three orbits, so the group could reconstruct a clean reference volume to check less complete reconstructions against. The upload holds the raw projection images, the scanning geometry, the reconstruction scripts and the reconstructed volumes.
We use it as an acceptance set: a fixed pile of awkward real data that every change has to keep working on. Each walnut is about 6 GB, roughly 254 GB for the whole collection. Twenty-one of the forty-two archives are on our disk so far, each one checked byte for byte against the checksum published with it. The rest are not fetched yet.
We keep the archives zipped and pull a single slice out of one by asking for a byte range, without unpacking anything. That is exactly what the workspace does against your storage, which is why this collection is a fair test of it.
Cone-Beam X-Ray CT Data Collection Designed for Machine Learning, FleX-ray Lab, CWI. CC BY 4.0, doi:10.5281/zenodo.2686726, published across six records.
- Samples
- 42 walnuts
- Orbits per sample
- 3
- Detector
- 1536 by 1944, 14-bit
- On our disk
- 21 of 42 archives
- Checked by
- published MD5, byte for byte
- Licence
- CC BY 4.0
Not on this page. No picture on this site comes from the walnut collection. We hold it, we test against it, and we have not built a viewer for projection data, so showing you a walnut here would be a stage set. Every image on this site is from the Me 163 industrial CT volume or the QIN prostate MRI, both credited in the footer.
Formats and connections
| Topic | What it takes |
|---|---|
| Volumes in | DICOM, read from your own storage. The acquisition settings survive the import, and series stay lined up with each other. |
| What comes out | A release: one file with the label events in order, the people behind them and a hash chain. A reviewer of your paper can check it without your volumes. |
| Where the data sits | Your own S3-compatible storage. The browser reads the slice it needs through a signed read that expires. We keep an index and a hash. |
| Big volumes | A 512-slice study opens without waiting for the whole file. Bytes arrive as you need them, by range. |
| Who can write | People, models and agents each write inside limits you set, and the log names which one wrote. Read-only accounts are free and unlimited. |
| Citing it | A release names the data it came from and the label list in force, so a method section can point at one identifier rather than a folder. |
The worked example on this site
The CT on this site is the Fraunhofer EZRT XXL-CT scan of a Me 163 airframe section, subvolume V5, with the dataset's own instance labels. It is an industrial scan rather than a cone-beam one, and it is here because it is published, licensed and hard: hundreds of separate parts, thin sheet metal, and metal artefacts that make boundaries argue.
The three views below are cut through the same volume at right angles to each other, from a 256 cubed sample of it. The projection at the top of the page is that sample seen through, with the dataset's labels in colour. The sample holds 169 labelled parts; two of them wrap most of the scene, so the colour overlay leaves them out and the rest stay readable. The instance names are ours. The masks are the dataset's.
Fraunhofer EZRT XXL-CT Instance Segmentation Me 163, subvolume V5. CC BY 4.0, doi:10.5281/zenodo.10651746.
axial real scan 
coronal real scan 
sagittal real scan
- Source volume
- 512 slices
- In plane
- 0.33 mm
- Step
- 0.6 mm
- Sample shown
- 256 cubed
- Sample spacing
- 0.66 mm across, 1.2 mm through
- Labelled parts
- 169
- Licence
- CC BY 4.0
What we do not claim
There is no reconstruction in Nitsor. We do not turn projections into a volume, and we do not correct beam hardening, ring artefacts or scatter. Bring a reconstructed volume, or reconstruct with the tools you already use and bring the result.
We make no compliance claim, and we have no speed multiplier to sell. We have not measured how much faster a group labels with this than without it, so there is no number here.
There is no reconstruction, no scripting interface and no package you can install on your own cluster. If your group works from a Python pipeline, ask on the call what that means for you, and we will answer straight.