Re: GdkPixbuf image depth

[Owen Taylor <otaylor redhat com>]

Havoc Pennington <hp redhat com> writes:

> On Sat, Jan 11, 2003 at 12:04:36PM +0000, Chris Garrett wrote:
> > Sorry, I meant bits-per-sample rather than bits-per-pixel.
> >
> > Is it possible to use 16 or 24 bits?  If not with GdkPixbuf, then is there 
> > another way of directly manipulating pixel data with more than 8 bits per 
> > sample, and subsequently rendering it to a gnome canvas or a drawing area?
>
> One major purpose of GdkPixbuf is to be limited to a single format -
> GdkImage is the thing that comes in multiple formats.  But of course
> that's why GdkImage doesn't support any kind of convenient
> manipulation, because doing anything with it involves the giant list
> of special cases as found in gdkrgb.c or gdkpixbuf-drawable.c.
>
> If GdkPixbuf supported M formats and GdkImage supported N formats,
> then gdkrgb.c and gdkpixbuf-drawable.c would contain M*N special cases
> intead of just the N that are in there now - ouch. ;-) And the scaling
> and compositing code would contain M cases instead of 1.
>
> Anyway, just explaining why this stuff isn't there. Basically you have
> to write your own 16-bit-sample-data-to-GdkImage converter.

I'd have to disagree with Havoc here. GdkPixbuf was originally 
intended to handle different formats of data, and has the 
necessary type fields for doing so. The point of GdkPixbuf
is not to be limited to a particular format, but to be
independent from the hardware's format.

There would be fairly major practical difficulties at this point
in adding additional formats ... a lot of code assumes that 
every GdkPixbuf is either 888 RGB or 8888 RGBA, so I'm
not sure we'll actully be doing so very soon.

(The code in GTK+ that assumes this is fixable, 3rd party code
is not in our control, so if we added additional formats,
we'd have to have big warnings "before using a pixbuf in
one of these formats, make sure that the code you are using
supports that format")

But conceptually I could definitely see supporting:

 - A more normal alpha format like 32-bit word premultiplied ARGB
 - 16 bit per channel

And perhaps even alternate color spaces like CMYK.

Though that doesn't really help you here and now. :-)

Regards,
                                        Owen