CLR_NOT_SUPPORTED when using Microsoft.SPOT.Bitmap with 1 bpp image

I’m building a handset which receives an image to dsiplay on TE35 via bluetooth from a PC in response to a key press on same handset, so it needs to be fast, surprising my users don’t like to wait! I’m willing to impose only monochrome image when operating over bluetooth since the data rate is so low. My problem is to keep the payload as small as possible my design sends an indexed bitmap with bitcount 1 to the handset, but when the NETMF receives the image and I pass to GT.Picture class I get CLR_NOT_SUPPORTED exception.

I have several options available 1) Inflate the image to 8bpp index on handset end in RLP (so its fast). Means I have to do some low level bit manipulation, not the end of the world but I’m a purist and I would like to do it the “right” way; or 2) Modify the .Net MicroFramework so it supports images with 1 bpp. My hesitation is that I’ve never had to compile the NETMF and I’m worried I opening a proverbial “Pandora’s box”.

Has anyone had success with modifying and recompiling Framework 4.3 on FEZ Spider II?
I’m aware Wifi is probably better suited but it can;t match the easy of setup of Bluetooth.
I’m using WT12 via UART running at 921600baud.

Thanks in advanced for all your support.
I only have this last issue to work out and I can start churning out hundreds of these devices on the G120.

Kind regards

@ medmont - Unfortunately since decoding 1-bit bitmaps is not supported by NETMF, your only option then is to use RLP to inflate it since rebuilding the firmware is not something we support or make available to you.

I think I would try to get the raw bytes of the bitmap-file and convert it on the device to a supported format, maybe that’s possible (don’t ask me for exact steps or code, just a thought).
I think, even without the slightest idea of how that could be done, it would be less frustrating and time consuming than recompiling the whole NETMF…

Thanks to everyone for their input.

I will rule out trying to recompile framework, which means I will have to get busy with writing an algorithm for up sizing to 8bpp.

I am intrigued by response from cyberh0me. It sounds like maybe a cheats way around the problem. Can you elaborate more please…

I just saw that there is a Bitmap-class in GHI.Utilities, maybe hat can be used.

Useful little class, but unfortunately the GH.Utilities.Bitmap.Convert method requires the image to be a Microsoft.SPOT.Bitmap which is not supported for 1bpp. Perhaps the engineers at GHI might consider providing an overload which will accept a byte[] instead of Bitmap in future release.

@ medmont - We will look into a byte[] overload for a future SDK.