Adam Goode adam at spicenitz.org
Fri Jun 4 08:26:47 PDT 2010


I have written a library called OpenSlide that is designed to read
multi-gigapixel images stored in a variety of proprietary
vendor-specific formats. Internally, I use cairo for all the drawing,
and I return image data to the user in ARGB32 format. This is fine,
since all formats up to this point were 8-bit-per-channel RGB.

Recently, support was added to OpenSlide to read a format in
16-bit-per-channel RGB. For now, I am scaling down to 8 bits to work
within the existing interfaces of cairo as well as my own API. But I
would like to allow these kinds of images to be read at full fidelity.

Because cairo is so useful internally in my project, I would like to see
how hard it would be to add 16-bit-per-channel ARGB to cairo, rather
than having 2 paths in my own code for drawing.

I saw on the summer of code ideas page talk of CAIRO_FORMAT_ARGB64. I
think this could be the right way to go. I would want this to be an
integer format, not float16, since my data is in 16-bit format on disk,
and float16 can't represent it exactly.

What is the way to go about this? I assume pixman would need to have
support for this format, and then cairo could be adapted to work on top
of that new support. I guess there are also endian issues with using 16
bits per channel that have been avoided with the 8 bit per channel
ARGB32 format so far.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.cairographics.org/archives/cairo/attachments/20100604/7dd1a5dc/attachment.pgp>

More information about the cairo mailing list