BASIC IMAGING PROFILE Technical References Ver.1.0

MCPC TR-001 Ver.1.0
BASIC IMAGING PROFILE
Technical References
Ver.1.0
February 20, 2004

Mobile Computing Promotion Consortium(MCPC)

Feb 20,2004

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Revision History
Revision

Date

1.0

2004/02/20

SectionComments
Ver1.0

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

2

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Contents
Abstract ....................................................................................................................................................4
Warning ................................................................................................................................................4
Reference Standards and Specifications ..................................................................................................5Definition of abbreviations and symbols ...................................................................................................6Q1. Preferred-format in capabilities object ...............................................................................................7
Q2. Image-formats in capabilities object...................................................................................................9Q3. Example procedure to analyze capabilities object and its algorithm ................................................11
Q4. Descriptions of an image element in an Image Descriptor at the time of ImagePush ......................13
Q5. Determent of data transmission instructed by an Imaging Responder to an Imaging Initiator at thetime of Image Push ................................................................................................................................14
Q6. Response code of GetStatus Request.............................................................................................17
Q7. How to use Body/End of Body headers with GetPartialImage .........................................................20
Q8. Image formats transmitted to a digital still camera etc. ....................................................................24
Q9. When a file name cannot be handled by Imaging Responder file system........................................25
Q10. Maximum OBEX packet size .........................................................................................................26
Q11. Supported features attributes of service record when supporting Image .......................................27
Q12. Usage of Total image data capacity of service record....................................................................28
Q13. Usage of the Class of Device/Service (CoD) .................................................................................29
Contributors............................................................................................................................................31

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

3

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Abstract
This document is intended to supplement Basic Imaging Profile (BIP) specifications by Bluetooth Special
Interest Group (SIG), and to improve interoperability between BIP compliant devices. This Q&A format
document illustrates recommendable implementation methods and examples.
Warning

This document is neither mandatory requirements nor impairments to the rights of Bluetooth. Suggested
uses in this document shall be adopted by users at their sole risk and responsibilities. MCPC shall makeany explicit or implicit guarantee or warranty including but not limited to legal infringements, marketability
and consistency to certain purposes.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

4

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Reference Standards and Specifications
Shown below is a table of standards and specification documents referred by this document. The latest
versions are used unless otherwise stated.

References[1] BASIC IMAGING PROFILE Interoperability Specification[2] IMPLEMENTATION GUIDELINES BASIC IMAGING PROFILE, Revision 1.0[3] JEITA Standard Exchangeable image file format for digital still camera, Version 2.21
[4] JEITA Standard Design rule for Camera File system, Version 2.0[5] ISO/IEC 10918-1 / ITU-T Recommendation T.81 information technology - Digital compression andcoding of continuous-tone still images - Requirements and guide-lines[6] IrOBEX Specification, Version 1.2, Infrared Data Association[7] Specification of the Bluetooth System, Assigned Numbers Specification

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

5

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Definition of abbreviations and symbols
Shown below is a table of abbreviations and symbols used in this document.

Abbreviation/Symbol

Definition

CoD

Class of Device

DCF

Design rules for Camera File system

OBEX

Object Exchange Protocol

SDP

Service Discovery Protocol

Exif

Exchangeable image file for digital still cameras

XML

Extensible Markup Language

DTD

Document Type Definition

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

6

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q1. Preferred-format in capabilities objectA.
A preferred-format element is used by the Imaging Responder to inform an Imaging Initiator of the mostappropriate image format among acceptable formats. However, it is valid only when the format of anative image is identical to a specified image format or when an Imaging Initiator can convert atransmission image to a specified image format. The image format specified in this preferred-format shallbe subset of image-formats described later in Q2. And the Imaging Responder, who wishes to receive anative image without conversion of the image formats, shall not specify a preferred-format element.

