[cairo] cairo_format_t [was: static array allocation caused a segfault]

[Kai-Uwe Behrmann]

>    8. Re: static array allocation caused a segfault (Vladimir Vukicevic)

> Date: Mon, 12 Nov 2007 16:49:46 -0800
> From: Vladimir Vukicevic <vladimir at pobox.com>
> On Nov 12, 2007, at 12:02 PM, Pete wrote:
> 
> > qiuhqing <qiuhqing <at> gmail.com> writes:
> >>    double rgb[805*805*3];
> >>    CAIRO_FORMAT_ARGB32,
> >
> >
> > Also be aware that ARGB32 should be 805 * 805 * 4. Your static array  
> > is too
> > small, even if it works directly on the stack like this.
> 
> While we're at it, it should be 805*805 of uint32_t, not of double.  A  
> memory chunk of 805*805*3 doubles is plenty big for an 805x805 ARGB32  
> image, but I hope you're not going to try accessing it directly :)
 
I find it always confusing to say CAIRO_FORMAT_ARGB32 and mean a 8-bit 
per channel thing. At a first glace I seriously expect it to be a IEEE 
float format, which it is not. Most users will expect to multiply by the 
channels count to get the pixel size not to divide the pixel size by the 
channel count.

If you consider, most of the imaging world has changed its pixel naming to 
a per channel base, it would be nice to see Cairo following this too.
It is pretty common to say 16-bit image processing, which means per 
channel. Or 8-bit monitor displaying, which is again per channel. The 
monitor LUT's are sometimes 10/12 or even 14-bit, again per channel.
The pixel numbers dont say anything about the colour resolution.

Why bit per channel instead of bit per pixel?
For instance a 16-bit Gray X-Ray image, properly displayed, can be 
superior compared to a 32-bit/pixel CMYK representation. In this case the 
numbers are non relevant to the lightness distinction. The example makes 
clear, what counts are the shades of gray.

Tricks like dithering dont count. Otherwise all people would still use 
indexed gif's for photos. But I dont any camera or scanner doing so.

On the other side a 32 bit chunck with 3*10 bit RGB inside would be harder 
to describe. Is such thing still in use for hardware and must be 
supported? At least it is not present in cairo_format_t. Out of scope?

Possibly someone can point me to a document describing the necessity of 
Cairos per pixel naming as is. Is it something to do with tradition?
Nethertheless the non selfexplanatory behaviour today makes it feel much 
like a pitfal.

To exemplyfy (a F stands for floating point):

colour bit/channel     bit/pixel  cairo_format_t sheme
RGB     8               24        CAIRO_FORMAT_RGB24
RGBA    8               32        CAIRO_FORMAT_ARGB32
Gray    8                8
GrayA   8               16
Alpha   8                8        CAIRO_FORMAT_A8
CMYKA   8               40
RGB    16               48        CAIRO_FORMAT_RGB48
RGBA   16               64        CAIRO_FORMAT_ARGB64
Gray   16               16
GrayA  16               32
CMYKA  16               80
RGB[A]... 16-bit float/channel use the same pixel size as the 16-bit per 
channel integers.
RGB    IEEE Half 16     48        CAIRO_FORMAT_RGB48F
RGBA   IEEE Half 16     64        CAIRO_FORMAT_ARGB64F
...
IEEE floats and 32-bit integers:
RGB    FLOAT 32         96        CAIRO_FORMAT_RGB96F
RGBA   FLOAT 32        128        CAIRO_FORMAT_ARGB128F
...
IEEE doubles:
RGB    DOUBLE 64       192        CAIRO_FORMAT_RGB192F
RGBA   DOUBLE 64       256        CAIRO_FORMAT_ARGB256F

The later can easily be confused with a 256 shades of Gray per channel 
naming.
Do you really expect a user to always divide the pixel values by 
the channels count to get an idea about the colour resolution.

To remember the marketing inflation of having 16 million colours and so on
is long gone away. Today it is in, to say a software supports 16-bit, 
which is much more meaningful. 
As a side step, manufacturers suggesting theire consumer camera to deliver 
the full range of 16-bit is still a joke. Such anouncements are 
demystified regularily.


Windows and osX have long inherited pixel naming conventions. 
Cairo as a young project does not. Cairo could express pixels much more 
close to our current language in cairo_format_t.

Lets end here and come to a suggestion for a new sheme:

CAIRO_FORMAT_ARGB32 -> CAIRO_FORMAT_ARGB_8
CAIRO_FORMAT_RGB24  -> CAIRO_FORMAT_RGB_8
CAIRO_FORMAT_A8     -> CAIRO_FORMAT_A_8
CAIRO_FORMAT_A1     -> CAIRO_FORMAT_A_1

#define CAIRO_FORMAT_ARGB32 CAIRO_FORMAT_ARGB_8
could ashure compatibility.

Later Cairo could add
CAIRO_FORMAT_ARGB_16  
CAIRO_FORMAT_RGB_16  
CAIRO_FORMAT_RGB_HALF 
CAIRO_FORMAT_RGB_FLOAT 
... and so on.


kind regards
Kai-Uwe Behrmann
--
developing for colour management
www.behrmann.name + www.oyranos.org

PS: Of course, I dont say RGB is sufficient for proper Cmyk passing.