> "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/gra
phics/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/graphi
cs/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 )
<A.Thyssen griffith.edu.au>
>
------------------------------------------------------------
-----------------
> It is a pretty smart tree that can outsmart the
average kite flyer.
> ---
Gary
> <gengvallaol.com>
>
------------------------------------------------------------
-----------------
> 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-usersimagemagick.org
http://studio.imagemagick.org/mailman/listinfo/magick
-users
|