Re: Thoughts about a new GdkPixbuf transform interface

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-02-19 at 08:03, Bill Haneman wrote:

> > typedef enum GdkPixbufEdgeMode {
> >   GDK_PIXBUF_EDGE_NEAREST,
> >   GDK_PIXBUF_EDGE_TRANSPARENT,
> >   GDK_PIXBUF_EDGE_TILE
> > };
> 
> Hmm, what about WRAP? If we had non-affine transformations this could
> matter, for instance if you are using FFT to do your transformations. 
> Is that what you meant by "TILE" ?

Yes, TILE means wrap. (Though I'd say that applicability of FFT based
methods only works for _affine_ transformations. If you have a
non-linear spatial transform, then you can't use a fourier transform.)

[...]

> >  - Making the "transform then render a portion   of the transformed object" 
> >    model explicit hopefully makes it easier.
> [not sure what you mean here I'm afraid]

The docs for gdk_pixbuf_scale() say::

 Creates a transformation of the source image @src by scaling by
 @scale_x and @scale_y then translating by @offset_x and @offset_y,
 then renders the rectangle (@dest_x, @dest_y, @dest_width,
 @dest_height) of the resulting image onto the destination image
 replacing the previous contents.

Nobody ever understood what that meant. I'm hoping that if you
have to write:

 gdk_pixbuf_transform_scale (transform, scale_x, scale_y);
 gdk_pixbuf_transform_offset (transform, offset_x, offset_x);
 gdk_pixbuf_transform_composite (transform, dest, 
                                 dest_x, dest_y, dest_width, dest_height);

the model will be clear.

> >  - Checks feature of composite_color() removed. Was a silly demo-app thing,
> >    and won't be significantly faster than just filling a destination
> >    pixmap.
> > 
> > Main problem I see with the proposal is the name ... not crazy
> > about GdkPixbufTransform; GdkPixbufCompositor was another idea,
> > but even long.
> 
> GdkPixbufXform ?  
> 
> As for "why do we need non-affine transforms", note that in effect we
> already have some implicit non-affine behavior in our smoothing types. 

Actually, all the current "smoothing types" fit perfectly into the model
of reconstruction-function affine-transformation sampling-function.
They aren't terribly _good_ filters, but they are mathematically 
simple.

> Alternatively we could have some kind of GdkPixbufFilter object, but
> some of the smoothing/filters really need source as well as target info.
> 
> For example, gnome-mag needs to do not only pixbuf scaling but various
> kinds of smoothing (for instance thresholding or font/image smoothing),
> since the blurring introduced by bilinear interpolation can reduce
> legibility of scaled text.  In the more general GdkPixbuf world, it'd
> allow us to plug various image processing doodads/algorithms into
> GdkPixbuf without having to hack into the pixbuf data from both source
> and dest, and post-process it (which is what is now required).
> 
> This would mean for instance that lots of GIMP filters could become
> GdkPixbufFilters (which would be special cases of GdkPixbufTransform).  
> 
> I guess what I'm suggesting is that GdkPixbufXforms be chainable and
> potentially non-affine, as well as user-subclassable, with a couple of
> trivial methods like 
> 
> gdk_pixbuf_xform_is_affine ()
> gdk_pixbuf_xform_get_matrix () [valid only for affine xforms]
> 
> and methods sufficient for overloading in subclasses like
> 
> gdk_pixbuf_xform_get_tile (xform, source, target, subregion_foo)
> 
> or something like that, which fills a subregion of 'target' from
> 'source' on demand.  Not sure what data struct to use for
> subregion_foo... 
> 
> I don't want to complicate this idea out of existance; but I think that
> providing this simple extension to the API would allow a simple
> implementation of affine transforms while also supporting user-supplied
> non-affine transforms (and eventual chaining of affine+non-affine
> transforms, pull-model tiled transformation, etc.).

So, the proposal is that the affine-and- transformation object
that I've proposed above would be just one implementation of generic
GdkPixbufTransform and we could have other types of GdkPixbufTransform
that did other operations?

It's not a ridiculous idea; there is a certain elegance to it.

Though:

 - It makes things considerably more complex

 - You have end up with a choice for the pipeline of:

    - Pixel based. Possibly incredibly slow and inefficient
      when you have steps that base one destination pixel
      on multiple source pixels.

    - Do the whole image at each step of the pipeline.
      Easy, fast, but you don't get any memory usage 
      savings over a simpler interface without filter
      chaining.
    
    - Tile based. Complex, complex, complex.

Regards,
                                             Owen