[Mono-winforms-list] Are 16-bit and 24-bit pixel formatssupportedby libgdiplus?

[Kornél Pál]

Hi,

I need 1-bit, 4-bit, 8-bit, 16-bit, 24-bit, 32-bit BMP support for
ImageListStreamer as it supports all of them. Currently it's most likely
that I will implement BMP saving entirely in managed code as MS GDI+ has no
support to convert images to indexed pixel formats. Even MS GDI+ LockBits
only has support for some pixel format conversions so I will have to do
conversion in managed code.

Unlike GDI that usually uses masks GDI+ only supports alpha channel so
images has to be stored in Format32bppArgb that requires conversion anyway.

ImageList_Read and ImageList_Write have poor BMP reader and writer
implementations that can be reproduced by preprocessing BMP headers before
GDI+ loads BMPs and modifying BMP headers after GDI+ writes them, but
probably it's easier to do everything using managed code.

Back libgdiplus:
MS GDI+ use the original image data and coverts pixel formats on the fly
when drawing. When using streams it reads pixel data every time you draw a
bitmap.

Using Format32bppArgb internally in libgdiplus can result in better
performance, but I think conversion should be done when loading and saving
bitmaps but Bitmap.PixelFormat should return the original pixel format for
compatibility.

Kornél

----- Original Message -----
From: "Jonathan Gilbert" <2a5gjx302 at sneakemail.com>
To: <mono-winforms-list at lists.ximian.com>
Sent: Thursday, November 10, 2005 5:00 AM
Subject: Re: [Mono-winforms-list] Are 16-bit and 24-bit pixel
formatssupportedby libgdiplus?


> At 03:15 PM 09/11/2005 +0100, Kornel wrote:
>>Hi,
>>
>>bmpcodec.c loads 16-bit and 24-bit bitmaps as 32-bit and has no support to
>>save bitmaps in 16-bit or 24-bit format. Is this because libgdiplus has no
>>support for these formats or is this only a limitation of bmpcodec.c?
>
> When I first started playing with mono, libgdiplus had "support" for 24-
> and 32-bit pixel formats only. By this I mean that it would, on the
> exterior, appear to be using those different types, but internally, it
> would *always* use 32-bit ARGB. This is convenient for most things because
> it is what Cairo itself uses (all Cairo supports for many operations, if I
> understand correctly), and for those few inconvenient things like
> LockBits/UnlockBits, the code would allocate a second buffer and translate
> the pixel format to/from whatever was requested. Thus, Bitmap.PixelFormat
> would return Format24bppRgb, Format32bppRgb or Format32bppArgb, but
> anything other than Format32bppArgb would result in translations. This is
> actually still the case for non-indexed Bitmap data!
>
> What I added to libgdiplus about 10 months ago was support for 1-, 4- and
> 8-bit indexed images. Actually, most of the code was already able to
> handle
> 8-bit images, as it can still compute the pixel size & stride & such in
> terms of the depth & components, but a good amount of additional code was
> required to do stuff like locking misaligned windows of 1- and 4-bit
> images. Just recently, I augmented that original patch with a patch for
> the
> rotation code (which was previously broken in another way too -- it didn't
> refresh the Cairo surface object, so anything that wasn't simply accessing
> the bits directly would cause a crash). Bitmap.RotateFlip now fully
> supports 1-, 4- and 8-bit images as well as the previously-supported
> 32-bit. In fact, it works better than Microsoft's implementation, which
> has
> an annoying bug for 5 RotateFlipType values with 1-bit images :-) (This
> snags up the test suite when running on Windows, since the original
> Microsoft GdiPlus.dll is used instead of libgdiplus, and thus RotateFlip
> produces incorrect images for those combinations! I sent an e-mail to
> Jordi
> about this a couple of weeks ago, but he still hasn't replied...)
>
> The pivotal point of my support for 1-, 4- and 8-bit indexed images, apart
> from alignment issues with LockBits, was, in order to make them usable
> with
> Cairo's drawing functions (such as what Graphics.DrawImage uses ;-), to
> produce translations of 1-, 4- and 8-bit Bitmaps to CAIRO_FORMAT_ARGB32 in
> temporary buffers released after the call completed. If you're planning on
> completing this area, this would probably be the road to go for 15-,
> 16-bit
> bitmaps as well. You would simply need to do another check like I have
> done
> in functions such as GdipDrawImageRectRect, where if the image is not
> already in format CAIRO_FORMAT_ARGB32, a function is called to translate
> the image to that format. Glancing at the Cairo source code, it appears
> that it can natively handle PixelFormat.Format24bppRgb (as
> CAIRO_FORMAT_RGB24), but you will need to do the conversions for 15- and
> 16-bit bitmaps.
>
> Hope this helps :-)
>
> Jonathan Gilbert
> _______________________________________________
> Mono-winforms-list maillist  -  Mono-winforms-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-winforms-list