--- title: "OME-TIFF for Microscopy AI: Which Stored Plane Is the Requested Image?" description: "Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21." canonical: "https://www.leviathansystems.co/articles/microscopy-ai-ome-tiff-plane-axis-mapping" last-updated: "2026-10-21" --- # OME-TIFF for Microscopy AI: Which Stored Plane Is the Requested Image? Leviathan Systems — Technical content Published 2026-10-21; updated 2026-10-21. An OME-TIFF image's dimensions do not uniquely identify the stored plane for a requested Z position, time point and channel. DimensionOrder supplies a default order, while TiffData can explicitly assign planes. In the fictional case below, the same Z0–T1–C2 request selects IFD 10 in one valid default ordering and IFD 5 in another. Resolve that mapping before treating an equal-shaped image as the required AI input. ## Separate plane identity from image shape A microscopy-AI consumer can receive a complete 512 × 512 image while still receiving the wrong channel or time point. Equal dimensions answer how many positions the plane contains. They do not identify which acquisition coordinates those positions represent. The OME Data Model and File Formats 6.3.1 documentation describes OME-TIFF as TIFF pixel storage accompanied by OME-XML metadata. TiffData connects stored IFDs to image-plane coordinates. Its DimensionOrder discussion supplies the default rasterization order; explicit mappings can change the correspondence. This is a representation decision for a supplied scientific input. It does not establish an instrument's acquisition accuracy, image quality, biological finding or AI performance. The related DICOM geometry article concerns physical patient-coordinate mapping, and the GeoTIFF article concerns resolution and spatial windows. Here the unresolved choice is which member of a multi-axis microscopy image population reaches the consumer. References: [OT](https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/specification.html) ## OME-P37: 12 scalar planes, each 512 × 512 Stipulate one fictional image series with SizeX = 512, SizeY = 512, SizeZ = 2, SizeC = 3 and SizeT = 2. It has three separate scalar channels, each with one sample per pixel, and one full-resolution plane for every Z/T/C combination. Each sample is an unsigned 16-bit value. There are no pyramidal sub-resolutions, RGB packing or additional image series in this case. The plane population is 2 × 3 × 2 = 12. Each plane contains 512 × 512 = 262,144 samples. Counting two bytes per stipulated sample gives 524,288 bytes, or 0.5 MiB, of unpacked sample payload per plane. Twelve such planes contain 6,291,456 bytes, or 6 MiB. Those numbers omit TIFF directories, metadata, compression and every other file overhead. They are neither an encoded file size nor a transfer, decoder-buffer or GPU-memory measurement. Two offers with this same sample population can have different file sizes and access behavior. The one-sample-per-channel premise matters. OME's 2016-06 schema distinguishes logical channels and sample components, including RGB cases. The simple 12-plane accounting must not be generalized to every image merely because SizeC equals three. References: [OS](https://github.com/ome/ome-model/blob/v6.3.1/specification/src/main/resources/released-schema/2016-06/ome.xsd) ## Trace the requested Z0–T1–C2 plane in two default orders Offer A uses DimensionOrder XYZTC and the ordinary default TiffData mapping, beginning at IFD 0 with Z0–T0–C0. For OME-P37, Z changes fastest, then T, then C. Its zero-based IFD index is z + 2t + 4c. The requested z = 0, t = 1, c = 2 therefore selects 0 + 2 + 8 = IFD 10. Offer B uses the same dimensions and complete scalar population but default XYCTZ ordering. C changes fastest, then T, then Z. Its index is c + 3t + 6z. The same request selects 2 + 3 + 0 = IFD 5. Both offers can represent the requested image correctly. Their physical plane order differs. Reading IFD 5 from A just because B used index 5 would instead select Z1–T0–C1 in A. The mistaken read would still return an image of the expected dimensions and sample type. These formulas follow the stipulated sizes and default mappings. They are not universal byte-offset formulas, and an IFD number is not a file-byte offset. No file was created or read for this example. References: [OT](https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/specification.html) OME-P37: selected default mappings for the same 12-plane image population | Z/T/C request | Offer A: XYZTC IFD | Offer B: XYCTZ IFD | Same requested identity? | Source | | --- | --- | --- | --- | --- | | Z0–T0–C0 | 0 | 0 | Yes, under the stated mappings | Planning analysis | | Z1–T0–C0 | 1 | 6 | Yes; storage indices differ | Planning analysis | | Z0–T1–C2 | 10 | 5 | Yes; this is the selected input | Planning analysis | | Z1–T0–C1 | 5 | 7 | Yes; A's IFD 5 is not the selected input | Planning analysis | Original arithmetic for one scalar, full-resolution series with default mappings. A rendered preview with the right dimensions does not establish its Z/T/C identity. ## Explicit TiffData can change the default correspondence The OME-TIFF specification also defines zero-based IFD, FirstZ, FirstT and FirstC assignments, with PlaneCount controlling the mapped extent. Its reverse-time example deliberately assigns stored planes in a different order from the default. A consumer therefore needs the actual mapping, rather than only the DimensionOrder label. For a separate illustrative mapping, an entry naming IFD 0, FirstZ 0, FirstT 1, FirstC 2 and PlaneCount 1 assigns that IFD to OME-P37's selected coordinate. Under that explicit assignment, assuming the default IFD 10 would fail to follow the supplied mapping. That single entry establishes only one correspondence. It does not prove that the other 11 requested planes have mappings, that referenced pixels are readable or that assignments are free of conflicts. A claim to deliver all 12 coordinates needs the complete applicable mapping and corresponding contents. Changing a metadata label alone is not evidence that a provider delivered a different acquired image. OME-TIFF can also distribute a dataset across files identified through UUID references. The number of files is then a different quantity from the number of plane coordinates. OME-P37's calculation does not assume that one filename is a complete delivery. References: [OT](https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/specification.html) ## Channel and time indices need acquisition meaning Correctly selecting Z0–T1–C2 resolves one address relationship. It does not supply the meaning of channel C2, elapsed time at T1 or physical separation along Z. Those are different questions from storage order. The version-pinned OME 2016-06 schema describes per-plane TheZ, TheT and TheC as zero-based indices. Its optional DeltaT expresses time since the experiment began, with an associated unit; TimeIncrement supports a global timing description. PhysicalSizeX/Y/Z and their units describe physical sample size. Those declarations are distinct from the dimension counts. For example, stipulate that the selected plane has DeltaT = 7.5 seconds. T1 now identifies the second indexed time point while the supplied timing describes 7.5 seconds. Replacing that with an assumed one-second timestamp would change the interpretation without changing the selected IFD or pixel values. Absence of the timing declaration would not justify either number. Similarly, the label C2 does not establish a particular stain or wavelength. The provider needs to preserve the channel identity required by the application. Even complete representation metadata is a declaration whose scientific applicability needs the responsible specialist's evidence. References: [OS](https://github.com/ome/ome-model/blob/v6.3.1/specification/src/main/resources/released-schema/2016-06/ome.xsd) ## Judge the selected input at the consumer boundary Suppose the buyer requests OME-P37's full-resolution Z0–T1–C2 plane together with its channel identity and acquisition timing. Offer A can supply it from IFD 10; offer B can supply it from IFD 5. Equal encoded order is unnecessary if each delivered return correctly preserves the requested identity. Conversely, an offer returning A's IFD 5 while labeling it Z0–T1–C2 has not answered the request merely because the resulting image is 512 × 512. The wrong member of the series can pass a shape and unpacked-byte count comparison. A derived tensor need not retain TIFF directories verbatim. It does need a supported correspondence between its delivered axes and the selected source planes, including any declared channel selection, crop, resampling or value transformation applicable to the task. Ask the appointed provider to explain that correspondence for the actual returned input, rather than accepting a correct-looking preview as its substitute. OME-P37 supplies no claim about signal quality, valid observations, calibration, patient use or model accuracy. It also supplies no throughput ratio from the 6 MiB payload arithmetic. The purchase decision resolved here is whether the proposed return preserves the required image population and identity. ## Scope a separate physical equipment installation When the chosen scientific-computing equipment needs physical installation, the existing Rack-and-Stack & Colocation Installation service is a route to discuss agreed mounting, IT connections, labeling and installation records. Share a nonconfidential equipment, rack, site and connection outline to establish scope and availability. Microscopy data interpretation, reader integration and model acceptance remain with the appointed scientific and software providers. The physical installation inquiry does not imply an imaging or data-engineering service. ## Primary sources - [OT — OME Data Model and File Formats 6.3.1: OME-TIFF specification](https://docs.openmicroscopy.org/ome-model/6.3.1/ome-tiff/specification.html). Checked 2026-10-20. DimensionOrder, default and explicit TiffData assignments, zero-based indices/PlaneCount, multi-file UUID references and separate sub-resolution rules. OME-P37 is an original scalar, full-resolution example, not a file-validation or decoder result. - [OS — OME Model v6.3.1: released OME 2016-06 schema, Pixels/Plane/Channel definitions](https://github.com/ome/ome-model/blob/v6.3.1/specification/src/main/resources/released-schema/2016-06/ome.xsd). Checked 2026-10-20. Version-pinned official schema source: dimension counts, physical sizes/units, zero-based plane coordinates, timing declarations and channel/sample-component distinction. Optional metadata is not imputed when absent. ## Related Leviathan resources - [DICOM array indices and physical patient coordinates](/articles/healthcare-ai-dicom-pixel-index-patient-geometry) - [GeoTIFF sample resolution and storage tiles](/articles/geospatial-ai-cog-overview-resolution-window-tiles) - [HDF5 logical arrays and external source dependencies](/articles/scientific-ai-hdf5-virtual-dataset-source-values) - [Rack-and-stack physical installation scope](/services/rack-and-stack) ## Does the scientific-computing equipment need installation? Share a nonconfidential equipment, rack, site and IT connection outline to discuss a separate physical installation and handoff scope. [Discuss the scope](/contact?service=rack-and-stack&from=/articles/microscopy-ai-ome-tiff-plane-axis-mapping)