As the number of appearances of preferred-format elements is specified as “?” in DTD ofimaging-capabilities object, multiple descriptions are not possible and if unnecessary, it may be omitted.
And according to an attribute-list declaration of preferred-format element, four attribute values,“encoding”, “pixel”, “transformation” and “maxsize” are defined. Among them, “encoding” is a mandatory
attribute, which shall be described upon describing a preferred-format element. On the other hand,“pixel” may be omitted. However it is recommended to describe it as much as possible in order toenhance interoperability. Although “pixel” may be described either in a fixed value (e.g. ”640*480”) or a
range of pixel sizes (e.g. ”1*1-1600*1200”), descriptions in a fixed value is recommended.

Shown below is an element type (ELEMENT) declaration and an attribute-list (ATTLIST) declaration
related to a preferred-format element extracted from DTD of imaging-capabilities object.
<!ELEMENT preferred-format EMPTY><!ATTLIST preferred-format
encoding CDATA #REQUIRED
pixel CDATA #IMPLIED
transformation NMTOKENS #IMPLIED ”stretch crop fill”
maxsize CDATA #IMPLIED>

Description examples of a preferred-format element are shown as:・

Example1
The Imaging Responder is able to receive JPEG encoded images and BMP encoded images of any
pixel sizes but prefer JPEG encoded image with size 320*240 pixels.
<imaging-capabilities version=”1.0”><preferred-format encoding=”JPEG” pixel=”320*240”/><image-formats encoding=”JPEG” pixel=”1*1-65535*65535”/><image-formats encoding=”BMP” pixel=”1*1-65535*65535”/></imaging-capabilities>

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

7

BASIC IMAGING PROFILE Technical References Ver.1.0
・

Feb 20,2004

Example2
The Imaging Responder is able to receive JPEG encoded images of 160*120 pixel size and640*480 pixel size but prefer JPEG encoded images of 640*480 pixel size.
<imaging-capabilities version=”1.0”><preferred-format encoding=”JPEG” pixel=”640*480”/><image-formats encoding=”JPEG” pixel=”160*120”/><image-formats encoding=”JPEG” pixel=”640*480”/></imaging-capabilities>

・

Example3
The Imaging Responder is able to receive JPEG encoded images of any pixel sizes, but prefer
JPEG encoded images of 640*480 (VGA) ~ 1024*768 (XGA) pixel size.
<imaging-capabilities version=”1.0”><preferred-format encoding=”JPEG” pixel=”640*480-1024*768”/><image-formats encoding=”JPEG” pixel=”1*1-65535*65535”/></imaging-capabilities>

・

Example4
The Imaging Responder is able to receive JPEG encoded images of all pixel sizes, but it prioritizes
the reception of JPEG encoded images whose file size is 50000 bytes or smaller.
<imaging-capabilities version=”1.0”><preferred-format encoding=”JPEG” maxsize=”50000”/><image-formats encoding=”JPEG” pixel=”1*1-65535*65535”/></imaging-capabilities>

・

Example5
The Imaging Responder is able to receive JPEG encoded images and BMP encoded images of all
pixel size, but it prioritizes the reception of JPEG encoded images.
<imaging-capabilities version=”1.0”><preferred-format encoding=”JPEG”/><image-formats encoding=”JPEG” pixel=”1*1-65535*65535”/><image-formats encoding=”BMP” pixel=”1*1-65535*65535”/></imaging-capabilities>

As shown in above examples, when describing a preferred-format element, “pixel” may be described
either in a fixed value (e.g. ”640*480”) or a range of pixel sizes (e.g. ”1*1-1600*1200”). However,descriptions in a fixed value are recommended in order to reduce the processing load for an Imaging
Initiator to determine the pixel size of an image.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

8

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q2. Image-formats in capabilities object

A.
An Image-formats element is used by the Imaging Responder to inform an Imaging Initiator of theacceptable image format.

