Conclusions and questions for ds/bilboed of YUV-in-pixman discussions
at the video hackfest:

* The color conversion matrix is different from format to format. Is
  it ever the case that two formats are the same, except that the
  matrix is different? Or will the name always imply a particular
  matrix?

  Benjamin says that the name does indeed always imply a particular
  matrix.


* Chroma samples have a defined location; it may be different from
  video codec to video codec.

  I believe ds said that it would be fine to use an enum value for
  each format as opposed to trying to exhaustively describe all the
  YUV formats.

  This implies that the chroma shift is embedded in the name.

  Is there a standard way of referring to chroma shifts?


* When there is chroma subsampling, when converting to RGB, we need to
  interpolate. The quality of this interpolation is determined by the
  filter that is set on the image:

     - pixman_filter_neareest:

       for each destination pixel determine location in source. Then
       take the nearest luma/chroma samples and apply the matrix.

     - pixman_filter_bilinear:

       for each destination pixel determine location in source, then
       determine the four closest luma samples and the four closest
       chroma samples, then bilinearly filter those and apply the
       matrix.

     - pixman_filter_convolution:

       for each destination pixel
       	   s = location in source

	   find nearest luma sample 

	   align midpoint of convolution kernel with that sample

	   for each pixel in convolution kernel, 	   
	       find nearest luma sample, apply weight, add to sum
	       find nearest chroma sample, apply weight, add to sum
	   
	   color convert the average


* When YUV formats are added to cairo, cairo will need to set
  pixman_filter_bilinear on a YUV pattern, even when there is no
  transformation.


* Planar formats will be handled with something like this:

  	 pixman_image_create_bits (format, char **planes, int **rowstrides);


* If you pass NULL for plane data, the bits will be 0 and not
  black. This is actually already the case because it's somewhat
  unclear what a premultiplied (0, 0, 0, 0) ARGB pixel actually is.


* Writing to YUV formats:

  - Need some thought

  - How does it relate to a hypothetical
    pixman_image_set_resampling_filter?