Basic Imaging Profile
The File Transfer
Profile defines a mechanism enabling Bluetooth devices to exchange
files in a generic fashion. The foundation of the Basic Imaging Profile is
a series of constructs that enable Bluetooth
devices to negotiate the size and encoding of
imaging data to be exchanged. Given the variety of image formats currently
in use, it is impossible – without using a
negotiation mechanism – to guarantee that images transferred
via Bluetooth (even when correctly received) can actually be used by a
receiving device.
Interoperability
cannot be guaranteed unless all Bluetooth imaging devices support at
least one common image format. Therefore, this profile requires that all
Bluetooth imaging devices be capable of
receiving JPEG thumbnail images and/or providing JPEG
thumbnail versions of their stored images (either by performing format
conversions or by using a thumbnail image created when
the image is stored).
For more details : Download the BIP Profile from the Bluetooth.org
website.
Image reprinted from Bluetooth BIP Profile, Figure
2.1
The Baseband,
LMP, and L2CAP are the OSI layer 1 and 2 Bluetooth protocols.
RFCOMM is the Bluetooth adaptation of GSM TS 07.10. SDP is the Bluetooth
Service Discovery Protocol . OBEX is the Bluetooth adaptation of
IrOBEX. ME is the Management
Entity which coordinates procedures during initialization and manages
the state of the link.
The following roles are defined
for this profile:
The
Imaging Initiator is the device that initiates a Basic Imaging feature.
The Imaging Initiator must provide at least an object exchange client
and must comply with the
interoperability requirements for the client of the GOEP if not
defined in a different way in the
present profile. To support some features, the Imaging
Initiator must also provide an object exchange server and comply with
the interoperability
requirements for a server set in the GOEP.
Imaging Responder: The
Imaging Responder is the device that responds to the initiation
of a Basic Imaging feature by the Imaging Initiator. The Imaging
Responder must provide at
least an object exchange server. The Imaging Responder must comply
with the interoperability requirements for the server of the GOEP if not
defined in a different way in the
present profile. To support some features, the Imaging
Responder must also provide an object exchange client and comply with
the interoperability
requirements for a client set in the GOEP.
There is no mandatory mapping between the Imaging Initiator/Imaging
Responder roles and baseband
master/slave roles.
The scenarios covered by this profile
are:
-
Use of a mobile phone to send one
or more images to a wristwatch. Scenarios involving
imaging devices of different natures but forming a functionally
equivalent combination are also enabled by this
profile.
-
Use of a mobile phone to browse and
retrieve the images stored on a digital still
camera. These images may then be stored locally or forwarded to a
third party via a PLMN network. Scenarios
involving imaging devices of different natures
but forming a functionally equivalent combination are also enabled by
this profile.
-
Use of a PC to automatically
download the content of a digital still camera as soon
as the camera comes into the vicinity of the PC. Scenarios involving
imaging devices of different natures but forming a
functionally equivalent combination are also
enabled by this profile.
-
Use of a printer to print one or
more images sent from a digital still camera. Scenarios
involving imaging source devices of a different nature but with
equivalent functionally could also be implemented.
-
Use of a mobile phone to control
the shutter of a digital still camera and immediately
examine the result on the phone’s screen. In the present scenario,
any other portable imaging device could play the
role of the mobile phone.
-
Use of a laptop computer to send
and control the display of images by a projector
device. Scenarios involving imaging source devices of a different
nature but equivalent functionality can also be
implemented. The role of the projector could
potentially be played by any device with display capability.
The profile
fundamentals are the same as those defined in the GOEP. This
profile does not mandate that either the server or the client enter the
discoverable or connectable mode automatically even if
they are able to do so.
User interaction is
always needed to trigger one of the six features defined below, where
"user interaction" includes both on-the-fly interaction and use
of preconfigured settings.
There is a mode
associated with the Basic Imaging Profile. It affects how the Imaging
Responder is configured.
Bluetooth Imaging
Mode enables the Imaging Responder to
maintain a connection and receive commands from
Imaging Initiators. As a result of entering Bluetooth Imaging
Mode:
-
Devices that wish to be
discoverable for a limited period of time shall be in limited
discoverable mode and in connectable mode. It is expected that most
implementations will take this approach.
-
Devices that wish to be
discoverable all the time shall be in general discoverable
mode and in connectable mode.
-
Devices that wish to be hidden from
devices they never talked to before shall be
in non-discoverable mode and in connectable mode.
The setting of the
CoD bits – together with the registration of all the local imaging
applications in the SDP database of the Imaging
Responder – may also be influenced by entry
into Bluetooth Imaging Mode. It is
recommended that Bluetooth Imaging Mode be entered and exited via user
interaction, but depending on the nature of the Imaging
Responder and on the application it is running,
this mode may be entered automatically.
There are six
features associated with the Basic Imaging Profile:
-
Image Push: The Image Push
feature pushes one or more images to an Imaging Responder device.
As a result of being pushed, an image could be displayed, stored,
buffered, or printed.
-
Image Pull: The Image Pull
feature browses through the images stored on the Imaging Responder
device and downloads one or more of them as requested by the user.
-
Advanced Image Printing:
The Advanced Image Printing feature is designed for
the usage case where the Imaging Responder
is a printer or printing-enabled device. This feature enables an
Imaging Initiator device to specify print job
options and produces richer output than that
obtained by using the Image Push feature.
-
Automatic Archive:
The Automatic Archive feature triggers the Imaging
Responder device to download from the
Imaging Initiator device all or part of the images stored on that
device. It is up to the Imaging Responder to
determine which images to download – the Automatic
Archive feature could, for instance, be combined with a
synchronization application that would
retrieve only new images from the Imaging Initiator device.
-
Remote Camera: The Remote
Camera feature allows the user of the Imaging Initiator device to view
thumbnail size monitoring images as seen by the
Imaging Responder device and trigger the
shutter of the Imaging Responder when desired. The Imaging Responder
is a device with image capture capability, such as
a digital still camera.
-
Remote Display: The Remote
Display feature allows the user to push images to an Imaging Responder
with display capability and control the display sequence of those
images. These basic imaging features should
be triggered by the user. They should not generally
be performed automatically unless such action is the result of a
configuration setting that is under user control.
Section 3.3 of the BIP Profile gives
example sequences of the features outlined above.
Note: In the
example sequences, with the exception of Automatic Archive, pairing can be
performed as necessary and is left to the
implementer’s discretion. All devices must support
pairing as defined in the GAP. In the case of Automatic Archive, it is
highly recommended that pairing be a
prerequisite to the use of that feature.
This section
describes the feature requirements for devices compliant with the Basic
Imaging Profile. For each
feature described in this chapter, an open OBEX Imaging Service session
is assumed. This means that all features can be invoked
only after a successful connection
request/response to the Imaging Service of an Imaging Responder. Whether
to close the Imaging Service sessio n after each feature invocation or
leave it open for future feature invocations is
left to the implementer’s discretion.
The requirements imposed
on devices by the Basic Imaging Profile depend on the device’s
declared capabilities. The one common requirement imposed on all devices
implementing the Basic Imaging Profile is the ability
to exchange imaging data. There are three
optional capabilities that enable a device to remotely control another
device or to be remotely controlled itself:
The Basic Imaging
Profile common capability:
The optional remote
control capabilities:
-
Bluetooth Controlled Capturing: The
capture of an image, using an optical system,
via a Bluetooth interface. (A digital still camera that does not have
a shutter that can be triggered via a
Bluetooth interface is not considered a controlled
capture device.)
-
Bluetooth Controlled Printing: The
printing of images via a Bluetooth interface that
is also used to transfer images.
-
Bluetooth Controlled Display: The
display of images, controlled via a Bluetooth interface,
that is also used to transfer the images.
In all four
capabilities, imaging data is transferred between a device that acts as
source and a device that acts as destination; the role
(source or destination) is inconsequential when
classifying a device according to these capabilities.
This section lists
the features provided by this profile and the required degree of support
classified by imaging capability.
Image reprinted from Bluetooth BIP Profile, Table
4-1
Consequently, for a
device to qualify as a Basic Imaging Profile-enabled device, it shall
at least be able to act as Image Push Client or Image Pull Client or Image
Push Server or Image Pull Server.
The tables contained
in Section 4.3 of the BIP Profile describe the functions associated with
each feature and the level of support required
for each function. There are two tables per feature, one corresponding
to the requirements applicable when the feature is supported by an
Imaging Initiator device, and one corresponding to the
requirements applicable when the feature is
supported by an Imaging Responder device.
Each table lists the
functions that comprise a given feature ; the columns indicate the level
of support required for each function. When a feature requires only a
primary OBEX session, the Imaging Initiator only
needs to support the client portion of the OBEX
Imaging Service and the Imaging Responder only needs to support
the server portion of the OBEX Imaging Service. When a feature requires
both primary and secondary OBEX sessions, some
functions must be supported by both client and
server portions of the OBEX Imaging Service.
Storage Formats Support:
-
The present profile does not mandate support for
any particular imaging data storage format
Imaging File Formats Support
-
The present profile does not
mandate support for any particular imaging file format for
local storage. The method used to store images in a Bluetooth imaging
device is left to the implementer’s
discretion.
-
The only requirement, in terms of
file formats, for an imaging device to be compliant with
the Basic Imaging Profile is that it must be able to produce a
thumbnail (called an imaging thumbnail) for
each and every image that it exposes to other devices.
-
This imaging thumbnail may be a
result of a conversion performed locally or it may have
been created when the associated full-size image was captured. Other
image encodings, namely GIF, PNG, BMP, WBMP, and JPEG2000, are also
supported in this profile. There is, however, no
interoperability guarantee:
-
Interoperability presupposes that
both parties (Initiator and Responder) support
the same encoding, while the only encoding mandated by this profile is
the imaging thumbnail.
-
These other encodings have many
variants using different encoding parameters
and options. Since most of these encodings have one or more defacto
variants that codecs are assumed to support, interoperability problems
should be rare. However, there are cases –
especially for JPEG2000, which has yet to be
widely deployed in the imaging industry – where it’s possible that
an image file exchanged between two devices
supporting this profile may not be correctly
interpreted even though both devices indicate support for the encoding.
Imaging Thumbnail
-
The definition of a thumbnail in
Bluetooth Imaging (also called an imaging thumbnail in
this profile) is as follows:
-
JPEG baseline-compliant
-
sRGB as default colour space
-
Pixel size: 160x120
-
Sampling: YCC422
-
One marker segment for each DHT and
DQT
-
Typical Huffman table
-
DCF thumbnail file as file format
(i.e. EXIF with the thumbnail container in APP1
empty and the imaging thumbnail as basic main image)
-
If the aspect ratio of the original
image differs from 4:3, it is left to the implementer to decide
which method to use to produce the thumbnail (padding , filling,
cropping, etc.) .
Imaging Handles
-
The Basic Imaging Profile is based
on image handles. Image handles are indices (similar
to pointers) that are created and assigned by a device to its locally
stored images. Image handles are 7
character long strings containing only the digits 0 to 9.
-
Handles are only required to be
unique on the source device. Image handles on a device
must be valid and unique throughout the duration of a primary OBEX
connection. On some implementations, handles may be
valid throughout the lifespan of the imaging
device, but this is not a requirement of this profile
– handles can change each time a new primary OBEX connection is
established. Image
handles are always transported in an OBEX User Defined header called
"Img-Handle"
Imaging Attachments
-
This profile supports the exchange
of attachments linked with an image via its handle.All operations
related to attachments are marked with an OBEX Type header of
"xbt/ img-attachment".
XML Headers and Objects
-
All XML headers and bodies are
encoded using UTF-8. These objects listed in Section 4.4.6 of the BIP
Profile are:
-
Images-Listing Object
(x-bt/img-listing)
-
Image-Properties Object
(x-bt/img-properties)
-
Imaging-capabilities Object
(x-bt/img-capabilities)
-
Printer-control Object
(x-bt/img-print)
-
Monitoring-image Object
(x-bt/img-monitoring)
Imaging Descriptors
-
The imaging descriptors are used to
control the content of images-listing objects, describe
the characteristics of images as they’re transferred, and describe
the characteristics of attachments
associated with images as they’re transferred. Imaging
descriptors are transferred in an OBEX User Defined Header called
"Img-Description". These objects listed in Section 4.4.7 of
the BIP Profile are:
-
Image Handles Descriptor
-
Image Descriptor
-
Attachment Descriptor
This section
describes each function defined in the Basic Imaging Profile. The request
and response message formats associated with each function are described
in tables that show the mandatory OBEX fields and
headers in the OBEX frame. Note that the
position of the fields and headers within the frame as illustrated in the
following tables must be strictly followed. Headers
that are not specified in the tables may be used
and placed after the headers that are specified, but this profile does not
guarantee that other implementations will interpret
them as intended.the functions detailed are:
-
GetCapabilities Function
-
PutImage Function
-
PutLinkedThumbnail Function
-
PutLinkedAttachment
-
RemoteDisplay Function
-
GetImagesList Function
-
GetImageProperties Function
-
GetImage Function
-
GetLinkedThumbnail Function
-
GetLinkedAttachment Function
-
DeleteImage Function
-
StartPrint Function
-
GetPartialImage Function
-
StartArchive Function
-
GetStatus Function
-
GetMonitoringImage Function
There are 5 OBEX operations which are used in
the Object Push Profile: Connect , Disconnect , Put ,
Get & Abort.
The table below
lists the OBEX headers required by the Basic Imaging Profile.
Image reprinted from Bluetooth BIP Profile, Table
5-2
Note that the
profile does not exclude the headers that are not listed in Table 5-2.
Some implementations might choose to use additional
headers to enable added value services. It is
also the intention of the Bluetooth SIG to enrich further Bluetooth
Imaging with a second profile development phase, that
could lead to new headers being added to the
Basic Imaging Profile functions. Therefore unknown or unsupported
headers shall always be skipped and ignored. Application Parameters Header
, User-Defined Headers & OBEX Headers in Multi-Packet Responses
are further defined in Section 5.2 of the actual BIP Profile.
Imaging Responders
are required to support only two OBEX response codes:
A list of the full
error codes defined for the Basic Imaging Profile is contained in Table
5-4 of the BIP Profile. On the Imaging Initiator side, all the response
codes listed in Table 5-4 must be recognized as
error codes; how to handle these error codes is left to the implementer’s
discretion.Support for response codes other than Bad Request and Not
Implemented is optional; it is recommended,
however, that as many of the others as possible be supported
because they are more informative and give the client a better indication
of the nature of an error; this permits
better error reporting.
Support for OBEX
authentication is mandatory, including support for OBEX user IDs.
Whether or not it is actually used is left to the implementer’s
discretion.
Note that if a
device initiates OBEX authentication, interoperability cannot be guaranteed
with devices that lack a user interface. Therefore it is recommended that
OBEX authentication be turned off.
Some Basic Imaging Profile
features require bi-directional communication between the
Imaging Initiator and the Imaging Responder. For this reason two related
OBEX sessions are established.
The establishment of
a secondary session does not imply switching of the Imaging Initiator
and Imaging Responder roles. The Imaging Initiator is always an OBEX
client in the primary session and an OBEX server in the
secondary session; the Imaging Responder is
always an OBEX server in the primary session and an OBEX client
in the secondary session.
If for some reason
the primary OBEX session is aborted or disconnected, the secondary
session must be aborted and disconnected as well. A secondary session
cannot exist outside the primary session to which it is
related.
The service
discovery service record for the Imaging service is defined in Table 6-1of
the BIP Profile. If a Basic Imaging Profile
implementation can offer several outcomes as result of an Image
Push operation, there shall be as many service discovery records for that
implementation as there are possible outcomes, each
service discovery record having bit 0 of the
Supported Features attribute set to 0 and one and only one of bits 1,
2, or 3 set. This allows an Imaging Initiator to choose the outcome of an
Image Push operation by opening the RFCOMM
channel indicated in the relevant service discovery
record.
If a Basic Imaging
Profile implementation does not need or does not wish to specify the
outcome of an Image Push operation, it provides one and only one instance
of the service discovery record, in which bit 0
of the Supported Features attribute is set to 1
and bits 1, 2, and 3 are set to 0. For example, an implementation on which
the outcome of the Image Push operations can be
controlled from the user interface on an
operation per operation basis would probably choose not to indicate any
specific outcome in its service discovery
record.
The use of
initialization is mandatory in this profile. The procedures are defined in
the GOEP.
Note , the above text contains excerpts from the Bluetooth
SIG's Specification, as well as various interpretations of the Specs. For
complete details of the various sections, consult the actual Bluetooth
Specification.
|