As the number of appearances of an image-formats element is specified as ”*”, in DTD ofimaging-capabilities object, multiple descriptions of image format are possible. (It may be omitted when it
does not act as an ImagePush Responder.) According to attribute-list declaration of image-formats
element, three attribute values, “encoding”, “pixel”, and “maxsize” are defined. Among them, “encoding”
is a mandatory attribute for the descriptions. “Pixel” may be omitted, though for the interoperability
enhancement, the description is encouraged. When “pixel” is omitted, it shall be considered that there isno limitation in acceptable pixel sizes.

Shown below are an element type (ELEMENT) declaration and an attribute-list (ATTLIST) declaration
related to an image-formats element extracted from DTD of an imaging-capabilities object.
<!ELEMENT image-formats EMPTY><!ATTLIST image-formats
encoding CDATA #REQUIRED
pixel CDATA #IMPLIED
maxsize CDATA #IMPLIED>

Description examples of an image-formats element are shown.
・

Example1
The Imaging Responder is able to receive JPEG encoded images of any pixel sizes.
<imaging-capabilities version=”1.0”><image-formats encoding=”JPEG” pixel=”1*1-65535*65535”/></imaging-capabilities>

・

Examble2
The Imaging Responder is able to receive JPEG images of 1*1~1600*1200 pixel size.
<imaging-capabilities version=”1.0”><image-formats encoding=”JPEG” pixel=”1*1-1600*1200”/></imaging-capabilities>

・

Example3
The Imaging Responder is able to receive only JPEG encoded images with sizes 160*120 pixels,
320*240, 640*480 and 1280*960.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

9

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004<imaging-capabilities version=”1.0”><image-formats encoding=”JPEG” pixel=”160*120”/><image-formats encoding=”JPEG” pixel=”320*240”/><image-formats encoding=”JPEG” pixel=”640*480”/><image-formats encoding=”JPEG” pixel=”1280*960”/></imaging-capabilities>
・ Example4
The Imaging Responder is able to receive only JPEG encoded images with sizes 160*120~320*240
pixels, 640*480 and 1280*960.
<imaging-capabilities version=”1.0”><image-formats encoding=”JPEG” pixel=”160*120-320*240”/><image-formats encoding=”JPEG” pixel=”640*480”/><image-formats encoding=”JPEG” pixel=”1280*960”/></imaging-capabilities>

As shown in above examples, when describing an image-formats element, acceptable pixel sizes of
Imaging Responder may be described either by a range of pixel sizes (e.g. ”1*1-1600*1200”) or a fixedvalue (e.g. ”640*480”). However when a pixel size is described by a fixed value, an Imaging Initiatormaybe able to resize the image to an approximate size but not to an exact size, and may fail to transmit it
for a few pixels error. Therefore in order to enhance the interoperability, it is recommended to describe
acceptable pixel sizes by a range of pixel sizes as long as Imaging Responder’s capability permits.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

10

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q3. Example procedure to analyze capabilities object and its algorithm

A.
The graph below is an example of a procedure analyzing capabilities object in case of an Image Push
initiator.
Start

Obtain Image Capabilities
ObjectConfirm Preferred format

Preferred format
exist?

Image format conversion
based on preferred-format

Yes

Native imagetransmittable?

Yes
Transmit native image

No
No
Conversion possible?

Convert andtransmit

No
Confirm Image formats

Image format conversion
based on image-formats

Native imagetransmittable?

Yes
Transmit native image

No

Conversion possible?

No

Yes

Yes
Convert andtransmit

Transmit JPEG encoded
thumbnail image

End

Figure 1: A recommended procedure to analyze Image Capabilities Object

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

11

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Image format conversion based on a preferred-format:
According to the ATTLIST preferred-format, an original image should be transmitted without
conversion if possible. If the result of the analysis reveals that the original image cannot betransmitted, the conversion is performed and the converted image is transmitted. When theconversion is impossible, the process of the image format conversion based on apreferred-format is terminated.

