SIST ISO 15740:2014
Photography - Electronic still picture imaging - Picture transfer protocol (PTP) for digital still photography devices
Photography - Electronic still picture imaging - Picture transfer protocol (PTP) for digital still photography devices
ISO 15740:2013 provides a common communication protocol for exchanging images with and between digital still photography devices (DSPDs). This includes communication between DSPDs and host computers, printers, other digital still devices, telecommunications kiosks and image storage and display devices.
This protocol is transport- and platform-independent.
Photographie - Imagerie des prises de vue électroniques - Protocole de transfert d'images (PTP) pour les appareils photographiques électroniques numériques
Fotografija - Digitalno upodabljanje mirujočih slik - Protokol za prenašanje slik pri fotografskih napravah za mirujoče slike (PTP)
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
01-marec-2014
1DGRPHãþD
SIST ISO 15740:2011
)RWRJUDILMD'LJLWDOQRXSRGDEOMDQMHPLUXMRþLKVOLN3URWRNRO]DSUHQDãDQMHVOLNSUL
IRWRJUDIVNLKQDSUDYDK]DPLUXMRþHVOLNH 373
Photography - Electronic still picture imaging - Picture transfer protocol (PTP) for digital
still photography devices
Photographie - Imagerie des prises de vue électroniques - Protocole de transfert
d'images (PTP) pour les appareils photographiques électroniques numériques
Ta slovenski standard je istoveten z: ISO 15740:2013
ICS:
37.040.99 Drugi standardi v zvezi s Other standards related to
fotografijo photography
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
INTERNATIONAL ISO
STANDARD 15740
Third edition
2013-09-15
Photography — Electronic still
picture imaging — Picture transfer
protocol (PTP) for digital still
photography devices
Photographie — Imagerie des prises de vue électroniques —
Protocole de transfert d’images (PTP) pour les appareils
photographiques électroniques numériques
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Digital still photography device model . 5
4.1 Overview . 5
4.2 Baseline requirements . 6
5 Data format specification . 6
5.1 General format . 6
5.2 Data types . 7
5.3 Simple types . 9
5.4 Arrays .11
5.5 Data sets . .12
6 Image and data object formats .21
6.1 Object usage .21
6.2 Thumbnail formats .22
6.3 ObjectFormatCodes .23
6.4 Object format version identification .23
6.5 Data object association .24
7 Transport requirements .26
7.1 Disconnection events.26
7.2 Reliable, error-free channel .27
7.3 Asynchronous event support .27
7.4 Device discovery and enumeration .27
7.5 Specific transports .27
8 Persistent storage .27
8.1 StorageID .27
8.2 Data object referencing .28
8.3 Receiver object placement .29
9 Communication protocol .30
9.1 Device roles .30
9.2 Sessions .30
9.3 Transactions .30
9.4 Operation flow .33
9.5 Vendor extensions .33
10 Operations .35
10.1 Operation overview .35
10.2 Operation parameters .35
10.3 OperationCode format .35
10.4 OperationCode summary .35
10.5 Operation descriptions .35
11 Responses .60
11.1 ResponseCode format .60
11.2 ResponseCode summary .60
11.3 Response descriptions .61
12 Events
............................................................................................................................................................................................................................66
12.1 Event usage .66
12.2 Event types .66
12.3 Event data set .66
12.4 EventCode format .67
12.5 EventCode summary .67
12.6 Event descriptions .67
13 Device properties .71
13.1 Device property usage .71
13.2 Values of a device property .71
13.3 Device property management requirements .72
13.4 Device property identification .72
13.5 Device property descriptions .76
14 Streaming (PTP v1.1 only) .92
14.1 Streaming overview .92
14.2 Stream transfer .92
14.3 Multiplexing .92
14.4 Discovering and configuring stream capabilities .93
14.5 Data transfer mechanism .93
14.6 Packet layout .94
14.7 Frame layout .95
14.8 Enumerating supported streams .95
14.9 Retrieving stream information.95
15 Conformance section .95
Annex A (informative) Optional device features .98
Annex B (normative) Object referencing and format codes .100
Annex C (informative) Operation flow example scenarios .102
Annex D (informative) Filesystem implementation examples .106
Annex E (informative) Reference to OSI model .109
Annex F (informative) SendObject implementation example .112
Bibliography .115
iv © ISO 2013 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
The committee responsible for this document is ISO/TC 42, Photography.
This third edition cancels and replaces the second edition (ISO 15740:2008), of which it constitutes a
minor revision with the following changes:
— as the vendor extension ID registry formerly maintained by the I3A has been transferred to another
organization, term 3.21 (I3A) was removed and the remaining terms renumbered;
— in 9.5.1, the fourth and fifth sentences were amended and combined to reflect that a new organization
assigns and maintains VendorExtensionIDs.
Introduction
This third edition of ISO 15740 (hereinafter designated PTP v1.1) provides optional support for new
increased performance and compatibility. All new constructs are fully backward compatible with the
first edition (hereinafter designated PTP v1.0) and are optional. See 5.5.2 for standard version.
For the purposes of this International Standard, digital still photography devices (DSPDs) are defined
as devices with persistent storage which capture a digital two-dimensional image at a discrete point in
time. Most DSPDs include interfaces that can be used to connect to a host computer or other imaging
device, such as a printer. A number of high speed interface transports has been developed, including
USB, TCP/IP and IEEE 1394 (FireWire). This International Standard is designed to provide requirements
for communicating with DSPDs. This includes communications with any type of device, including
host computers, direct printers and other DSPDs over a suitable transport. The requirements include
standard image referencing behaviour, operations, responses, events, device properties, data sets and
data formats to ensure interoperability. This International Standard also provides optional operations
and formats, as well as extension mechanisms.
This International Standard specifies the following:
— behaviour requirements for DSPDs; this includes the baseline features a device needs to support in
order to provide interoperability over conforming transports;
— functional requirements needed by a transport to facilitate the creation of a transport-dependent
implementation specification that conforms to this International Standard;
— a high-level protocol for communicating with and between DSPDs consisting of operation, data and
response phases;
— sets of suggested data codes and their usages including
— OperationCodes,
— ResponseCodes,
— ObjectFormatCodes,
— DevicePropCodes,
— EventCodes,
— required data sets and their usages,
— a means of describing data object associations and filesystems and
— mechanisms for implementing extensibility.
This International Standard does not attempt to define any of the following:
— any sort of device discovery, enumeration or transport aggregation methods; implementation of this
functionality is left to the transports and the platforms upon which support for this International
Standard is implemented;
— an application programming interface; this is left to the platforms upon which support for this
International Standard is implemented.
This International Standard has been designed to appropriately support popular image formats used in
[15]
digital still cameras, including the Exif and TIFF/EP formats defined in ISO 12234-1 and ISO 12234-2,
as well as the Design Rule for Camera Filesystem (DCF) and the Digital Print Order Format (DPOF).
The technical content of this International Standard is closely related to PIMA 15740:2000. The main
difference is that PIMA 15740:2000 includes an informative annex describing a USB implementation of
vi © ISO 2013 – All rights reserved
ISO 15740. This information is not included in this International Standard, which instead references the
USB still device class document developed by the Device Working Group of the USB Implementers Forum.
PTP v1.1 provides optional support for new increased performance and compatibility. All new constructs
are fully backward compatible with PTP v1.0 and are optional.
— Performance Enhancements:
— Support for retrieval of ObjectHandles in enumerated chunks, via specification of three new
optional operations and a new response code. This may reduce long response times for some
initiators that possess large numbers of objects.
— Support for optional arbitrary resizing prior to image transmission via specification of a new
operation GetResizedImageObject. In PTP v1.0, image sizes might be requested in full-resolution
or thumbnail size only.
— Support for arrays of data sets. This can be used to reduce the number of required transactions
necessary for device characterization from being a function of the number of objects on the
device to one.
— An optional fast file characterization operation called GetFilesystemManifest that exploits data
set arrays to request, in a single transaction, only the minimum data required to characterize
a typical filesystem. Many initiators, particularly in printing scenarios, are interested in fast
filesystem characterization for access to a specifically named file in a particular place. This
capability can significantly improve end-user workflow latency. This single operation replaces
the typical series of many GetObjectInfo requests with a binary filesystem manifest. This
manifest is defined as a simple array of a subset of the standard ObjectInfo data set called the
ObjectFilesystemInfo data set. This operation replaces the need for many GetObjectInfo calls,
while also avoiding the need for responders to perform many internal file-opens on the fly, or
to cache ObjectInfo image data that is often held persistently only “inside” internal image files
(e.g. TIFF tags inside EXIF JPEGs), to quickly communicate only the fast filesystem information.
— Compatibility Enhancements:
— An optional mechanism to support multiple vendor extension sets. This is specified via the new
VendorExtensionMap data set, and two new optional operations that may be invoked outside of
a session (GetVendorExtensionMaps and GetVendorDeviceInfo).
— The optional fast file characterization method GetFilesystemManifest natively supports
extremely large objects, by requiring 8-bytes for object size (UINT64), as opposed to the
standard 4-bytes.
— A new standard ObjectFormatCode to support the Digital Negative file format (DNG).
— Feature Enhancement:
— An optional mechanism for handling streaming content. This is specified via the new StreamInfo
data set, as well as the supporting GetStreamInfo and GetStream operations, as well as some
optional new supporting DeviceProperties. This is described in a new Clause 14.
INTERNATIONAL STANDARD ISO 15740:2013(E)
Photography — Electronic still picture imaging — Picture
transfer protocol (PTP) for digital still photography devices
1 Scope
This International Standard provides a common communication protocol for exchanging images with
and between digital still photography devices (DSPDs). This includes communication between DSPDs
and host computers, printers, other digital still devices, telecommunications kiosks and image storage
and display devices.
This protocol is transport- and platform-independent.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO 12234-2, Electronic still-picture imaging — Removable memory — Part 2: TIFF/EP image data format
ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS)
ISO/IEC 10918-1:1994, Information technology — Digital compression and coding of continuous-tone still
images: Requirements and guidelines
IEC 61966-2-1, Multimedia systems and equipment — Colour measurement and management — Part 2-1:
Colour management — Default RGB colour space — sRGB
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
album
end-user-created object used to logically group data objects according to some user-defined criteria
Note 1 to entry: An album might or might not be a physical folder in a filesystem. In this International Standard,
an album is a type of association.
3.2
association
logical construct used to expose a relationship between discrete objects
Note 1 to entry: Associations are used to indicate that separate data objects are related. Associations are
represented like folders, and can be nested using a standard branched hierarchical tree structure.
EXAMPLE A time sequence, or user-defined groupings by content or capture session.
3.3
connection
transport-provided mechanism for establishing paths for transferring data between devices
3.4
datacode
16-bit unsigned integer whose Most Significant Nibble (4 bits) is used to indicate the category of code
and whether the code value is standard or vendor-extended
3.5
data object
image or other type of data that typically exists in persistent storage of a DSPD or other device
3.6
dataset
transport-independent collection of one or more individual data items with known interpretations
Note 1 to entry: Data sets are not necessarily opaque nor atomic to transport implementations.
3.7
Design Rule for Camera Filesystem
DCF
standard convention for camera filesystems which specifies the file format, foldering and naming
conventions in order to promote file interoperability between conforming digital photography devices
3.8
device discovery
act of determining the set of all devices present on a particular transport or platform that are physically
or logically accessible
3.9
digital still photography device
DSPD
device with persistent storage which captures a two-dimensional digital still image
3.10
Digital Print Order Format
DPOF
standardized ASCII file stored on removable media along with the image files that indicates how many
copies of which images should be printed
Note 1 to entry: DPOF also allows index prints, cropping, and text overlays to be specified.
3.11
enumeration
act of creating an ordered increasing numerical list that contains one representative element for each
member of a set
3.12
Exif/JPEG
compressed file format for digital cameras in which the images are compressed using the baseline JPEG
standard described in ISO 12234-2
Note 1 to entry: In Exif, metadata and thumbnail images are stored using TIFF tags within an application segment
at the beginning of the JPEG file.
3.13
folder
optional sub-structure in a hierarchical storage area that can contain data objects
2 © ISO 2013 – All rights reserved
3.14
FlashPix
image file format, defined in FlashPix Format Specification, using a structured storage file containing
metadata and a tiled, hierarchical image representation
Note 1 to entry: The tiles in a FlashPix image are normally baseline JPEG images, and individual image tiles of a
particular resolution can be easily accessed for rapid display and editing.
3.15
IEEE 1394
high-speed serial bus standardized by the IEEE (Institute of Electrical and Electronics Engineers)
currently having clock rates of 100, 200 and 400 Mbits/s
Note 1 to entry: IEEE 1394 is often referred to as FireWire.
3.16
image aspect ratio
ratio of the image width to the image height
3.17
image capture device
device for converting a scene or a fixed image, such as a print, film or transparency, to digital image data
3.18
image output device
device that can render a digital image to hardcopy or softcopy media
3.19
in-band event
event transmitted on the same logical connection as operations and responses
Note 1 to entry: Events are only asynchronous to the degree of data precision for which the transport
implementation allows event interleaving.
3.20
initiator
device that initiates a conversation by opening a session, and issues all formal operations to the responder
Note 1 to entry: The initiator is analogous to the client in the client/server paradigm.
3.21
Infrared Data Association
IrDA
infrared wireless communication system that currently supports wireless communication at data rates
between 9 600 bps and 4 Mbps
3.22
Joint Photographic Experts Group
JPEG
specific image compression method defined in ISO/IEC 10918-1
3.23
LogicalStorageID
least significant sixteen bits of a StorageID
Note 1 to entry: This value uniquely identifies one logical storage area within the physical store indicated in the
PhysicalStorageID.
3.24
Most Significant Nibble
MSN
most significant four bits of the most significant byte
3.25
object aggregation
act of taking one or more location-specific lists of objects that exist on a particular device and grouping
them together in one set
3.26
ObjectHandle
device-unique 32-bit unsigned integer assigned by a device to each data object in local persistent storage
which is provided to external devices
Note 1 to entry: External recipients of an ObjectHandle must use it to reference that piece of data in subsequent
transactions. ObjectHandles are guaranteed to be persistent over at least a session.
3.27
out-of-band event
event transmitted on a different logical connection to that for operations and responses
Note 1 to entry: Out-of-band events are asynchronous from operation transactions.
3.28
personal computer
PC
any personal computing device, which may employ various hardware architectures and operating systems
3.29
PhysicalStorageID
most significant sixteen bits of a StorageID
Note 1 to entry: This value uniquely identifies one physical storage area on a device, although there may be more
than one logical store per physical store.
3.30
Portable Network Graphics
PNG
extensible file format for lossless, portable, compressed storage of raster images
Note 1 to entry: PNG supports indexed colour, greyscale, truecolour and an optional alpha channel.
3.31
protocol
defined mechanisms for exchanging data between devices
3.32
pull model
use paradigm for DSPDs where the object receiver initiates the operation requests to transfer data
objects from the sender
3.33
push model
use paradigm for DSPDs where the object sender initiates the operation requests to transfer data objects
to the receiver
3.34
QuickDraw picture
file format consisting of sequences of saved drawing commands
Note 1 to entry: QuickDraw files are commonly referred to as PICT files.
4 © ISO 2013 – All rights reserved
3.35
responder
device that responds to operations from the initiator
Note 1 to entry: The responder is analogous to a server in the client/server paradigm.
3.36
session
logical connection between two devices defining a period of time during which obtained state
information, such as handle persistence, may be relied upon
3.37
square pixel sampling
image having equal sample spacing in the two orthogonal sampling directions
3.38
StorageID
device-specific four-byte unsigned integer (UINT32) that represents a unique storage area that may
contain data objects
Note 1 to entry: The most significant 16 bits of a StorageID represent the PhysicalStorageID, while the least
significant 16 bits of a StorageID represent the LogicalStorageID.
3.39
transport aggregation
act of taking one or more transport-specific list of conforming devices that are logically or physically
accessible in a system and grouping them in one set that spans all transports across the particular system
3.40
transport
means of attaching the digital capture device to some other digital device including a physical wire or a
wireless connection
3.41
Universal Serial Bus
USB
digital interface for connecting up to 127 devices in a tiered-star topology
4 Digital still photography device model
4.1 Overview
Digital still photography devices (DSPDs) are used to acquire digitally encoded still images. These
devices include a persistent storage capability so that any digital images and other data acquired by the
device are preserved across power cycle operations unless they are specifically deleted.
A DSPD might support many different features. This International Standard supports devices with
a wide range of potential features. However, a small number of features is required for conformance
with this International Standard, while many others are optional. Subclause 4.2 describes the required
features and functionality. Annex A describes features that are not required for conformance but which
should be implementable using this International Standard and its extension mechanisms.
Standard data formats for datatypes and data sets are described in Clause 5.
Clause 6 describes required and optional support for particular image and non-image formats and
metadata. Clause 6 also describes methods for associating data objects.
A particular feature set places requirements on the transports used to connect the DSPD to other
devices. Clause 7 describes these requirements.
All DSPDs must store images in some form of storage area. Clause 8 describes the usage of these stores,
as well as the methods for referencing them.
Clause 9 describes the roles of devices, sessions and transactions that transports are required to use
in order to communicate with and/or between DSPDs. Clause 10 lists the standard operations, their
corresponding optional operation codes and their usages. Standard responses to operations are defined
in Clause 11. The use of events is mandatory in order to ensure synchronization between devices.
Clause 12 describes events and their usages.
In order to expose device controls and manipulate properties in a common way, a standard set of device
properties and their usages have been defined in Clause 13.
Clause 15 serves as a summary of the individual operations and events that are required to be supported
by particular devices, as well as a checklist that can be used by implementers.
4.2 Baseline requirements
4.2.1 General
The requirements listed in 4.2.2 to 4.2.5 shall be met in order for a DSPD to conform to this
International Standard.
4.2.2 Implementation of a suitable transport
The DSPD shall provide appropriate hardware and software support for at least one transport that
meets the requirements specified in Clause 7.
4.2.3 Thumbnail support
The DSPD shall provide support for thumbnails as described in 6.2.
4.2.4 Standard image and data reference behaviour
In order to ensure interoperability, it is necessary to define a standard mechanism for describing image
and data objects present on a device. The DSPD shall meet the requirements described in Clause 6.
4.2.5 Asynchronous event support
The DSPD shall be capable of generating and reacting to asynchronous events. Clause 12 describes
events and their usages.
5 Data format specification
5.1 General format
5.1.1 Multibyte data
For the purposes of interpretability, all data fields showing internal content representations shall be read
from left to right, in order of decreasing byte significance, commonly referred to as big-endian notation.
Therefore, the left-most byte shall represent the Most Significant Byte (MSB), and the right-most byte
shall represent the Least Significant Byte (LSB). The most significant four bits of the MSB are referred
to as the Most Significant Nibble (MSN), while the least significant four bits of the LSB are referred to as
the Least Significant Nibble (LSN). The actual multibyte format used on the wire is transport-specific,
while the actual multibyte format used at the application interface is platform-specific.
6 © ISO 2013 – All rights reserved
5.1.2 Bit format
Bit fields presented in this International Standard are numbered so that the least significant bit is at the
zero position, holding the right-most position in the field; e.g. the most significant bit of a UINT32 would
be referred to as bit 31, while the least significant bit would be referred to as bit 0.
5.1.3 Hexadecimal notation
This International Standard uses hexadecimal notation as a means of concisely describing multibyte
fields. All hexadecimal byte fields are represented with the prefix “0x”. Following this prefix are pairs of
characters, where each pair represents one byte, with the most significant byte appearing first and the
least significant byte appearing last.
5.2 Data types
5.2.1 Datatype summary
The types of data that are defined in this International Standard as having specific interpretations of
their data content are listed in Table 1.
Table 1 — Datatype summary
Size
Name Format PTP Version
(bytes)
OperationCode 2 Datacode (UINT16) 1.0+
ResponseCode 2 Datacode (UINT16) 1.0+
EventCode 2 Datacode (UINT16) 1.0+
DevicePropCode 2 Datacode (UINT16) 1.0+
ObjectFormatCode 2 Datacode (UINT16) 1.0+
StorageID 4 Special (UINT32) 1.0+
ObjectHandle 4 Handle (UINT32) 1.0+
DateTime Variable String 1.0+
DeviceInfo Variable Dataset 1.0+
StorageInfo Variable Dataset 1.0+
ObjectInfo Variable Dataset 1.0+
DevicePropDesc Variable Dataset 1.0+
Enumerated form of 1.0+
DevicePropDescEnum Variable
DevicePropDesc
Range form of 1.0+
DevicePropDescRange Variable
DevicePropDesc
Object Variable Variable 1.0+
VendorExtensionMap 8 Dataset 1.1+
ObjectFilesystemInfo Variable Dataset 1.1+
StreamInfo 36 Dataset 1.1+
EnumID 4 Special (UINT32) 1.1+
5.2.2 Datacodes
Datacodes are 16-bit unsigned integers (UINT16) with specified interpretations, used for the purposes of
enumeration. In order to aid in visual interpretation and potential transport debugging, and to simplify
some transport implementations, the primary and vendor-defined datacodes for operations, responses,
data formats, events, and properties in this International Standard have mutually exclusive values. The
most significant four bits of a datacode (Most Significant Nibble) shall have a particular bit pattern that
identifies its code type. Therefore, the allocation of these four bits to type specification infers that the
minimum value of any enumerated datacode is 0 (xxxx0000-00000000) and the maximum value is
4,095 (xxxx1111-11111111).
It is strongly recommended that transport implementations use these codes directly in their binary
representations, but this is not mandatory. Particular transport implementations may be unable to
use the specified code systems for one or more code types, due to pre-existing structure formats for
data-wrapping, or other constraints. Where it is possible to use the codes, they should be used. If one
or more particular datacode types cannot be used, the transport implementation specification should
still attempt to accommodate those datacode types that can be used. If the binary form suggested in
this International Standard is not used for a particular datacode type, an appropriate corresponding
enumerated identifier in an alternate form should be made available where possible for each datatype
enumeration specified, each having the same usage and definition as those specified in this International
Standard. This allows for transport-aggregating abstractions in host software to use the codes defined
in this International Standard, even though a particular code might not be transmitted across the wire
for a particular transport in the binary form specified. Transports may also need to perform multiple
transactions over the wire in order to fulfill one operation defined in this International Standard, and
therefore one operation code may not be sufficient.
For example, if a transport does not use the 16-bit OperationCodes, it should still provide an equivalent
mechanism for the GetObject operation that supports the same usage defined in this International
Standard. Another example is a transport that uses OperationCodes for some operations but not others,
because the transport in question possesses a built-in mechanism for performing the equivalent
operation, and provides its own operation identification scheme for that operation. See Table 2.
Table 2 — Datacode formats
Bit 15 Bit 14 Bit 13 Bit 12 Bits 11-0 Code type
0 0 0 0 Any Undefined (not a conforming code)
0 0 0 1 Any Standard OperationCode
0 0 1 0 Any Standard ResponseCode
0 0 1 1 Any Standard ObjectFormatCode
0 1 0 0 Any Standard EventCode
0 1 0 1 Any Standard DevicePropCode
0 1 1 0 Any Reserved
0 1 1 1 Any Reserved
1 0 0 0 Any Undefined
1 0 0 1 Any Vendor-Defined OperationCode
1 0 1 0 Any Vendor-Defined ResponseCode
1 0 1 1 Any Vendor-Defined ObjectFormatCode
1 1 0 0 Any Vendor-Defined EventCode
1 1 0 1 Any Vendor-Defined DevicePropCode
1 1 1 0 Any Reserved
1 1 1
...
INTERNATIONAL ISO
STANDARD 15740
Third edition
2013-09-15
Photography — Electronic still
picture imaging — Picture transfer
protocol (PTP) for digital still
photography devices
Photographie — Imagerie des prises de vue électroniques —
Protocole de transfert d’images (PTP) pour les appareils
photographiques électroniques numériques
Reference number
©
ISO 2013
© ISO 2013
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized otherwise in any form
or by any means, electronic or mechanical, including photocopying, or posting on the internet or an intranet, without prior
written permission. Permission can be requested from either ISO at the address below or ISO’s member body in the country of
the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2013 – All rights reserved
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Digital still photography device model . 5
4.1 Overview . 5
4.2 Baseline requirements . 6
5 Data format specification . 6
5.1 General format . 6
5.2 Data types . 7
5.3 Simple types . 9
5.4 Arrays .11
5.5 Data sets . .12
6 Image and data object formats .21
6.1 Object usage .21
6.2 Thumbnail formats .22
6.3 ObjectFormatCodes .23
6.4 Object format version identification .23
6.5 Data object association .24
7 Transport requirements .26
7.1 Disconnection events.26
7.2 Reliable, error-free channel .27
7.3 Asynchronous event support .27
7.4 Device discovery and enumeration .27
7.5 Specific transports .27
8 Persistent storage .27
8.1 StorageID .27
8.2 Data object referencing .28
8.3 Receiver object placement .29
9 Communication protocol .30
9.1 Device roles .30
9.2 Sessions .30
9.3 Transactions .30
9.4 Operation flow .33
9.5 Vendor extensions .33
10 Operations .35
10.1 Operation overview .35
10.2 Operation parameters .35
10.3 OperationCode format .35
10.4 OperationCode summary .35
10.5 Operation descriptions .35
11 Responses .60
11.1 ResponseCode format .60
11.2 ResponseCode summary .60
11.3 Response descriptions .61
12 Events
............................................................................................................................................................................................................................66
12.1 Event usage .66
12.2 Event types .66
12.3 Event data set .66
12.4 EventCode format .67
12.5 EventCode summary .67
12.6 Event descriptions .67
13 Device properties .71
13.1 Device property usage .71
13.2 Values of a device property .71
13.3 Device property management requirements .72
13.4 Device property identification .72
13.5 Device property descriptions .76
14 Streaming (PTP v1.1 only) .92
14.1 Streaming overview .92
14.2 Stream transfer .92
14.3 Multiplexing .92
14.4 Discovering and configuring stream capabilities .93
14.5 Data transfer mechanism .93
14.6 Packet layout .94
14.7 Frame layout .95
14.8 Enumerating supported streams .95
14.9 Retrieving stream information.95
15 Conformance section .95
Annex A (informative) Optional device features .98
Annex B (normative) Object referencing and format codes .100
Annex C (informative) Operation flow example scenarios .102
Annex D (informative) Filesystem implementation examples .106
Annex E (informative) Reference to OSI model .109
Annex F (informative) SendObject implementation example .112
Bibliography .115
iv © ISO 2013 – All rights reserved
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out
through ISO technical committees. Each member body interested in a subject for which a technical
committee has been established has the right to be represented on that committee. International
organizations, governmental and non-governmental, in liaison with ISO, also take part in the work.
ISO collaborates closely with the International Electrotechnical Commission (IEC) on all matters of
electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are
described in the ISO/IEC Directives, Part 1. In particular the different approval criteria needed for the
different types of ISO documents should be noted. This document was drafted in accordance with the
editorial rules of the ISO/IEC Directives, Part 2. www.iso.org/directives
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of
any patent rights identified during the development of the document will be in the Introduction and/or
on the ISO list of patent declarations received. www.iso.org/patents
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
The committee responsible for this document is ISO/TC 42, Photography.
This third edition cancels and replaces the second edition (ISO 15740:2008), of which it constitutes a
minor revision with the following changes:
— as the vendor extension ID registry formerly maintained by the I3A has been transferred to another
organization, term 3.21 (I3A) was removed and the remaining terms renumbered;
— in 9.5.1, the fourth and fifth sentences were amended and combined to reflect that a new organization
assigns and maintains VendorExtensionIDs.
Introduction
This third edition of ISO 15740 (hereinafter designated PTP v1.1) provides optional support for new
increased performance and compatibility. All new constructs are fully backward compatible with the
first edition (hereinafter designated PTP v1.0) and are optional. See 5.5.2 for standard version.
For the purposes of this International Standard, digital still photography devices (DSPDs) are defined
as devices with persistent storage which capture a digital two-dimensional image at a discrete point in
time. Most DSPDs include interfaces that can be used to connect to a host computer or other imaging
device, such as a printer. A number of high speed interface transports has been developed, including
USB, TCP/IP and IEEE 1394 (FireWire). This International Standard is designed to provide requirements
for communicating with DSPDs. This includes communications with any type of device, including
host computers, direct printers and other DSPDs over a suitable transport. The requirements include
standard image referencing behaviour, operations, responses, events, device properties, data sets and
data formats to ensure interoperability. This International Standard also provides optional operations
and formats, as well as extension mechanisms.
This International Standard specifies the following:
— behaviour requirements for DSPDs; this includes the baseline features a device needs to support in
order to provide interoperability over conforming transports;
— functional requirements needed by a transport to facilitate the creation of a transport-dependent
implementation specification that conforms to this International Standard;
— a high-level protocol for communicating with and between DSPDs consisting of operation, data and
response phases;
— sets of suggested data codes and their usages including
— OperationCodes,
— ResponseCodes,
— ObjectFormatCodes,
— DevicePropCodes,
— EventCodes,
— required data sets and their usages,
— a means of describing data object associations and filesystems and
— mechanisms for implementing extensibility.
This International Standard does not attempt to define any of the following:
— any sort of device discovery, enumeration or transport aggregation methods; implementation of this
functionality is left to the transports and the platforms upon which support for this International
Standard is implemented;
— an application programming interface; this is left to the platforms upon which support for this
International Standard is implemented.
This International Standard has been designed to appropriately support popular image formats used in
[15]
digital still cameras, including the Exif and TIFF/EP formats defined in ISO 12234-1 and ISO 12234-2,
as well as the Design Rule for Camera Filesystem (DCF) and the Digital Print Order Format (DPOF).
The technical content of this International Standard is closely related to PIMA 15740:2000. The main
difference is that PIMA 15740:2000 includes an informative annex describing a USB implementation of
vi © ISO 2013 – All rights reserved
ISO 15740. This information is not included in this International Standard, which instead references the
USB still device class document developed by the Device Working Group of the USB Implementers Forum.
PTP v1.1 provides optional support for new increased performance and compatibility. All new constructs
are fully backward compatible with PTP v1.0 and are optional.
— Performance Enhancements:
— Support for retrieval of ObjectHandles in enumerated chunks, via specification of three new
optional operations and a new response code. This may reduce long response times for some
initiators that possess large numbers of objects.
— Support for optional arbitrary resizing prior to image transmission via specification of a new
operation GetResizedImageObject. In PTP v1.0, image sizes might be requested in full-resolution
or thumbnail size only.
— Support for arrays of data sets. This can be used to reduce the number of required transactions
necessary for device characterization from being a function of the number of objects on the
device to one.
— An optional fast file characterization operation called GetFilesystemManifest that exploits data
set arrays to request, in a single transaction, only the minimum data required to characterize
a typical filesystem. Many initiators, particularly in printing scenarios, are interested in fast
filesystem characterization for access to a specifically named file in a particular place. This
capability can significantly improve end-user workflow latency. This single operation replaces
the typical series of many GetObjectInfo requests with a binary filesystem manifest. This
manifest is defined as a simple array of a subset of the standard ObjectInfo data set called the
ObjectFilesystemInfo data set. This operation replaces the need for many GetObjectInfo calls,
while also avoiding the need for responders to perform many internal file-opens on the fly, or
to cache ObjectInfo image data that is often held persistently only “inside” internal image files
(e.g. TIFF tags inside EXIF JPEGs), to quickly communicate only the fast filesystem information.
— Compatibility Enhancements:
— An optional mechanism to support multiple vendor extension sets. This is specified via the new
VendorExtensionMap data set, and two new optional operations that may be invoked outside of
a session (GetVendorExtensionMaps and GetVendorDeviceInfo).
— The optional fast file characterization method GetFilesystemManifest natively supports
extremely large objects, by requiring 8-bytes for object size (UINT64), as opposed to the
standard 4-bytes.
— A new standard ObjectFormatCode to support the Digital Negative file format (DNG).
— Feature Enhancement:
— An optional mechanism for handling streaming content. This is specified via the new StreamInfo
data set, as well as the supporting GetStreamInfo and GetStream operations, as well as some
optional new supporting DeviceProperties. This is described in a new Clause 14.
INTERNATIONAL STANDARD ISO 15740:2013(E)
Photography — Electronic still picture imaging — Picture
transfer protocol (PTP) for digital still photography devices
1 Scope
This International Standard provides a common communication protocol for exchanging images with
and between digital still photography devices (DSPDs). This includes communication between DSPDs
and host computers, printers, other digital still devices, telecommunications kiosks and image storage
and display devices.
This protocol is transport- and platform-independent.
2 Normative references
The following documents, in whole or in part, are normatively referenced in this document and are
indispensable for its application. For dated references, only the edition cited applies. For undated
references, the latest edition of the referenced document (including any amendments) applies.
ISO 8601, Data elements and interchange formats — Information interchange — Representation of
dates and times
ISO 12234-2, Electronic still-picture imaging — Removable memory — Part 2: TIFF/EP image data format
ISO/IEC 10646, Information technology — Universal Coded Character Set (UCS)
ISO/IEC 10918-1:1994, Information technology — Digital compression and coding of continuous-tone still
images: Requirements and guidelines
IEC 61966-2-1, Multimedia systems and equipment — Colour measurement and management — Part 2-1:
Colour management — Default RGB colour space — sRGB
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
album
end-user-created object used to logically group data objects according to some user-defined criteria
Note 1 to entry: An album might or might not be a physical folder in a filesystem. In this International Standard,
an album is a type of association.
3.2
association
logical construct used to expose a relationship between discrete objects
Note 1 to entry: Associations are used to indicate that separate data objects are related. Associations are
represented like folders, and can be nested using a standard branched hierarchical tree structure.
EXAMPLE A time sequence, or user-defined groupings by content or capture session.
3.3
connection
transport-provided mechanism for establishing paths for transferring data between devices
3.4
datacode
16-bit unsigned integer whose Most Significant Nibble (4 bits) is used to indicate the category of code
and whether the code value is standard or vendor-extended
3.5
data object
image or other type of data that typically exists in persistent storage of a DSPD or other device
3.6
dataset
transport-independent collection of one or more individual data items with known interpretations
Note 1 to entry: Data sets are not necessarily opaque nor atomic to transport implementations.
3.7
Design Rule for Camera Filesystem
DCF
standard convention for camera filesystems which specifies the file format, foldering and naming
conventions in order to promote file interoperability between conforming digital photography devices
3.8
device discovery
act of determining the set of all devices present on a particular transport or platform that are physically
or logically accessible
3.9
digital still photography device
DSPD
device with persistent storage which captures a two-dimensional digital still image
3.10
Digital Print Order Format
DPOF
standardized ASCII file stored on removable media along with the image files that indicates how many
copies of which images should be printed
Note 1 to entry: DPOF also allows index prints, cropping, and text overlays to be specified.
3.11
enumeration
act of creating an ordered increasing numerical list that contains one representative element for each
member of a set
3.12
Exif/JPEG
compressed file format for digital cameras in which the images are compressed using the baseline JPEG
standard described in ISO 12234-2
Note 1 to entry: In Exif, metadata and thumbnail images are stored using TIFF tags within an application segment
at the beginning of the JPEG file.
3.13
folder
optional sub-structure in a hierarchical storage area that can contain data objects
2 © ISO 2013 – All rights reserved
3.14
FlashPix
image file format, defined in FlashPix Format Specification, using a structured storage file containing
metadata and a tiled, hierarchical image representation
Note 1 to entry: The tiles in a FlashPix image are normally baseline JPEG images, and individual image tiles of a
particular resolution can be easily accessed for rapid display and editing.
3.15
IEEE 1394
high-speed serial bus standardized by the IEEE (Institute of Electrical and Electronics Engineers)
currently having clock rates of 100, 200 and 400 Mbits/s
Note 1 to entry: IEEE 1394 is often referred to as FireWire.
3.16
image aspect ratio
ratio of the image width to the image height
3.17
image capture device
device for converting a scene or a fixed image, such as a print, film or transparency, to digital image data
3.18
image output device
device that can render a digital image to hardcopy or softcopy media
3.19
in-band event
event transmitted on the same logical connection as operations and responses
Note 1 to entry: Events are only asynchronous to the degree of data precision for which the transport
implementation allows event interleaving.
3.20
initiator
device that initiates a conversation by opening a session, and issues all formal operations to the responder
Note 1 to entry: The initiator is analogous to the client in the client/server paradigm.
3.21
Infrared Data Association
IrDA
infrared wireless communication system that currently supports wireless communication at data rates
between 9 600 bps and 4 Mbps
3.22
Joint Photographic Experts Group
JPEG
specific image compression method defined in ISO/IEC 10918-1
3.23
LogicalStorageID
least significant sixteen bits of a StorageID
Note 1 to entry: This value uniquely identifies one logical storage area within the physical store indicated in the
PhysicalStorageID.
3.24
Most Significant Nibble
MSN
most significant four bits of the most significant byte
3.25
object aggregation
act of taking one or more location-specific lists of objects that exist on a particular device and grouping
them together in one set
3.26
ObjectHandle
device-unique 32-bit unsigned integer assigned by a device to each data object in local persistent storage
which is provided to external devices
Note 1 to entry: External recipients of an ObjectHandle must use it to reference that piece of data in subsequent
transactions. ObjectHandles are guaranteed to be persistent over at least a session.
3.27
out-of-band event
event transmitted on a different logical connection to that for operations and responses
Note 1 to entry: Out-of-band events are asynchronous from operation transactions.
3.28
personal computer
PC
any personal computing device, which may employ various hardware architectures and operating systems
3.29
PhysicalStorageID
most significant sixteen bits of a StorageID
Note 1 to entry: This value uniquely identifies one physical storage area on a device, although there may be more
than one logical store per physical store.
3.30
Portable Network Graphics
PNG
extensible file format for lossless, portable, compressed storage of raster images
Note 1 to entry: PNG supports indexed colour, greyscale, truecolour and an optional alpha channel.
3.31
protocol
defined mechanisms for exchanging data between devices
3.32
pull model
use paradigm for DSPDs where the object receiver initiates the operation requests to transfer data
objects from the sender
3.33
push model
use paradigm for DSPDs where the object sender initiates the operation requests to transfer data objects
to the receiver
3.34
QuickDraw picture
file format consisting of sequences of saved drawing commands
Note 1 to entry: QuickDraw files are commonly referred to as PICT files.
4 © ISO 2013 – All rights reserved
3.35
responder
device that responds to operations from the initiator
Note 1 to entry: The responder is analogous to a server in the client/server paradigm.
3.36
session
logical connection between two devices defining a period of time during which obtained state
information, such as handle persistence, may be relied upon
3.37
square pixel sampling
image having equal sample spacing in the two orthogonal sampling directions
3.38
StorageID
device-specific four-byte unsigned integer (UINT32) that represents a unique storage area that may
contain data objects
Note 1 to entry: The most significant 16 bits of a StorageID represent the PhysicalStorageID, while the least
significant 16 bits of a StorageID represent the LogicalStorageID.
3.39
transport aggregation
act of taking one or more transport-specific list of conforming devices that are logically or physically
accessible in a system and grouping them in one set that spans all transports across the particular system
3.40
transport
means of attaching the digital capture device to some other digital device including a physical wire or a
wireless connection
3.41
Universal Serial Bus
USB
digital interface for connecting up to 127 devices in a tiered-star topology
4 Digital still photography device model
4.1 Overview
Digital still photography devices (DSPDs) are used to acquire digitally encoded still images. These
devices include a persistent storage capability so that any digital images and other data acquired by the
device are preserved across power cycle operations unless they are specifically deleted.
A DSPD might support many different features. This International Standard supports devices with
a wide range of potential features. However, a small number of features is required for conformance
with this International Standard, while many others are optional. Subclause 4.2 describes the required
features and functionality. Annex A describes features that are not required for conformance but which
should be implementable using this International Standard and its extension mechanisms.
Standard data formats for datatypes and data sets are described in Clause 5.
Clause 6 describes required and optional support for particular image and non-image formats and
metadata. Clause 6 also describes methods for associating data objects.
A particular feature set places requirements on the transports used to connect the DSPD to other
devices. Clause 7 describes these requirements.
All DSPDs must store images in some form of storage area. Clause 8 describes the usage of these stores,
as well as the methods for referencing them.
Clause 9 describes the roles of devices, sessions and transactions that transports are required to use
in order to communicate with and/or between DSPDs. Clause 10 lists the standard operations, their
corresponding optional operation codes and their usages. Standard responses to operations are defined
in Clause 11. The use of events is mandatory in order to ensure synchronization between devices.
Clause 12 describes events and their usages.
In order to expose device controls and manipulate properties in a common way, a standard set of device
properties and their usages have been defined in Clause 13.
Clause 15 serves as a summary of the individual operations and events that are required to be supported
by particular devices, as well as a checklist that can be used by implementers.
4.2 Baseline requirements
4.2.1 General
The requirements listed in 4.2.2 to 4.2.5 shall be met in order for a DSPD to conform to this
International Standard.
4.2.2 Implementation of a suitable transport
The DSPD shall provide appropriate hardware and software support for at least one transport that
meets the requirements specified in Clause 7.
4.2.3 Thumbnail support
The DSPD shall provide support for thumbnails as described in 6.2.
4.2.4 Standard image and data reference behaviour
In order to ensure interoperability, it is necessary to define a standard mechanism for describing image
and data objects present on a device. The DSPD shall meet the requirements described in Clause 6.
4.2.5 Asynchronous event support
The DSPD shall be capable of generating and reacting to asynchronous events. Clause 12 describes
events and their usages.
5 Data format specification
5.1 General format
5.1.1 Multibyte data
For the purposes of interpretability, all data fields showing internal content representations shall be read
from left to right, in order of decreasing byte significance, commonly referred to as big-endian notation.
Therefore, the left-most byte shall represent the Most Significant Byte (MSB), and the right-most byte
shall represent the Least Significant Byte (LSB). The most significant four bits of the MSB are referred
to as the Most Significant Nibble (MSN), while the least significant four bits of the LSB are referred to as
the Least Significant Nibble (LSN). The actual multibyte format used on the wire is transport-specific,
while the actual multibyte format used at the application interface is platform-specific.
6 © ISO 2013 – All rights reserved
5.1.2 Bit format
Bit fields presented in this International Standard are numbered so that the least significant bit is at the
zero position, holding the right-most position in the field; e.g. the most significant bit of a UINT32 would
be referred to as bit 31, while the least significant bit would be referred to as bit 0.
5.1.3 Hexadecimal notation
This International Standard uses hexadecimal notation as a means of concisely describing multibyte
fields. All hexadecimal byte fields are represented with the prefix “0x”. Following this prefix are pairs of
characters, where each pair represents one byte, with the most significant byte appearing first and the
least significant byte appearing last.
5.2 Data types
5.2.1 Datatype summary
The types of data that are defined in this International Standard as having specific interpretations of
their data content are listed in Table 1.
Table 1 — Datatype summary
Size
Name Format PTP Version
(bytes)
OperationCode 2 Datacode (UINT16) 1.0+
ResponseCode 2 Datacode (UINT16) 1.0+
EventCode 2 Datacode (UINT16) 1.0+
DevicePropCode 2 Datacode (UINT16) 1.0+
ObjectFormatCode 2 Datacode (UINT16) 1.0+
StorageID 4 Special (UINT32) 1.0+
ObjectHandle 4 Handle (UINT32) 1.0+
DateTime Variable String 1.0+
DeviceInfo Variable Dataset 1.0+
StorageInfo Variable Dataset 1.0+
ObjectInfo Variable Dataset 1.0+
DevicePropDesc Variable Dataset 1.0+
Enumerated form of 1.0+
DevicePropDescEnum Variable
DevicePropDesc
Range form of 1.0+
DevicePropDescRange Variable
DevicePropDesc
Object Variable Variable 1.0+
VendorExtensionMap 8 Dataset 1.1+
ObjectFilesystemInfo Variable Dataset 1.1+
StreamInfo 36 Dataset 1.1+
EnumID 4 Special (UINT32) 1.1+
5.2.2 Datacodes
Datacodes are 16-bit unsigned integers (UINT16) with specified interpretations, used for the purposes of
enumeration. In order to aid in visual interpretation and potential transport debugging, and to simplify
some transport implementations, the primary and vendor-defined datacodes for operations, responses,
data formats, events, and properties in this International Standard have mutually exclusive values. The
most significant four bits of a datacode (Most Significant Nibble) shall have a particular bit pattern that
identifies its code type. Therefore, the allocation of these four bits to type specification infers that the
minimum value of any enumerated datacode is 0 (xxxx0000-00000000) and the maximum value is
4,095 (xxxx1111-11111111).
It is strongly recommended that transport implementations use these codes directly in their binary
representations, but this is not mandatory. Particular transport implementations may be unable to
use the specified code systems for one or more code types, due to pre-existing structure formats for
data-wrapping, or other constraints. Where it is possible to use the codes, they should be used. If one
or more particular datacode types cannot be used, the transport implementation specification should
still attempt to accommodate those datacode types that can be used. If the binary form suggested in
this International Standard is not used for a particular datacode type, an appropriate corresponding
enumerated identifier in an alternate form should be made available where possible for each datatype
enumeration specified, each having the same usage and definition as those specified in this International
Standard. This allows for transport-aggregating abstractions in host software to use the codes defined
in this International Standard, even though a particular code might not be transmitted across the wire
for a particular transport in the binary form specified. Transports may also need to perform multiple
transactions over the wire in order to fulfill one operation defined in this International Standard, and
therefore one operation code may not be sufficient.
For example, if a transport does not use the 16-bit OperationCodes, it should still provide an equivalent
mechanism for the GetObject operation that supports the same usage defined in this International
Standard. Another example is a transport that uses OperationCodes for some operations but not others,
because the transport in question possesses a built-in mechanism for performing the equivalent
operation, and provides its own operation identification scheme for that operation. See Table 2.
Table 2 — Datacode formats
Bit 15 Bit 14 Bit 13 Bit 12 Bits 11-0 Code type
0 0 0 0 Any Undefined (not a conforming code)
0 0 0 1 Any Standard OperationCode
0 0 1 0 Any Standard ResponseCode
0 0 1 1 Any Standard ObjectFormatCode
0 1 0 0 Any Standard EventCode
0 1 0 1 Any Standard DevicePropCode
0 1 1 0 Any Reserved
0 1 1 1 Any Reserved
1 0 0 0 Any Undefined
1 0 0 1 Any Vendor-Defined OperationCode
1 0 1 0 Any Vendor-Defined ResponseCode
1 0 1 1 Any Vendor-Defined ObjectFormatCode
1 1 0 0 Any Vendor-Defined EventCode
1 1 0 1 Any Vendor-Defined DevicePropCode
1 1 1 0 Any Reserved
1 1 1 1 Any Reserved
It is a convention of this International Standard that all datacodes shall set bit 15 to 1 in order to indicate
that the code value is vendor-specific, and therefore undefined in this International Standard. Codes
indicating that they are vendor-defined should be interpreted according to the VendorExtensionID and
VendorExtensionVersion fields of the DeviceInfo data set as described in 5.5.2.
8 © ISO 2013 – All rights reserved
Individual datacode interpretations and usage are described in the appropriate section of this
International Standard for each type of datacode.
5.3 Simple types
5.3.1 Simple type summary
The generic datatypes that may be used in this International Standard are listed in Table 3.
All datatypes having bit 14 set to 1 are uniform arrays of individual fixed-length types.
Table 3 — Datatype codes
Datatype code Type Description
0x0000 UNDEF Undefined
0x0001 INT8 Signed 8-bit integer
0x0002 UINT8 Unsigned 8-bit integer
0x0003 INT16 Signed 16-bit integer
0x0004 UINT16 Unsigned 16-bit integer
0x0005 INT32 Signed 32-bit integer
0x0006 UINT32 Unsigned 32-bit integer
0x0007 INT64 Signed 64-bit integer
0x0008 UINT64 Unsigned 64-bit integer
0x0009 INT128 Signed 128-bit integer
0x000A UINT128 U
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...