[magick-users] GIF Quantization (Rotating Images)

[Damien Dunlop]

> 
> From: Anthony Thyssen          \ Internet:    (anthony at griffith.edu.au)
> To:   ImageMagick              \ Internet:    (magick-users at imagemagick.
org)
> cc:   Damien Dunlop            \ Internet:    (djd at cmad.com.au)
> 
> Subject: Re: [magick-users] GIF Quantization (Rotating Images)
> 
> Damien wrote...
> |
> | > From: Elie Zedeck RANDRIAMIANDRIRAY
> | > and
> | > From: Pete Whatever
> | >
> | convert -size 1500x2000 xc: +noise Random A.gif
> |
> Yes I agree that this is far too slow! Especially with such a limited
> number of colors in the final solution.   A Q16 version of IM
> is probably even slower!
> 
> If you want to change this please be our guest and help!
> 
> Theorizing....  It is probably a data structure issue due to the number
> of colors in the original image.  The structure probably should be
> limited by the output limit.
> 
> Hmmmm prehaps the specialised   -treedepth   seting will help,
> You will have to ask Cristy (Magick on the forum) for info, as I myself
> do not understand how this effects quantization, only that it is an
> 'expert' setting for the implements process.
> 
> 
> | b) Another program is 70 times faster doing the same.
> |
> But it is not as general, batch drivable, and it is not free either!

No, I mean yes, I agree. I was just using it as an example to 
indicate there must be something not quite right. I am sure there 
are bugs in IM like every other software, including Paint Shop Pro.

> Then again, IM was not designed with 'palette' image preservation in mind,
> images are stored in memory as RGB images, not palette images, so as to
> avoid the limitations of a palette image.
> 
> 
> | c) If both input and output are gif as in this case,
> | colour quantizing should not be needed, but as you both suggest,
> | it is probably occurring - which may possibly explain other problems
> | (the post - `Colour Confusion').
> |
> That is not true.  -- and I should know!!!
> 
> Almost all distortions, whether it is a resize or a rotate, will
> generate lots of new color, unless they use a direct (and horrible)
> color sampling (nearest neighbor, or integer lookup).
> It is the nature of distortions, when you want to generate a high
> quality result!

OK. I thought a rotation would require no more than a relative
displacement of the original pixels, a maximum distance of
0.2 pixels for a 45 deg rotation - which may be significant
for a small image but I would have thought, relatively
insignificant for images of 1000x1000 or more. But, I have
never performed any qualitative analysis on such an issue.

Incidently, the post `Colour Confusion' operation does not 
involve distortion, just appending.
 
> For resize  -sample  will do this.
> for rotate use the -distort images without any interpolation...
> 
>    -filter point -interpolate NearestNeighbor  -distort SRT 30
> 
> I am thinking also of replacing the current  -magnify  operation
> (which is currently equivelent to  -resize 200%)
> with a 'scaleX2' type of resize...
>    http://scale2x.sourceforge.net/
> This has the properity of generating a nicer enlarged view of the image
> without generating extra colors, or generating a 'pixelated' look.
> It is designed specifically with palette images such as from older
> computer games.
> 
> All these methods will NOT generate new colors, and as such will
> not invalidate the existing image palette.
> 
> Of course I have not experimented with who well IM preserves of tests
> the existing 'palette' with the modified image, so I don't know
> how well this works.
> 
>     convert -size 1500x2000 xc: +noise Random A.gif
> 
> Just read and write the pre-quantized image
>     convert A.gif -taint  B.gif
> or  convert A.gif -sample 110%  B.gif
> 
> No quantization was needed, and few colors was present, so it was FAST!
> (0.5 seconds on my system)
> 
> How well this works, is another matter, as there is no way for IM to
> know if operation 'X' generated extra colors or not.  It isn't recorded.

I checked the palettes:

PSP palette after rotation = palette before rotation
Im palette after rotation has only one colour in
common with the palette before rotation - so lots of
changing going on. 

I must look at a rotated `quality' image to determine if
I can notice the difference between PSP and IM.

With the -taint and -sample, palette after = palette before
as you implied.