When the pixel size in preferred-format is described by a fixed value, it is recommended toresize the image to this fixed value if possible. When the pixel size in preferred-format is
described using a range and the native image pixel size exceeds upper limit, it is recommended
to resize the image to the upper limit. On the contrary when the native image pixel size falls
below lower limit, it is recommended to resize the image to the lower limit. And when scaling
down the image to a pixel size specified by an Imaging Responder while maintaining the aspectratio, and if the size is not identical to the specified pixel size because of decimal point handlingetc., it is recommended, if necessary, to apply a conversion processes such as fill, crop andstretch for the matching.

On the other hand, when a pixel size is not described in a preferred-format, it shall be decided
referring to the value in the image-formats.

Image format conversion based on image-formats:
According to ATTLIST image-formats, an original image should be transmitted without
conversion if possible. If native image format is not one of the formats listed in image-formats,conversion is performed and the converted image is transmitted. When the conversion is
impossible, the process of image format conversion based on image-formats is terminated.

Resizing to a larger pixel sizes should be avoided as much as possible. It is recommended toresize to the biggest pixel size of Imaging Responder’s pixel sizes range, keeping it smaller
than original image. And when reducing the image to the pixel size specified by an Imaging
Responder while maintaining the aspect ratio, and if the size is not identical to the specified
pixel size because of decimal point handling etc., it is recommended, if necessary, to apply aconversion processes such as fill, crop and stretch for the matching.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

12

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q4. Descriptions of an image element in an Image Descriptor at the time of ImagePush

