Re: image linktypes for gephex-0.5 and img-lib

Georg Seidel wrote:
> 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).

Most effects use the image link type format and the helper functions 
also for internal stuff. A puzzle effect should could divide the input 
and output image  in sub images and use the efficient image copy code to 
copy them.

> 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?

yes alpha could be an additional plane,


Hm, i think it should be possible to unify both. This would enable slow 
but generic converters.

void*  data;
size_t data_size;
--
size_t width;   // of image in pixels
size_t height;  // of image in pixels
--
int   color_model;  // (YUV, YUV (MPG), RGB, RGBA, G(RAY))
                     // and order of layers
                     // permutation is possible with offset

{ // for each layer
size_t bbp;           // (1,8)
size_t subsampling_x; // for yuv420  this is 2 in the uv layers
size_t subsampling_y; // and one in the y layers
size_t pixel_offset;  // distance to neighbor pixel in bpp
size_t offset_pixel;  // for data to first pixel of that layer in bpp
size_t offset_row;    // length of one row in bpp
}

> 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).

Could be implemented with negative pixel offsets.

It seems that GePhex entered again an overengineer period :)

Martin

_______________________________________________
gephex-devel mailing list
[email protected]
http://lists.gephex.org/mailman/listinfo/gephex-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBLG9dCm3i57PRsbsRAhTMAKCe5GEKoLFvMzNHDK/yCctCbKA5+QCdFdb3
zZWImZGLiFUqLk1HdfA+/vE=
=D94l
-----END PGP SIGNATURE-----