Windows Mobile 6.5 Camera APIs for Custom Apps

Windows Mobile 6.5 relied primarily on Microsoft DirectShow as the low-level camera driver API that enabled developers to build fully customized photography applications. While the operating system provided simple modal dialogs for basic photo snapping, developers aiming to build specialized viewfinders, manual controls, and real-time image processing pipelines had to interact directly with the DirectShow multimedia framework, its capture graph architecture, and underlying driver properties.

The DirectShow Framework

The core architecture for custom camera development on Windows Mobile 6.5 was Microsoft DirectShow. DirectShow operated as a COM-based framework capable of rendering and capturing video and still images. To implement a custom camera interface without relying on the OS's stock UI, developers instantiated a Capture Graph Builder (ICaptureGraphBuilder2) and created a filter graph.

The physical camera driver was exposed in DirectShow as a Video Capture Filter. This filter typically provided multiple pins:

  • Preview Pin: Streamed live video frames directly to a custom UI element, usually utilizing DirectDraw or the Video Mixing Renderer for hardware-accelerated preview.
  • Capture Pin: Captured full-resolution uncompressed frames or pre-compressed JPEG buffers directly from the image sensor.
  • Still Pin: Allowed triggering dedicated high-resolution still capture without interrupting the continuous preview stream.

Sensor Control via COM Interfaces

DirectShow exposed specific COM interfaces on the video capture filter, allowing applications to programmatically control the hardware camera driver:

  • IAMCameraControl: This interface provided low-level manipulation of the optical and sensor properties, including manual and automatic focus, optical and digital zoom, exposure time, aperture (iris), pan, and tilt.
  • IAMVideoProcAmp: This interface controlled the video processing amplifier settings. Developers used it to adjust image-tuning parameters such as brightness, contrast, hue, saturation, sharpness, gamma, and white balance.

Using these interfaces, custom apps could implement on-screen sliders and toggles to adjust sensor behavior in real time, bypassing the standard operating system automation.

Low-Level Stream Driver Architecture (Camera DDI)

Beneath DirectShow, Windows Mobile 6.5 utilized the Windows Embedded CE Camera Driver Device Driver Interface (DDI). The camera driver was implemented as a streaming driver (often named CAM1:), split into a Model Device Driver (MDD) and a Platform Dependent Driver (PDD).

The PDD communicated directly with the camera sensor interface and image processor. DirectShow's capture filter translated API calls into low-level DeviceIoControl messages (specifically IOCTL_CAM_PROPERTY commands) to set hardware registers for exposure, ISO, and focus directly on the hardware.

High-Level Alternative: SHCameraCapture

For applications that did not require a custom viewfinder or custom real-time effects, Windows Mobile provided the SHCameraCapture API. Unlike DirectShow, SHCameraCapture was a high-level shell API that invoked the operating system's default modal camera window.

While straightforward to implement, SHCameraCapture did not permit custom overlays, manual shutter speeds, or custom user interfaces, making DirectShow the mandatory choice for true custom photography applications.

OEM Extensions and Proprietary APIs

Because Windows Mobile 6.5 hardware varied significantly between manufacturers, standard DirectShow implementations often lacked advanced features like burst mode, raw data access, or specific image stabilization routines. Major manufacturers such as HTC provided proprietary driver extensions and undocumented internal libraries (such as HTC's Camera.dll and customized DirectShow filter extensions) that developers reverse-engineered or accessed via partner SDKs to unlock hardware-accelerated features unique to specific handsets.