A.
When transmitting an image using ImagePush, it is mandatory to describe properties of the image to betransmitted in an image element of Image Descriptor. Image Descriptor is defined as follows:<!DOCTYPE image-descriptor [<!ELEMENT image-descriptor ( image ) ><!ATTLIST image-descriptor version CDATA #FIXED ”1.0” ><!ELEMENT image EMPTY><!ATTLIST image
encoding CDATA #REQUIRED
pixel CDATA #REQUIRED
size CDATA #IMPLIED
maxsize CDATA #IMPLIED
transformation (stretch | fill | crop ) #IMPLIED]>

According to the attribute-list declaration of the image element, five attribute values are defined;“encoding”, “pixel”, “size”, “maxsize” and “transformation”. Among them, “encoding” and “pixel” aremandatory attributes for the description. “Size” may be omitted, though for the enhanced interoperability,
the use of this attribute is encouraged.

When an Imaging Initiator specifies the image size into the Image Descriptor, It enables the Imaging
Responder to confirm the image size upon the image reception. Therefore, for example, when the
Imaging Responder notices that the image size is larger than the reception buffer size, the Imaging
Responder can immediately return an error code and terminate the processing.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

13

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q5. Determent of data transmission instructed by an Imaging Responder to an Imaging Initiatorat the time of Image PushA.
In some cases when Image Push is used, an Imaging Responder may want to temporarily withhold datatransmissions from an Imaging Initiator during a communication sequence; for example in a case that
the Imaging Responder’s storage area for received data becomes insufficient.

For example, in case of transmission of image file to a printer, the situation stated above happens whenthe Imaging Initiator continuously sends several pages or errors such as paper-out or ink-out occurs at a
printer during the transmission. The communication sequence is as follows.
Imaging Initiator

Imaging Responder

OBEX
ClientOBEX
ServerConnection establishment

PutImage・・・Continue

・Receive Buffer Full detected
・Paper out/Jam/Ink Error detected
Waiting for a while to send CONTINUE
response

PutImageContinue
PutImage

Figure 2: A communication sequence example where the Imaging Responder sustains response during
ImagePush

Problems of the communication sequence in Figure 2 are listed below.
Problems on the Imaging Responder’s side (e.g. printer) are;・

Printing may may not be performed due to disconnection if an Imaging Initiator has set a timer forthe reception of the response.

・In case of an Imaging Responder implements to return an error code (ex. Not Acceptable/Service
Unavailable), the Imaging Initiator could possibly release the session.

Impacts on the Imaging Initiator are;・

If an Imaging Initiator uses, for example, a progress bar indicating the progress of an image

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

14

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

transmission, the progress bar would stop due to lack of the response, and it would look like theapplication was frozen.
・ When there is no response, an Imaging Initiator is unable to judge whether it is caused by flow
control or some error in the Imaging Responder.

In such case, implementations stated below are recommended.
・An Imaging Responder suspends the response of OBEX PUT command.

・An Imaging Initiator sets longer timeout value

・An Imaging Initiator release the session after timeout.

Figure 3 shows the communication sequence in case of timeout of the Imaging Initiator.
Imaging Initiator

Imaging Responder

OBEX
ClientOBEX
ServerConnection establishment

PutImage・・・Continue

PutImageContinue
PutImage

Wait Timer

・Receive Buffer Full detected
・Paper out/Jam Ink Error detected
Waiting for a while to send CONTINUE
response

Resumption ofContinue

the communication

PutImageContinue
PutImage・Receive Buffer Full detected
・Paper out/Jam/Ink Error detected
Waiting for a while to send CONTINUE
response

Wait Timer

TimeupConnection release

Figure 3: A Communication Sequence Example for the Recommended Implementations in Image Push

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

15

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Timeout is Imaging Initiator’s implementation dependent. Examples of timeout setting of an Imaging
Initiator when transmitting image files to a printer are shown below as references:

Example 1: Considering the possibility of paper out or ink out of the printer.
User shall be given enough time to restore the printer before timeout, although it depends on an actual
usage situation.

Example 2: Considering possibility of consecutive jobs using same session to an inkjet printer.
Timeout value shall be set in consideration of time necessary for an inkjet printer to print one page ofimage. In case of an Imaging Initiator is likely to perform consecutive printings, timeout value shall be
set in consideration of a printing time. (Setting timeout value shorter than the duration of one page
print would possibly generate an error during consecutive printings)

Example 3: In case timeout value is set giving highest priority on power saving of an Imaging Initiator.
Timeout value shall be set in consideration of the battery capacity of an Imaging Initiator.

* When communications are made between the Imaging Initiator and the Imaging Responder as
described in Q4 or Q12, the possibility to cause such problem is low.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

16

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q6. Response code of GetStatus RequestA.
Paragraph 4.5.15 of BIP[1] describes response codes of GetStatus Request as follows:・After establishment of the secondary connection, an Imaging Responder shall return a response
code “Continue” to each GetStatus request coming from an Imaging Initiator. After the secondary
connection has been disconnected, an Imaging Responder shall return “Success” response code.

・In case of secondary connection cannot be preserved due to an error on the Imaging Responder, anerror response code should be returned to GetStatus request coming from the Imaging Initiator.

Furthermore, it is recommended for an Imaging Responder to implement the following in order toenhance the interoperability.
・An Imaging Responder shall return “Continue” response code to a GetStatus request coming fromthe Imaging Initiator before the establishment of the secondary connection.

Figure 4 shows a communication sequence using the additional recommendation.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

17

BASIC IMAGING PROFILE Technical References Ver.1.0

Imaging Initiator
SecondaryServer

Feb 20,2004

Imaging Responder

Primary
ClientPrimaryServerSecondary
ClientConnection establishment

GetStatus
Continue

Connection establishment
GetStatus
Continue

GetStatus
Continue

Disconnect
GetStatus
Success

Disconnect

Figure 4: A communication sequence example using recommendation with Advanced Image Printing

The explanation is as follows:

Regarding the portion inside dotted line in Figure 4, the Imaging Responder shall assume that a Primary
Client of the Imaging Initiator may or may not transmit GetStatus request. (BIP[1] specifies transmission
condition for GetStatus request in StartArchive but does not specify it in StartPrint.) For example, if an
Imaging Responder is implemented to return an error code or “Success” response code when thesecondary connection is not established, the Imaging Initiator would release the primary connection justbefore or during the establishment process of the secondary connection. (BIP[1] specifies that uponreceiving “Success”, the Imaging Initiator shall release the primary connection.) Figure 5 shows thecommunication sequence described above.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

18

BASIC IMAGING PROFILE Technical References Ver.1.0

Imaging Initiator
SecondaryServer

Feb 20,2004

Imaging Responder

Primary
ClientPrimaryServerSecondary
ClientConnection establishment

GetStatus
Success

Disconnect

Connection establishment

NG
Figure 5: Possible problems in case the recommended implementation is not performed

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

19

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q7. How to use Body/End of Body headers with GetPartialImageA.
When transmitting a partial image file requested by GetPartialImage, an Imaging Initiator isrecommended to use an End of Body header in case of the final part of the partial image file, but use
Body header in the other cases. And in case of the response of the final part of the image file, EndFlag=1
should be set.

Shown below is an example of Body / End of Body headers usage when obtaining a 2000 bytes JPEG
image (img5.jpg) using GetPartialImage.
Imaging Initiator
SecondaryServerImaging Responder

Primary
ClientPrimaryServerSecondary
Client・・・Connection establishment

Connection establishment(1)

Get Request: GetPartialImage(PFSO=0,PFL=1024)
Get Response: Continue（Body＝512byte EndFlag=0）(2)

Get Request: GetPartialImage

GetPartialImage
Process to obtainfirst 1024 bytes
of a file.

Get Response: Success（End of Body=512byte）(3)

Get Request: GetPartialImage (PFSO=1024, PFL=976)
Get Response: Continue（Body＝512byte EndFlag=1）(4)

Get Request: GetPartialImage
Get Response: Success（End of Body=464byte）

GetPartialImage
Process to obtain
976 bytes of data
starting fromth1024 byte to theend of the file.

・
・
・
Where
PFSO: PartialFileStartOffset
PFL: PartialFileLength

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

20

BASIC IMAGING PROFILE Technical References Ver.1.0

Secondary

Bytes

Meaning

0x83

GET, Final bit set

0xnnnnLength of packet

0xCB

HI for Connection Id header

0xnnnnnnnn

Connld = nnnnnnnn

0x42

HI for Type header

0x0014

Length of Type header

x-bt/img-partial

MIME Media-Type of object, null terminated

0x01

HI for Name header

0x0015

Length of Name header

0069 006D 0067

Name header content “img5.jpg”

Feb 20,2004

Client Request:(1)Opcode0035 002E 006A (UTF-16 encoded), null terminated0070 0067 0000
0x4C

HI for Application Parameter header

0x000F

Length of Application Parameter header

04 04 00000400

PartialFileLength (= 1024 Bytes)

05 04 00000000

PartialFileStartOffset (= 0)0x90

Continue, Final bit set

0xnnnnLength of response packet

0xC3

HI for Length header

0x00000400

Length of partial file

0x4C

HI for Application Parameter header

0x000C

Length of Application Parameter header

06 04 000007D0

TotalFileSize (= 2000 Bytes)

07 01 00

EndFlag (= FALSE)

0x48

HI for Body header

0x0200Length of Body header

SecondaryServer response:(1)Response code

0x……
Secondary
Client Request:(2)Opcode

0x83

GET, Final bit set

0xnnnnLength of packet

0xCB

HI for Connection Id header

0xnnnnnnnn

Connld = nnnnnnnn

Secondary
Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

21

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Server response:(2)Response code

0xA0

Success, Final bit set

0xnnnnLength of response packet

0x49

HI for End of Body header

0x0200Length of End of Body header

0x……

Secondary

Bytes

Meaning

0x83

GET, Final bit set

0xnnnnLength of packet

0xCB

HI for Connection Id header

0xnnnnnnnn

Connld = nnnnnnnn

0x42

HI for Type header

0x0014

Length of Type header

x-bt/img-partial

MIME Media-Type of object, null terminated

0x01

HI for Name header

0x0015

Length of Name header

0069 006D 0067

Name header content “img5.jpg”

Client Request:(3)Opcode0035 002E 006A (UTF-16 encoded), null terminated0070 0067 0000
0x4C

HI for Application Parameter header

0x000F

Length of Application Parameter header

04 04 000003D0

PartialFileLength (= 976 Bytes)

05 04 00000400

PartialFileStartOffset (= 1024)

0x90

Continue, Final bit set

0xnnnnLength of response packet

0xC3

HI for Length header

0x000003D0

Length of partial file

0x4C

HI for Application Parameter header

0x000C

Length of Application Parameter header

06 04 000007D0

TotalFileSize (= 2000 Bytes)

07 01 01

EndFlag (= TRUE)

0x48

HI for Body header

0x0200Length of Body header

SecondaryServer response:(3)Response code

0x……
Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

22

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Secondary
Client Request:(4)Opcode

0x83

GET, Final bit set

0xnnnnLength of packet

0xCB

HI for Connection Id header

0xnnnnnnnn

Connld = nnnnnnnn

0xA0

Success, Final bit set

0xnnnnLength of response packet

0x49

HI for End of Body header

0x01D0Length of End of Body header

SecondaryServer response:(4)Response code

0x……

Figure 6: An Example of Body/End of Body headers usage in Advanced Image Print

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

23

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q8. Image formats transmitted to a digital still camera etc.

A.
As there are various types of JPEG formats, digital still cameras may not handle all of those formats
properly. Even if transmissions of a JPEG encoded image succeed, an Imaging Responder might not beable to display this image. Recommendations for transmissions of JPEG encoded image to a digital stillcamera etc. are as follows:

Digital still camera etc. generally use image formats which conforms to Exif[3] and DCF[4]. When other
JPEG encoded images are sent to a digital still camera etc., the main images or the thumbnail images
may not be displayed properly. Therefore, it is recommended to do as follows:

1) If necessary, before transmitting JPEG images, an Imaging Initiator should conform them to Exif[3]and DCF[4].
(A judgment of whether Imaging Responder is digital still camera or not can be made by the CoD.)
2) In other cases, it is recommended to transform an image that satisfies following conditions.
・Use standard Huffman table [5].
・Use baseline DCT method [5].

