DICOM-Shaped Part 10 File — Explicit VR, Synthetic Phantom (.bin)
A DICOM Part 10 file built byte by byte: 128-byte preamble, the DICM magic, an explicit-VR file meta group and a 27-element dataset ending in 16-bit pixel data. Every identifier is invented: the patient name is SYNTHETIC^PHANTOM, the instance UIDs sit under the unregistered 2.25 UUID arc, and the pixels are a generated pattern. There is no protected health information here and nothing in the file refers to a real person, device or study.
| Offset | Contents | Notes |
|---|---|---|
| 0 | 128 zero bytes | the Part 10 preamble, ignored by readers |
| 128 | 'DICM' | the magic that identifies a Part 10 file |
| 132 | group 0002 file meta | always explicit VR LE, whatever the dataset uses |
| after meta | dataset, explicit VR LE | 27 elements in ascending tag order |
| (7FE0,0010) | OW, 2048 bytes | 32x32 unsigned 16-bit pixels |
Specifications
- Layout
- DICOM PS3.10 Part 10
- Preamble Bytes
- 128
- Magic
- DICM at offset 128
- Transfer Syntax
- 1.2.840.10008.1.2.1
- Transfer Syntax Name
- Explicit VR Little Endian
- Rows
- 32
- Columns
- 32
- Bits Allocated
- 16
- Bits Stored
- 12
- Photometric
- MONOCHROME2
- Uid Root
- 2.25.329800735698586629295641978511506172918
- Contains PHI
- false
- Extension Note
- identical bytes; rename to .dcm for viewers that gate on the suffix
Testing contract
Expected to pass- Scenario
- Parse the preamble and file meta group, read the transfer syntax, then decode the dataset and pixel data.
- Expected result
- DICM appears at offset 128, the transfer syntax reads 1.2.840.10008.1.2.1, the dataset holds 27 elements in ascending tag order, and PixelData decodes to a 32x32 unsigned 16-bit image.
What is a .bin file?
A .bin file is a generic binary blob with no specific format — raw bytes whose meaning depends entirely on the producing application (firmware images, memory dumps, serialized payloads). The extension signals only 'not text.'
How to use this file
Use an example .bin file to test binary/hex viewers, file-type sniffing, octet-stream handling, and download pipelines that must not corrupt arbitrary bytes.
How to use this file for testing
“DICOM-Shaped Part 10 File — Explicit VR, Synthetic Phantom (.bin)” is a deterministic Novus Examples fixture for Scientific data, Serialization testing. Citation catalogs (BibTeX, RIS), chemistry structures (MDL Molfile, PDB), and gridded binary data (NetCDF, FITS) — for testing reference managers, molecule viewers, and scientific-data loaders.
Documented properties for this file: 32 rows · 32 columns. Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Scientific fixtures are small, valid, and fully synthetic — no real organism, patient, sample, or observation. Point your parser or loader at the file and check it reads the documented records, variables, or headers; binary formats ship a readable twin or metadata listing for comparison.
Related files
- fitsFITS BINTABLE — Typed Columns with TUNIT (.fits)A FITS binary table with four typed columns, big-endian numerics packed with no inter-field padding and TUNIT declaring milli-jansky on the two flux columns. It is the fixture for a table reader that has to build a row struct from TFORM codes rather than guess widths.

- fitsFITS BLANK — Undefined Integer Pixels (.fits)Integer FITS images mark undefined pixels with the BLANK keyword, and BLANK is compared against the stored value before BZERO and BSCALE are applied. Scale first and the four undefined pixels turn into a perfectly plausible zero, which is the ordering bug this file exists to expose.

- fitsFITS Header-Only — Valid File With No Pixels (.fits)A completely valid FITS file consisting of one 2880-byte header block and no data unit, which the standard permits whenever NAXIS is 0. It separates readers that model the data array as optional from readers that treat 'no pixels' as corruption.

- fitsFITS Image — BITPIX 16 with BZERO Unsigned Trick (.fits)FITS has no unsigned 16-bit type, so unsigned data is stored signed with BZERO = 32768 and recovered as BZERO + BSCALE * stored. Every stored value in this image is negative, so a reader that ignores the scaling returns an entirely negative frame while parsing the file perfectly.

- fitsFITS Image — BITPIX 8 Unsigned Bytes (.fits)The baseline rung of the BITPIX ladder: a 24x16 synthetic star field stored as unsigned bytes, the one integer width FITS holds without a BZERO shift. Every image in this family carries the same scene so a decoder can be scored across data types.

- fitsFITS Image — float32 with NaN and Inf Pixels (.fits)Single-precision FITS pixels including two NaNs, which is the only way the standard marks undefined data for floating BITPIX, plus one +Inf. Statistics computed without NaN-aware reductions come back as NaN for the entire frame.

Generated by generation/scientific.py. Free for any use, no attribution required — license.