Universal Medical Film Format (UMF) — Prototype 1.0
Status: experimental draft. Not a recognized international standard, not DICOM, and not a diagnostic certification. The name, file extension and MIME type require collision and formal-registration checks before a standards claim. Important: the .umf extension has already been used for an unrelated MediaHolder Universal Media Format. An alternate extension and unique file signature should be evaluated before broad adoption.
Design goals
Portable original image preservation, separately labeled derived image, capture quality observations, transform history and integrity checking. Capture source is clearly distinguished from a native clinical imaging acquisition.
Container specification (implemented subset)
capture.umf [ZIP, uncompressed STORE entries]\n├── manifest.json\n├── original/capture-001.jpg (or png/webp/avif)\n├── normalized/film-001.png\n├── quality/quality-report.json\n├── processing/processing-history.json\n└── integrity/checksums.json
UTF-8 names and JSON, deterministic entry ordering, required 6 entries. No ZIP64, encryption, compression, nested folders beyond defined entries, symlinks or executable files. Prototype limits: up to 60 MiB per archive, 30 MiB per entry and 20 entries at reader boundary. File headers and SHA-256 digests are checked before data are rendered.
Manifest requirements
format = UMF; schema_version = 1.0.0-prototype; package_id = UUID; created_at = UTC ISO-8601 string; capture, medical_film, images, quality, processing, privacy, integrity, disclaimer objects. The writer currently produces one image-pair per package.
Integrity
SHA-256 digests cover manifest.json, original image, normalized image, quality report and processing history. checksums.json is excluded from the digest list to avoid a self-reference. The ZIP CRC-32 is independently verified during parsing. Checksums detect accidental or simple malicious alterations but are not digital signatures and cannot establish who captured a photo or whether the image is clinically trustworthy. The prototype has no chain-of-custody attestation or signing infrastructure.
Derived image
The original bytes are not altered; the optional rotation/brightness/contrast operations and memory-limited derived-image resizing are recorded. The derived copy is PNG with sRGB assumed, not hardware-measured. The screenshot may have camera-managed image processing. No anatomical reconstruction or calibrated pixel spacing is attempted.
Security and privacy
The reader rejects unknown archive structure, unsafe paths, unsupported compression, oversized entries, inconsistent ZIP headers, CRC mismatch, invalid hashes, and images with unrecognized signatures. Further hardening is necessary before processing arbitrary untrusted packages at scale. Identifiers visible within original photo pixels and metadata are not automatically de-identified. Original bytes may contain GPS EXIF data.
Interoperability roadmap
Future releases may add documented JSON Schema, test vectors, external reference implementation, robust viewer, DICOM Secondary Capture mapping, formal conformance validation and public governance. DICOM photographed film representation must never be labeled as original acquisition data.
Version governance
Current schema version is deliberately marked 1.0.0-prototype. No backward-compatibility guarantees have yet been established. This document describes the packaged demo implementation, not an externally approved standard.