Furthermore, when a digital still camera acts as an Imaging Responder, the possibility to receive nonExif[3] and DCF[4] compliant images should be taken into considerations.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

24

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q9. When a file name cannot be handled by Imaging Responder file systemA.
In some cases, Name header cannot be handled by a file system of an Imaging Responder. For example,
an Imaging Initiator may transmit an image with a Name header encoded by Japanese character set,
while an Imaging Responder cannot handle Japanese characters.

This type of situation is also described in Q14 of BIP[1] whitepaper[2]. For higher interoperability, It is
recommended to proceed as follows:・

When the file name of received image cannot be handled by the file system, the Imaging Responder
should proceed to create file after converting the file name to a usable one.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

25

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q10. Maximum OBEX packet sizeA.
In OBEX[6], maximum OBEX packet sizes are negotiated during the connection process, and thesmaller one is adopted as their communication maximum packet size for their onward communications.
(The usable packet size based on OBEX[6] specification is from 255bytes to 64Kbytes-1.)

When this size is small, transmission rate becomes extremely slow. For example, in case of PUT
operation, the OBEX Server returns a response, following the OBEX Client data. The OBEX client does
not transmit next data until it receives a response for the previously transmitted data. The time waiting for
responses creates a big overhead. When the packet size is large, the frequency of a response wait
becomes smaller and throughput is improved.

