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

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

But the helper functions would be implemented in a separate lib.
So it is not necessary to store an offset in the linktype. It's enough
to pass an offset parameter to the helper functions.

>>
>>   * 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,

Hmm, right.

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

Yes, obviously that's possible. But I don't think it's desirable.
For example, I can imagine an effect that works equally well on all
packed pixel formats (as long as the subsampling of each component is
equal, which I assume), but it's harder to imagine effects that
work well on all kinds of planar formats _and_ packet formats.

To keep things simpler, I would create separate linktypes. The planar
type would be rarely used, maybe for stuff like vector-fields.

> It seems that GePhex entered again an overengineer period :)

:)

Georg