> "Ian" on wrote...
> | Currently, I've got code like this:
> | --cut--
> | #!/usr/bin/perl
> |
> | use warnings;
> | use strict;
> | use Image::Magick;
> |
> | my $image = Image::Magick->new();
> | $image->Read('testimage.jpg');
> | $image->Set(antialias=>'False');
> | --cut--
> |
> | Whenever I do a rotate, antialias still seems to mung up the image... It
> | get worse with consecutive rotates:
> |
> | --cut--
> | #for a blurry mess:
> | for (my $i=0; $i<45; $i++)
> | {
> | $image->Rotate(degrees=>1);
> | }
> | --cut--
> |
> | I was wondering if there was a way to turn off antialiasing for
> rotation,
> | or a different method to rotate an image w/o otherwise altering the
> data?
>
> The anti-aliasing involved with rotation isn't actually anti-aliasing,
> but a merging of parts of the pixels that go to making up the new pixel
> after the rotation.
>
> There are three ways a rotation can select colors.
> 1/ Just take the color of the point that equates to the roated image
> This will never add new colors to an image, but some pixels may
> be duplicated, will other pixel may not ne used in the final
> image. Eg you loose information.
>
> This is what happens in the "-fx" 'distortion mapping technique
> http://www.cit.gu.edu.au/~anthony/graphics/imagick6/distorts/#position_maps
>
> You could apply this method for implemented you 'aliased
> rotations'. I even have an example of a 45 degree rotation.
> It is however slow, and it is basically a DIY, rotation using
> lookup maps.
>
> 2/ You can select the color of the point by mixing the colors of the
> four pixels involved with this point in the new image (weighted
> apporpaitally by distance). This is called Interpolation.
>
> It also is not exact, and can produce errors and morie effects.
>
> Currently this is the only method used for 'Displacement maps'
> See
> http://www.cit.gu.edu.au/~anthony/graphics/imagick6/compose/#displace
>
> 3/ The totally correct method is to reverse map the area of the
> pixel you are trying to color in, back onto the original image
> and figure out the amount of color that maps from the orignal
> image into that pixel area. This is what IM does, and it does
> produce the most correct results.
>
> This is what was recently implemented onto Affine Transformations
> (which can do rotations)
>
> http://www.cit.gu.edu.au/~anthony/graphics/imagick6/distorts/#affine_rot
>
> So you see, rotations don't have anti-aliasing.
> It only seems like it does :-)
>
> PS: remember anything you do on the command line should be translatable
> somehow into a API such as PerlMagick.
>
>
> Anthony Thyssen ( System Programmer ) <[EMAIL PROTECTED]>
> -----------------------------------------------------------------------------
> It is a pretty smart tree that can outsmart the average kite flyer.
> --- Gary
> <[EMAIL PROTECTED]>
> -----------------------------------------------------------------------------
> Anthony's Home is his Castle http://www.cit.gu.edu.au/~anthony/
>
Btw,
>From the #position_maps page you referenced:
"The final problem is that by creatng our distortion maps using rotates,
we introduced some anti-aliasing to some of the diagonal edges."
Looks like I wasn't the only one fooled by thinking that anti-aliasing is
used with rotates! :)
With OpenGL or DirectX, there is the idea of a "camera view" when working
with an image. Is there anything like this for ImageMagick?
Finally, since I'm dealing mostly with grayscale images, would changing
the number of colors to 2 (white and black) avoid the merging of pixels
problem for a rotate? I've tried:
$image->Quantize(colors=>2,colorspace=>'Gray');
as well as
$image->WhiteThreshold(threshold=>127);
$image->BlackThreshold(threshold=>127);
but that doesn't seem to change the number of colors the way I was expecting.
_______________________________________________
Magick-users mailing list
Magick-users@imagemagick.org
http://studio.imagemagick.org/mailman/listinfo/magick-users