Because BIP[1] handles images, the amount of transmitted data is large. The packet size should be aslarge as possible in order to have good throughput. Recommended packet size is the one that enablestransmission of a whole thumbnail image at one time. (e.g. 5Kbytes)

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

26

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q11. Supported features attributes of service record when supporting Image

A.
Refer to 6.1.1. of BIP[1].

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

27

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q12. Usage of Total image data capacity of service record

A.
Total image data capacity attribute is a reference value of the memory size of the Imaging Responder for
the image storage capability. For example, although the memory size for image storage capability
decreases as images are received, it is not necessary to dynamically change the value of the Total
image data capacity.

An Imaging Initiator can decide not to transmit an image in case that the size of this image is bigger than
the Total image data capacity of the Imaging Responder.

However, since the value of a Total image data capacity is just a reference, there is no guarantee that the
Imaging Responder will succeed in storing an image transferred from an Imaging Initiator, even if the
Total image data capacity is larger than the size of the image.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

28

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Q13. Usage of the Class of Device/Service (CoD)A.
CoD is a 3 octets value and can be described as
b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13 b12 b11 b10 b9 b8 b7 b6 b5 b4 b3 b2 b1 b0.
Where “b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13” represents the Major Service Class, “b12 b11 b10 b9 b8”
represents the Major Device Class and “b7 b6 b5 b4 b3 b2” represents the Minor Device Class. “b1 b0” isthe Format Type field and should have the value “0 0”. Each bit should be set in conformance with
Assigned Numbers Specification[7].

