voXel DICOM conformance statement

Version 0.85.2, 30 September 2026.

This describes what voXel does with DICOM data. It follows the intent of PS3.2 rather than its full structure, because most of that structure describes network behaviour and voXel has none: it is a file reader with no association negotiation, no service classes and no connection to a PACS.

Read it alongside the scope, which says what the application is for and what it must not be used for.

Implementation model

voXel is a single application on iPadOS. It reads DICOM files that the user supplies from local storage, from an external drive, from a ZIP archive, or over a local network drop that the user starts themselves. It displays them. The only DICOM it writes is a 3D model the user exports as an Encapsulated STL instance; see What voXel writes.

There is no Application Entity, no AE Title, and no DIMSE. voXel is neither a Service Class User nor a Service Class Provider. It cannot be queried and it cannot query.

Networking

The only network feature is an optional drop server: a web listener the user starts on demand so a browser on the same network can send a folder to the iPad. It speaks HTTP, not DICOM. It is protected by a six digit pairing code and is off unless switched on. It serves HTTPS only, TLS 1.2 or later, with a certificate the iPad signs itself; the browser warns, and the sheet shows the certificate's fingerprint to check against. The connection is only as trustworthy as the reader's check of that fingerprint; without it, use the drop on a trusted home or office network, not a shared or public one.

No DICOMweb services are implemented. Neither QIDO-RS, WADO-RS nor STOW-RS is supported.

Media storage and file format

voXel reads files written to the DICOM File Format defined in PS3.10, with or without the 128 byte preamble. A file with neither preamble nor DICM marker is examined and read if the first element implies a recognised encoding; this accommodates exports that write a bare dataset.

Archives are unwrapped before reading: ZIP by container parsing and inflation, RAR 5 for stored entries only. Compressed RAR entries, 7z, xz, gzip, bzip2 and tar are identified by name and refused. An archive whose size fields do not add up is refused rather than trusted. A deflated dataset is inflated in one pass and refused past 512 MB.

Transfer syntaxes

A syntax marked No is identified by name and the file is refused. Pixel data is never partially decoded and never displayed as an approximation of itself.

Every decoder is written in Swift and is part of the application. None uses a third party library, and no codec is licensed, vendored or linked.

The lossless JPEG decoder implements ITU-T T.81 process 14: precision 2 to 16 bits, one to four components, all seven predictors, restart intervals and the point transform. It was verified sample for sample against an independent decoder on 500 clinical CT images before release.

The sequential JPEG decoder implements ITU-T T.81 processes 1, 2 and 4: baseline and extended Huffman coded DCT, precision 8 and 12 bits, one to four components, all four sampling factors seen in the corpus, restart intervals and the APP14 Adobe colour transform marker. Chroma that was subsampled is restored by bilinear interpolation on half pixel centres rather than by repetition, which is what the standard's own reconstruction implies and what keeps a subsampled image within 3 of 255 of an independent decoder. Full resolution files come back sample for sample identical. It was held against an independent decoder over the 24 baseline and extended objects in a public corpus before release.

The RLE decoder implements the PS3.5 Annex G byte run encoding: a per frame segment offset table, PackBits runs within each segment, and reassembly of one segment per sample per byte with the most significant byte first. Segment counts of 1, 2, 3, 4, 6 and 12 were exercised. Before release it was run over the 32 encoded objects in a public corpus, decoding 59 frames, each matching its expected length exactly.

SOP classes

voXel does not select by SOP Class UID. Any instance carrying Rows, Columns and decodable pixel data is displayed, which covers CT, MR, CR, DX, XA, MG, US, PT, NM, Secondary Capture and Enhanced multi-frame objects, subject to the pixel constraints below.

Instances with no pixel data are recognised and skipped rather than treated as errors. This includes Media Storage Directory (DICOMDIR), Structured Reporting objects, Presentation States, Registration, Segmentation and RT objects. None of their content is interpreted.

Pixel data

Grayscale pipeline

Stored values are transformed in the order PS3.4 defines.

Modality LUT is applied as Rescale Slope and Rescale Intercept. A Modality LUT Sequence is not applied.

VOI LUT is applied as Window Center and Window Width, honouring VOI LUT Function of LINEAR and LINEAR_EXACT. A VOI LUT Sequence is not applied. Where the file carries no window, one is computed from the image.

Presentation LUT is not applied. MONOCHROME1 is inverted for display.

The display is not calibrated to the Grayscale Standard Display Function of PS3.14, and no attempt is made to claim otherwise. This is the principal reason voXel is not for primary diagnostic interpretation.

Geometry

Slice ordering uses Image Position Patient projected onto the normal derived from Image Orientation Patient, so a stack sorts correctly regardless of instance numbering.

Measurements in millimetres require Pixel Spacing and Image Orientation Patient. Where either is absent, voXel declines to measure rather than assuming a scale.

Multiplanar reconstruction requires a consistent orientation across the series. Gantry tilt is corrected by carrying the in plane component of the inter-slice step. A series whose orientation is inconsistent, or whose obliquity exceeds sixty degrees, is refused for reconstruction with a stated reason.

Character sets

Text is decoded as UTF-8, with invalid bytes replaced. Specific Character Set is not honoured, so names in other character sets, such as accented Latin-1 (ISO_IR 100) or ISO 2022 IR 87, may not render correctly. Character set handling affects displayed text only and never pixel values or geometry.

Private data elements

Private elements are read, retained and shown in the tag inspector. None is interpreted. No private element affects display, geometry or measurement.

What voXel writes

One DICOM object: a 3D surface exported with Format set to DICOM, written as an Encapsulated STL instance.

It is written only from the series the model was built from. Because it carries the patient's name and identifiers, it is as identifying as the scan, and it files with the study in a PACS or another viewer.

Every other export is not DICOM. Images come out as PNG, JPEG, a notebook PDF, animated GIF or H.264 MP4, with any marks drawn in. Patient identifiers do not reach the exported image or its file name, but a name burned into the pixels, as on some ultrasound, stays. Surfaces come out as binary STL, Wavefront OBJ, 3MF or USDZ.

A surface file carries no DICOM elements, which is not the same as being anonymous: a skin-threshold reconstruction of a head study is a face. The STL header is the fixed string "voXel isosurface", with no patient, study or date in it. The application says as much where the export is offered.

Security and privacy

All processing is on device. There is no account, no backend and no analytics. Imported data remains in the application container until deleted by the user, under iOS data protection that keeps it unreadable while the iPad is locked. See the privacy policy.

Known limitations

Anything above marked No or refused is refused by name rather than approximated. Character set support is limited as described. This document describes version 0.85.2 and will change as the application does.