Legacy ImageMagick Discussions Archive

The resizes which don't involve the resample code (a.k.a. distort) methods simply only give weights to the points within the support which actually are within the image (this is not equivalent to using the nearest neighbour a.k.a. smear abyss policy). This is like chopping off the piece of the kerne...

Nicholas, Not sure I follow all this, but it looks like how the filter kernel is extended at the edges of the image or more precisely how the image is extended so that a full kernel can be use. I am not absolutely sure -resize works with -virtual-pixel, but -virtual-pixel allows one to extend the i...

I'll get going on this slowly. There are, actually, three desirable behaviors: corners (current behavior, and default; it extrapolates when upsampling) centers (it extrapolates when downsampling) and switch (mix and match depending on whether one is enlarging or downsampling in each direction; it ne...

Things are a bit different for man-made images, because generally they are made with a priori awareness of the total extent of the image. For such (the dragon picture, say) I could understand one preferring the current IM default (match corners) even when enlarging, because it is better at preservin...

Here are some examples of the difference between the two image size conventions (done with my first private pass at changing the code): The 8x enlargement of the IM built-in rose picture: convert rose: -resize 560x560 rose_corners.png resulted in http://web.cs.laurentian.ca/nrobidoux/misc/rose_corne...

Note however that the difference jumps at you when enlarging a small image.

1) Personal/professional: To do careful quantitative comparative testing of resampling methods, it is preferable to be able to switch image size convention (because some methods are more "friendly" to one or another of the conventions, and this levels the field; there is another reason, ha...

I'm going to take my time on this: I'm realizing now that to do this just right, I need to be extremely careful. It's not only the sampling positions that need to be changed, but also the way the filter kernel is scaled depending on the "resize factors." And there are other things to doubl...

I'll wait until I have a substantial quiet block of time to make changes. The "new" IM resize is more complex than the old version on which I did this switch years ago.

Opinions: A switch would be nice. The default should be: For resize, switch depending on what is done in each direction (so, when enlarging in one direction and reducing in the other, both conventions would be used, depending on the direction). For everything else, "match corners" (the cur...

Notation: When resizing, the sampled (input) image has m rows and n columns, the output image has M rows and N columns, output pixels are indexed with (I,J) with 0<=I<=M-1 and 0<=J<=N-1, and coordinates are set so that they equal the index right at a pixel location. (x,y) is a position in the "...

Chantal Racette would like to point out that she is "only" a Masters student.

It appears that ohloh stopped understanding the svn link for imagemagick in February or so. Maybe changing the download server link to the one used by Anthony would fix that? (It's not a great tragedy if ohloh does not update, but it's nice if it does.) Cristy is the ohloh imagemagick manager.

anthony wrote:I have been using
svn co https://magick.imagemagick.org/subversi ... gick/trunk .
for years to get the development tree.

Well, well, well.

This works without chenanigans \o/

LanczosFast is gone as of version 2684. Update to SVN version 2685... Removed LanczosFast from filter types and command line option parsing "resample.h" and "option.c" respecivally Added comment in ChangeLog for svn 2686 Apologies (I know better): I forgot to do a "find&quo...