The value of the Major Service Class is subject to change depending on available functions (services),but it is recommended that the Object Transfer attribute bit “b20” is set to 1. CoD examples with thedescriptions are shown below.
Device type
Major Service Class:b23 b22 b21 b20 b19 b18 b17 b16 b15 b14 b13

Major Device Class:b12 b11 b10 b9 b8

Minor Device Class:b7 b6 b5 b4 b3 b2

Digital Still Camera
Major Service Class:00011000000

Major Device Class:

00110

Minor Device Class:

001000Printer
Major Service Class:00010100000

Major Device Class:

00110

Minor Device Class:

100000

Cellular Phone
Major Service Class:

01010000000

Major Device Class:

00010

Minor Device Class:

000001Laptop PC
Major Service Class:00010000000

Major Device Class:

00001

Minor Device Class:000011

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 2004

29

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Handheld PC/PDA
Major Service Class:00010000000

Major Device Class:

00001

Minor Device Class:000100Palm sized PC
Major Service Class:00010000000

Major Device Class:

00001

Minor Device Class:000101

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 200430

BASIC IMAGING PROFILE Technical References Ver.1.0

Feb 20,2004

Contributors
Kazuo Shimizu

OLYMPUS CORPORATION

Yasuji Tamatsu

OPEN INTERFACE, INC.

Hideaki Tanaka

OPEN INTERFACE, INC.

Yasumasa Takahashi

OPEN INTERFACE, INC.

Soichi Saito

DENSO CORPORATION

Kiyotaka Inaba

RICOH COMPANY, LTD.

Hiroaki Uchiyama

RICOH COMPANY, LTD.

Alain Volmat

RICOH COMPANY, LTD.

Takuya Kawamura

LeaderTakayasu Aoki
Kenichi Fujii

TOSHIBA CORPORATIONTOSHIBA CORPORATION Digital Media Network Company

Sub-leader

CANON INC.

Kenichi Kurata

SEIKO EPSON CORPORATION

Tomohiro Ogawa

Sony Corporation

Mitsuyoshi Yasuda

Sony Ericsson Mobile Communications Japan, Inc.

Hiroshi Kato

TAIYO YUDEN CO., LTD.

Katsumi Murakami

FUJITSU LIMITED/FUJITSU DEVICES INC.

Yoshio Watanabe

FUJITSU LIMITED/FUJITSU DEVICES INC.

Tatsuya Inagaki

Matsushita Electric Industrial Co., Ltd.

Copyright(C) Mobile Computing Promotion Consortium (MCPC), 200431