Copyright © 2024, Society of Motion Picture and Television Engineers. All rights reserved. No part of this material may be reproduced, by any means whatsoever, without the prior written permission of the Society of Motion Picture and Television Engineers.
The Society of Motion Picture and Television Engineers (SMPTE) is an internationally-recognized standards developing organization. Headquartered and incorporated in the United States of America, SMPTE has members in over 80 countries on six continents. SMPTE’s Engineering Documents, including Standards, Recommended Practices, and Engineering Guidelines, are prepared by SMPTE’s Technology Committees. Participation in these Committees is open to all with a bona fide interest in their work. SMPTE cooperates closely with other standards-developing organizations, including ISO, IEC and ITU. SMPTE Engineering Documents are drafted in accordance with the rules given in its Standards Operations Manual.
For more information, please visit www.smpte.org.At the time of publication no notice had been received by SMPTE claiming patent rights essential to the implementation of this Engineering Document. However, attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. SMPTE shall not be held responsible for identifying any or all such patent rights.
This document was prepared by Technology Committee 27C.
This clause is entirely informative and does not form an integral part of this Engineering Document.
Digital Cinema Distribution Master (DCDM) image essence is regularly exchanged between post-production facilities, typically using the constrained TIFF files specified at SMPTE RP 428-5. Such exchange is time-consuming and costly because of the size of these files – on the order of 10 TB for a motion picture. This document specifies a means of mapping DCDM images into packed images such that file size is reduced, while:
The resulting files that contained packed images, i.e., lossless JPEG 2000 codestreams, are not compatible with, and hence not a substitute for, the final lossy JPEG 2000 codestreams that will ultimately reside in the D-Cinema Package (DCP) that is distributed to theaters.
This document specifies a mapping of DCDM images, as specified in SMPTE ST 428-1, into mathematically lossless JPEG 2000 codestreams, each called a packed image.
Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.
All text in this document is, by default, normative, except: the Introduction, any clause explicitly labeled as "Informative" or individual paragraphs that start with "Note:"
The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.
The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated but not prohibited.
The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.
The keyword "reserved" indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword "forbidden" indicates "reserved" and in addition indicates that the provision will never be defined in the future.
A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described.
Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative prose shall be the authoritative definition; tables shall be next; then formal languages; then figures; and then any other language forms.
The following documents are referred to in the text in such a way that some or all of their content constitutes requirements of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
No terms and definitions are listed in this document.
A packed image is a single JPEG 2000 codestream that:
| Parameter | Value |
|---|---|
| Rcom | 1 |
| Ccomi | 53.4D.50.54.45.20.44.43.44.4D.20.58.27.59.27.5A 27.20.69.6D.61.67.65.20.61.73.20.64.65.66.69.6E 65.64.20.69.6E.20.53.4D.50.54.45.20.53.54.20.34 32.38.2D.31 |
NOTE 1 — The contents of the Ccomi bytes correspond to
the string SMPTE DCDM X'Y'Z' image as defined in SMPTE ST 428-1.
One COM marker that conforms to Table 1 should be present in the main header of the packed image.
RPCL progression order and Pcap15 = 1 should be used.
Annex A provides sample packed images.
NOTE 2 — Pcap15 = 1 specifies that the High-Throughput (HT) block coder defined in Rec. ITU-T T.814 | ISO/IEC 15444-15 is used. The HT block coder significantly improves encoding and decoding speeds.
NOTE 3 — The RPCL progression order allows decoding of images in throughput-limited and -varying environments with a single contiguous read operation of a partial codestream.
NOTE 4 — The constraints of SMPTE ST 428-1 narrow the constraints of SMPTE ST 2067-40. For example, XRsizi = YRsizi = 1 for all components.
A sequence of packed images can be stored as a sequence of files as follows.
Each file shall contain exactly one packed image.
All packed images in the sequence shall have identical image characteristics, as specified in SMPTE ST 428-1, but their encoding constraints, as specified in SMPTE ST 2067-40, may vary.
All files from one sequence shall be stored in one directory that contains files from no other sequence.
The file name of each file of the sequence shall conform to the following file-name syntax, expressed using the ABNF rules specified in IETF RFC 5234.
file-name = [sequence-name "."] frame-number suffix sequence-name = *(ALPHA / DIGIT / "_" / "-" / ".") frame-number = 1*%d49-57 suffix = ".pdc.j2c"
Your_Movie_R1_SCOPE.000192.pdc.j2c Your_Movie_R1_SCOPE.000193.pdc.j2c ... Your_Movie_R1_SCOPE.028223.pdc.j2c
The length of file-name in characters shall not be greater
than 128. The collection of frame-number values shall be an
integer sequence {n, n + 1, n + 2, …, n + N – 1} where N is the number of
images in the sequence and n can be any non-negative integer.
The length of frame-number in characters shall be identical
for all files in the sequence. Leading zeros can be used to satisfy this
requirement.
The sequence-name shall be identical for all files in the
sequence.
The sequence-name can contain post-production reel names and
abbreviations. When sorted in increasing order of frame-number,
the files shall be in the intended temporal display order.
NOTE 1 — frame-number can be used to represent an offset
in frames from the timecode 01:00:00:00. For example, a
frame-number value of 086400 can correspond to 01:00:00:00 at
24 frames per second, i.e., the “picture start” frame in the head leader for
reel 1.
NOTE 2 — This file naming convention is similar to that specified in SMPTE RP 428-5
NOTE 3 — The pdc token in the file name
suffix is intended to differentiate files containing packed
images from those containing lossy-coded frames intended to be wrapped into
a D-Cinema composition for distribution to theaters.
Each image sequence that comprises a post-production reel shall begin with a digital head leader that has a duration of eight seconds.
The digital leader specified in SMPTE RP 428-6 should be used.
Table 2 lists examples of digital leader durations.
| Frame rate (frames per second) | Digital leader duration (number of frames) |
|---|---|
| 24 | 192 |
| 25 | 200 |
| 30 | 240 |
| 48 | 384 |
| 50 | 400 |
| 60 | 480 |
When converting a TIFF file that conforms to SMPTE RP 428-5 to a packed image, only the most significant 12 bits of each 16-bit TIFF sample are used.
Conversely, when converting packed images to TIFF files that conform to SMPTE RP 428-5, each 12-bit packed image sample is padded into a 16-bit TIFF sample as specified in SMPTE RP 428-5.
Except for their respective suffixes, the filenames of the TIFF and packed image files can be identical.
Table A.1 lists sample files containing packed images generated by encoding Element a (a TIFF file) using commonly-available tools.
| Element b | Tool | https://kakadusoftware.com/documentation-downloads/ |
|---|---|---|
| Method of generation | kdu_compress -i $SRC_FILE -o $KDU_J2C Creversible=yes Corder=RPCL \
Cblk="{32,128}" Cmodes=HT ORGtparts=R Clevels=5 ORGgen_tlm=6 -fprec 12M \
Cprecincts="{256,256},{256,256},{256,256},{256,256},{256,256},{128,128}" \
-com "SMPTE DCDM X'Y'Z' image as defined in SMPTE ST 428-1" |
|
| Element c | Tool | https://github.com/aous72/OpenJPH |
| Method of generation | ojph_compress -i $SRC_FILE -o $OJPH_J2C -reversible true -prog_order RPCL \
-block_size "{128,32}" -num_decomps 5 -tlm_marker true \
-precincts "{128,128},{256,256}" -tileparts R -bit_depth 12 \
-com "SMPTE DCDM X'Y'Z' image as defined in SMPTE ST 428-1" |
The following are the non-prose elements of this document: