Hi
Sven Neumann wrote:
> As already explained in my previous mail, the decimation routines are
> only used for the pre-scaling steps. As soon as the image is close
> enough to the final size, the chosen interpolation routine is used. This
> gives continuous results for all scale factors as there is no longer any
> special casing for scaling down by 50%.
What I don't understand is why there's a need to interpolate at all in
the case of scaling an image down. When scaling up, interpolation is
used to estimate missing information, but when scaling down there is no
missing information to be estimated - the problem is instead finding the
best strategy for *discarding* information.
What I do in PhotoPrint is just use a simple sub-pixel-capable box
filter - which is what your current approach
(scale-by-nearest-power-of-two, then interpolate) is approximating.
The routine looks like this:
// We accumulate pixel values from a potentially
// large number of pixels and process all the samples
// in a pixel at one time.
double tmp[IS_MAX_SAMPLESPERPIXEL];
for(int i=0;i<samplesperpixel;++i)
tmp[i]=0;
ISDataType *srcdata=source->GetRow(row);
// We use a Bresenham-esque method of calculating the
// pixel boundaries for scaling - add the smaller value
// to an accumulator until it exceeds the larger value,
// then subtract the larger value, leaving the remainder
// in place for the next round.
int a=0;
int src=0;
int dst=0;
while(dst<width)
{
// Add the smaller value (destination width)
a+=width;
// As long as the counter is less than the larger value
// (source width), we take full pixels.
while(a<source->width)
{
if(src>=source->width)
src=source->width-1;
for(int i=0;i<samplesperpixel;++i)
tmp[i]+=srcdata[samplesperpixel*src+i];
++src;
a+=width;
}
double p=source->width-(a-width);
p/=width;
// p now contains the proportion of the next pixel
// to be counted towards the output pixel.
a-=source->width;
// And a now contains the remainder,
// ready for the next round.
// So we add p * the new source pixel
// to the current output pixel...
if(src>=source->width)
src=source->width-1;
for(int i=0;i<samplesperpixel;++i)
tmp[i]+=p*srcdata[samplesperpixel*src+i];
// Store it...
for(int i=0;i<samplesperpixel;++i)
{
rowbuffer[samplesperpixel*dst+i] =
0.5+(tmp[i]*width)/source->width;
}
++dst;
// And start off the next output pixel with
// (1-p) * the source pixel.
for(int i=0;i<samplesperpixel;++i)
tmp[i]=(1.0-p)*srcdata[samplesperpixel*src+i];
++src;
}
> The main problem with the code in trunk is though that I think that the
> results of the new code are too blurry. Please have a look at the tests
> that I published at http://svenfoo.org/scalepatch/. And please try the
> patch and do your own tests.
The slight blurriness comes, I think, from performing the scaling in two
distinct stages. Just for kicks, since I had a rare spare hour to play
with such things, here are versions of the 3% and 23% test from your
page, for comparison, scaled using the downsample filter whose core is
posted above:
http://www.blackfiveservices.co.uk/3Percent.png
http://www.blackfiveservices.co.uk/23Percent.png
Hope this is some help
All the best,
--
Alastair M. Robinson
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
