Read the scans from your own storage. We never keep a copy.
A CT volume is too large to download whole, so nobody should try. The viewer asks your bucket for the bytes of the slice on screen, with a link you signed, and gets those bytes back. One view reads three byte ranges, about 0.6 per cent of the file. What we hold is an index and a fingerprint of the file, not the file.
- Scans go in as
- DICOM, part 10, uncompressed
- Where the scans live
- your S3-compatible bucket
- What we hold
- an index and a content hash
- One view reads
- 3 ranges, 1 572 864 bytes
- Of a 268 435 456 byte object
- 0.6 per cent
Which files open, and how far each one goes.
Most tools publish a list of format names. A name tells you nothing about whether the file opens, renders or comes back out. This sheet says how deep each one goes, in the same words the documentation uses. The product status page carries the formats that are still coming.
| Format | What it is | How far it goes |
|---|---|---|
| DICOM, part 10, uncompressed | What medical scanners write, and many industrial ones. | Registers from your bucket and the browser draws the slices. The technique settings that came with the file survive the import, so the record knows how the scan was taken and not only what it looks like. |
| VGI and VOL | Volume Graphics, common on industrial CT benches. | Registers, and there is a path to view it. |
| MRD | Raw magnetic resonance data, the ISMRM format. | Registers as raw. Nitsor says plainly that it cannot draw the file. |
| TIFF stacks and xtekct | Nikon and generic industrial CT output. | Register as raw. Nitsor says plainly that it cannot draw them. |
| NSI, REK, FLT, CB, SBM | Five more industrial CT vendor formats. | Register, and say plainly that they are not supported. |
One door to your bytes. It does not copy the file.
The diagram shows one registered object in your bucket, the three byte ranges a single view asks for, and how those bytes reach a browser. The browser signs a request for a range and your storage answers it. Nothing lands in ours.
- The object
- 268 435 456 bytes
- One slice
- 524 288 bytes
- One view
- 3 ranges, 0.6 per cent
- The read
- signed, straight from you
The browser asks your bucket for bytes=100663296-101187583 with a signed link and gets 206 Partial Content back. The link is short-lived. Your storage decides whether to answer it, and it answers the browser, not us.
What comes out, and who can read it
A release is one JSON file. It lists the label events in order, names the person or model behind each one and the person who accepted it, and chains the entries with SHA-256 so each entry commits to the one before it.
Your auditor needs nothing from us
They check the chain on their own machine, with no account here and no access to your storage. The file names no pixels, so you can hand it to a customer who must never see the scans.
Your record leaves when you do
Export is complete and unconditional. It does not depend on your still being a customer, and the history is never a paid extra.
Nothing is quietly dropped
Rejected work is an entry, not a deletion. A release that shows an argument and how it was settled is worth more six months later than one that shows only the winner.
What you get
A shorter security review
The question becomes who can read your bucket, not whose cloud holds a second copy of your patients or your parts.
A viewer that opens on the slice
The browser asks for the bytes on screen. A 512-slice series does not have to finish downloading before you can draw on it.
One identity, swapped not rebuilt
Sign-in is provider-neutral, so moving from one identity provider to another is a configuration change rather than a project.
A scan that changed gets caught
We hash each file when we index it. A file that has moved underneath you is reported, not quietly shown, which is the difference between finding out now and finding out three months later.
Where a byte can still land
Viewing, validating and converting can need temporary copies. Source data staying in place does not mean no byte is ever read or processed, and any vendor who tells you otherwise is rounding off in their own favour.
So here is the shape of it. If somebody took our whole database and none of your storage, they would have a list of file paths, a column of checksums, and a set of outlines in millimetres with names attached. We are not going to tell you that is nothing. It is not nothing. It is also not your scans.
Ask us for the configuration, network and storage records before you rely on any of this, and we will show you what exists.