[cairo] [RFC] high-quality pixman image downscaling

[Jeff Muizelaar]

I've added the cairo list back to the cc.

On Mon, Jul 06, 2009 at 07:15:43PM -0700, Bill Spitzak wrote:
> Jeff Muizelaar wrote:
> 
> >>The api you designed does not allow an arbitrary integer division to be 
> >>specified as you can only do original_width/integer values and thus the 
> >>only integer scales allowed are factors of both the width and height. I 
> >>would change this to a pair of integers (the scale is then 1/x,1/y, and 
> >>there is certainly no rounding problems).
> >
> >I don't understand this comment. The scaled size is specified by
> >scaled_width/scaled_height. What limitations does this have?
> 
> It cannot specify an integer scale that is not a divisor of the original 
> size. The nearest integer scale is not likely to be a divisor of the 
> image width and height.

I understand what you mean now. Can you explain what the advantage of
this would be? 

Currently the scaling code is designed around scaling to
an integer number of pixels. The plan for scaling to an integer scale
that is not a divisor would be to go through the two pass algorithm.
i.e. scale to the nearest integer number of pixels and then resample
that to desired size.

> 
> >>A big problem is edge repeat. To allow algorithims like you are 
> >>suggesting requires "repeat" handling of the edges of all images ALL THE 
> >>TIME.
> >
> >Only the lanczos algorithm requires any edge handling. Currently, the
> >code truncates the filter and therefor will not sample outside of the
> >image.
> 
> I think there may be some confusion on either my or your part, as the 
> need to handle box filters that extend outside the source image, and the 
> need to handle scale factors that don't evenly divide the size of the 
> image, are related.

The current box filters never extend outside the source image. Scale
factors that don't evenly divide the size of the image are handled by
two different strategies:
1) the box filter size alternates between two integer values such that
there is no extension
2) the box filter size is not an integer

> Not sure what "truncated" means. I think the only allowable results are 
> to act as though those portions of the filter are multiplied by 
> edge-repeated pixel values (either the nearest edge, or black, or mirror 
> or tiled versions of the image). If you are acting like the filter is 
> smaller and only the part that interesects the image, this is not good 
> as it produces artifacts where it acts somewhat like repeat but the 
> repeated color varies depending on how much the filter is inside the image.

Currently the code acts the like the filter is smaller. Can you explain
the artifacts and the problems with them further? Google Chrome uses
this strategy and I've not noticed any problems there.
> 
> >>"black outside" is much better done by clipping in the transformed 
> >>coordinate system so the edge is sharp for any scale or transform, which 
> >>is what all users expect and what most other interfaces such as Quartz 
> >>provide.
> >
> >I think everyone agrees this is the behaviour that users expect.
> >Developing an efficient design/implementation is the trickier part.
> 
> I don't know if it is efficient but Cairo currently produces the correct 
> image if you set the image sampling to repeat and make a path that is 
> the transform of the image border and clip to it before drawing the image.
> 
> I suspect that removing the need to decide what type of padding is being 
> done by the sampling will make it more efficient and thus a good first step.

We still need to support the different other repeat types so removing
REPEAT_NONE doesn't help much. Doing the clip efficiently is probably
the more interesting part.

-Jeff