BlueZ

This summer Jakub Adamek worked in the support for the Basic Image Profile(BIP) as his Google Summer of Code project.  Check his report below.

My Google Summer Of Code project was to implement the Basic Imaging Profile in obexd, and with Vinicius Costa Gomes as my mentor and the help of the Bluez community.

BIP is an OBEX based profile. Its specification can be found here. It was created primarily to give devices a way to negotiate encoding and image size before exchanging image data. Given the multitude of image formats in use, having such a mechanism is necessary to make sure a transferred image can be used by the receiving device. BIP also ensures some interoperability by defining an image format that can be understood by all implementations (called an imaging thumbnail in the spec).

The code of my implementation can be found here. The main reason that it is not in the Obexd tree is that the profile requires support for User-Defined Headers. Obexd is currently in transition, with OpenOBEX being phased out in favor of gobex, which
supports User-Defined Headers cleanly. After that transition is complete shifting the BIP code will be possible.

The profile is divided into 6 features. I’ll try to outline for you what these features are for, to what extent they are implemented and
why.

Image Push and Image Pull provide functions used to exchange image data. Between them, their functions allow a client to list images on the server, find out their properties (such as encodings and pixel sizes they are available in); upload and download images, attachments and thumbnails. We decided on using a command line configurable BIP root folder (like the FTP root folder) to store uploaded and downloadable images. The server accepts all possible image formats and by using the MagickWand library converts the images stored to whatever format the client desires. All functions these features support are mapped out to DBus methods provided by the Obexd client.

Automatic Archive allows a device (e.g. a camera) to request its recently captured images to be downloaded by another device. This feature requires the establishment of a second connection used for actual data transfer, in which the former server becomes the client and vice versa. We decided on a solution where the obexd server uses the obexd client via dbus to establish this connection – thus using this feature without the client is impossible. Images pulled are stored in the BIP root folder. The client implementation lacks one optional function because it is difficult to implement under OpenOBEX but should be simple with gobex. The client uses the obexd server for handling the secondary connection, and the source of the images to be archived is the BIP root folder.

Advanced Image Printing gives the possibility to control a printing device using the Digital Print Order Format. Obtaining the
specification for DPOF however requires a licensing agreement (see http://panasonic.jp/dc/dpof_110/white_e.htm), and thus I resigned from implementing this feature.

Remote Camera and Remote Display can cause specific actions in devices, and so their implementation in the server allows registering agents to handle such actions. Remote Camera can be used to request a digital still camera to capture an image, while Remote Display gives the possibility to upload images to a displaying device (e.g. a projector) and control which of them are shown. The agent APIs are currently simple and could use refinement. For Remote Camera unfortunately no truly useful agent implementation exists as of this moment, though writing one using e.g. libgphoto2 as a back-end is possible. A primitive proof of concept agent implementation exists for Remote Display that uses Okular to display the received images on screen. Both features have client implementations that map out all functions to dbus methods on the obexd client.

That’s the status as far as functionality goes. The code could use some polishing and there are some things that can definitely be done better. At least after reading this you should be well informed. Even if time constraints may cause progress to be slow, it is underway, so please stay tuned.

By Jakub Adamek