image linktypes for gephex-0.5 and img-lib

Yesterday I talked with martin about the linktype
for images in gephex-0.5.
Motivated by the discussion in the freeframe mailinglist,
we decided to add a pitch attribute
(= number of one row in bytes), to make it possible
to align the rows of an image.

Martin also had the idea to add an offset attribute which
would tell the offset of the first pixel from the
start of the pixel array (allowing to efficiently
operate on subimages).
I can see the use of that attribute for an image library, but I'm not
quite convinved yet that it is usefull for an image linktype
(can't think of a plugin that would use it).

Another idea was to have only two distinct image linktypes:
one for packed pixel formats and one for planar pixel formats.

   * the linktype for packed pixel format would have the following
     attributes:
        int   color_model   (BGRA32, YUV444, ...)
        int   bpp
        int   pitch          lenght of one row in bytes
        int   width
        int   height
        int   offset         offset of the first pixel (in bytes)
        byte* pixels         first pixel starts at pixels + offset

      Note that the information in bpp is actually redundant, since
      color_model should already specify it.
      We also need to define which color models we support
      (for example, I don't think we should support packed yuv support,
       where the sample-rate for y, u, and v differs). Also, I would
      not want to include fields like rmask, gmask, bmask for RGB
      formats.


   * the linktype for planar pixel format would have the following
     attributes:
        int   color_model   (YUV422, ...)
        int   bpp[3]
        int   pitch[3]       lenght of one row in bytes
        int   width
        int   height
        int   offset[3]      offset of the first pixel (in bytes)
        byte* pixels[3]      first pixel starts at pixels + offset

      Does anybody think we could need more than 3 planes?

Another possible attribute (it's in freeframe) is orientation,
which specifies if the rows are stored top-down or bottom-up.
I'm not sure we should use it, however (sticking to one
orientation simplifies things, and the advantage of a flexible
orientation is not obvious to me).

The disadvantage of these flexible image linktypes is that each unit
that accepts images has to deal with a variety of color models.
To keep units simple, we want to develop an external library
(starting from the current libscale), which has the following
components:

    * functions for color-model conversion of images
    * functions for scaling of images in different formats
    * maybe functions for simple color-conversions
      (change brightness, contrast, gamma, saturation...)
    * a high-level layer which provides a simplified access
      to the lowlevel functions above (it should understand
      commands like "I want this image scaled to 340x240 and
      converted to BGRA32" and execute them efficiently in
      terms of low-level functions).

Defining images this way it should be possible to write plugins
that do geometric tranformations on any kind of packed image
(by simply moving pixels). However, if you want subpixel accuracy,
that's a different story...

Any comments?

Georg