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...
Size: 261 bytes
Desc: OpenPGP digital signature
More information about the cairo