Legacy ImageMagick Discussions Archive

EWA originally only was used with Gaussian filters producing fairly blurry results (at that time there was also a code error (+ instead of -) that was later fixed). The destination pixel is reverse mapped to the source image to get the center of the ellipse. And yes it actually should not be the ...

How do you define "filter space" and how to you get your pixels into that space? The term is a bit loose, because of the fact that we don't scale distances to a [0, 1] range but a [0, support] range. That being noted, deriving filter-space depends on what coordinate frame you're defining its basis ...

The more I think about it, the more I think my comments on filter scaling just inadvertantly answered my own question...and everything else is falling into place too once I look at it from that perspective: Since EWA models a pixel's projection into source-space with an ellipse, it inherently uses a ...

Lancsos, I believe, and most cubic filters, in general use only a 4x4 neighborhood in the source domain for a given pixel in the output domain, unless you specify more lobes. So it is similar to EWA in the direction of processing, but uses a much limited size region to resample. Lanczos2 and cubic ...

The answer is a). It makes no sense to transform each pixel back to destination space where they all go to within the one pixel or so radius. Thus there is little if no distance to use for weighting. It has to be (gaussian) weighted in source space for all pixels that fall within the ellipse. Then ...

I think you misunderstood me: I'm not talking about weighting destination pixels...as you say, that's confusing concepts and makes no sense. I'm talking about weighting source texels depending on: Their distance from the source pixel in the source coordinate frame. ImageMagick needs to transform the ...

Ah, I see...well, crap. I guess I'll have to wait on Anthony for a definitive answer, but my followup question is this: If weights are computed based on distances in the source domain, is that because it's faster or easier to code, or is it necessary for correctness? (In my case it's a lot faster to ...

Thanks, I suppose the emphasis on "reverse mapping" answers question 2: The circle is projected into an ellipse in the source's coordinate frame, and the source texels are found by explicitly testing their locations against the source-space ellipse. That would explain why EWA doesn't work with crazy ...

By default, ImageMagick's distort operator often uses an "elliptical weighted average" of source samples to produce a destination pixel. I understand the concept on the most basic level: Project a circular pixel into the coordinate frame of the source, and you'll get an ellipse or similar conic ...

Oh, excellent! That's a good bit more convenient than the two-pass montage -> resize + crop solution. Thanks!

Thanks for the help, guys. -virtual-pixel tile sounds like what I want, but it doesn't seem to be working with resize. It might work with distort, but at the moment I'm specifically hoping to work with an orthogonal truncated sinc filter. To give an example of what I want, consider this source image ...

I'm wanting to resize some seamlessly tileable images in such a way that the results are also seamlessly tileable. The resize filter therefore needs to sample pixels beyond the image border in a wrapped/repeated/tiled fashion in order to prevent artifacts. I imagine a montage -> resize -> crop ...