Re: Question on gdk-pixbuf

Lauris Kaplinski <> writes:

> This states one more time gdk-pixbuf-s need of coherent colorspace API.
> I vote for adding colorspace enums, similar to OpenGL ones:
> R8G8B8A8
> R5G6B5
> R16G16B16
> C8M8Y8K8
> etc.
> Until there is no quality code, even silly converters would do. Plus
> people actually needing something (say 16bit color) would then eagerly
> write gdk-pixbuf routines, instead of private ones.

We have the data format as a (colorspace, bits per pixel) pair.  I
really don't want to support R5G6B5 and other such brokenness.  I
would like to have (grayscale, 8) and (cmyk, 8) representations.
16-bit channels would also be good.

Adding support for this can be done reasonably easily, I think.

> > Incidently, I am wondering whether it would be better to have a single
> > parameterised function for doing pixbuf -> pixbuf transfer operations,
> > detecting scaling, change of depth etc. automagically.  It might be a
> > little slower than a direct call, but would be much easier to document and
> > grok.  It might also be faster, if it can detect tricks efficiently(such
> > as noting that a requested scale operation is actually 1:1).
> Exactly :)

The pixops function pretty much take care of all of this already.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]