"Feather"-ed optimization of animated GIFs

Questions and postings pertaining to the development of ImageMagick, feature enhancements, and ImageMagick internals. ImageMagick source code and algorithms are discussed here. Usage questions which are too arcane for the normal user list should also be posted here.
Post Reply
mtodorov3_69

"Feather"-ed optimization of animated GIFs

Post by mtodorov3_69 »

I had the idea of comparing images in animation sequence, doing the difference, and then statistically disregard some pixels that exhibited only minor change in color. It is nothing new, I think it is called "feather" in PhotoShop and GIMP!

The GIF animator in convert does wonderful job at preserving colors, but alas it created
1.4 MB animated GIF, which is unusable on web for a logo with simple rotating part.

In Adobe ImageReady, we (my colleague Darko and me) have succeded cutting region with rotating part manually, and ImageReady has reduced the size of animated GIF to 66 K.

However, none of automatic GIF optimizers including ImageReady's has succeeded doing any shrink automatic.

It could be because of some stray pixels changing outside of clipped region, that may render ImageMagick's convert tool fail optimizing these areas out.

See for yourselves:

http://www.grf.hr/~mtodorov/grf-logo/grf-logo3.gif (original, Imagemagick, 1.4 MB)

http://www.grf.hr/~mtodorov/grf-logo/grf-logo3A.gif (optimized manually, 66 K)

Since GIFs should be generated by a CGI automated tool, involving POV-Ray model with form-tuned parms, it would be impractical either to edit images manually (and impossible since CGI process in on-the-fly) and unacceptable to have 1.4 MB result for a simple animation.

MNG is also over-inflated, perhaps because of the same reason: stray chanign pixels. This could some irrelavant detail or strange reflection of rotating part in POV-Ray model, or anitalias ro jitter artifact (but jitter=0 was used!), I don't see exactly.

I cannot believe that ImageMagick does no attempt at reducing the image size. The proble is no automated optimizing tool works afterwards.

I am willing to offer my programming skills, as far as I find available time, but I guess you are wizards already and it is not a great task. Just a parameter with tolerance when choosing subrectangle that changed.

Thanks,
Mirsad
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Post by anthony »

I had the idea of comparing images in animation sequence, doing the difference, and then statistically disregard some pixels that exhibited only minor change in color. It is nothing new, I think it is called "feather" in PhotoShop and GIMP!

Actually 'feather' is using a band of semi-transparent pixels around an image cut out of a larger shape. However I understand what you mean.

In IM settin a -fuzz facter will do the
same thing. See the expert note in the latest IM animation basics page
for a 'difficult to optimise animation'...
http://www.cit.gu.edu.au/~anthony/graph ... im_basics/

I took great pains in recently debugging the color comparison function, especially for transparent and near transparent pixels, with regard to the fuzz factor, because a -deconstruct of this image fails without some sort of correct -fuzz handling.
The GIF animator in convert does wonderful job at preserving colors, but alas it created 1.4 MB animated GIF, which is unusable on web for a logo with simple rotating part.

You will now find that the latest IM will now correctly handle the GIF optimization of your animation which you previously had problems with.
If the frames are too large because of color differences, add a fuzz factor.

I would also perform something else too.. Reduce colors to a single globe color table. This is currently not a simple matter with IM, but techniques are
given (actually transfrom from 'specific animation examples' to animation basics' (the next item under the above link).
I am willing to offer my programming skills, as far as I find available time, but I guess you are wizards already and it is not a great task. Just a parameter with tolerance when choosing subrectangle that changed.

Wow. If so perhaps you can have a look at the "layers.c" module in IM
in the next beta release of IM when it comes out. (6.2.6-5) This should have my 'automatic frame doubling' optimization handling in it (-layers OptimizePlus).

After that I have quite a few more layer functions to add including 'make unchanged pixels transparent', and a 'shuffle' and 'compose' layers operator to allow the merging of two animation sequences together. :-)

Any ideas you have will be most welcome as work in this area has been lacking for a long time. Read the pages, then Email me, and we'll talk more.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
mtodorov3_69

Post by mtodorov3_69 »

Hi!

I have tried 6.2.6-4 and -fuzz, and it does optimize better.

Unfortunatelly, sometimes too great fuzz naturally creates visible artifacts in animation,
especially in raytraced shadows.

I reply this late because I wanted to make som eexperiments before making a quality proposal and suggestion on improvement of IM.

Please find here results of space optimization of the 640x480 same animation in GIMP 2.2
wtih reduction of colors:

size (bytes) number of colors in GIF
optimization yes/no (slow)

1353193 3phase-rmfr-noadd3-gimp-nodith255col.gif
1269956 3phase-rmfr-noadd3-gimp-nodith255col-opt.gif
1222840 3phase-rmfr-noadd3-gimp-nodith128col.gif
1120025 3phase-rmfr-noadd3-gimp-nodith128col-opt.gif
1201829 3phase-rmfr-noadd3-gimp-nodith127col.gif
1101767 3phase-rmfr-noadd3-gimp-nodith127col-opt.gif
995580 3phase-rmfr-noadd3-gimp-nodith063col.gif
857519 3phase-rmfr-noadd3-gimp-nodith063col-opt.gif
696367 3phase-rmfr-noadd3-gimp-nodith031col.gif
514940 3phase-rmfr-noadd3-gimp-nodith031col-opt.gif
623509 3phase-rmfr-noadd3-gimp-nodith023col.gif
458398 3phase-rmfr-noadd3-gimp-nodith023col-opt.gif
604682 3phase-rmfr-noadd3-gimp-nodith020col.gif
446825 3phase-rmfr-noadd3-gimp-nodith020col-opt.gif
502590 3phase-rmfr-noadd3-gimp-nodith016col.gif
352517 3phase-rmfr-noadd3-gimp-nodith016col-opt.gif
490497 3phase-rmfr-noadd3-gimp-nodith015col.gif
339936 3phase-rmfr-noadd3-gimp-nodith015col-opt.gif
480848 3phase-rmfr-noadd3-gimp-nodith014col.gif
329344 3phase-rmfr-noadd3-gimp-nodith014col-opt.gif
464489 3phase-rmfr-noadd3-gimp-nodith013col.gif
323528 3phase-rmfr-noadd3-gimp-nodith013col-opt.gif
434244 3phase-rmfr-noadd3-gimp-nodith012col.gif
312704 3phase-rmfr-noadd3-gimp-nodith012col-opt.gif
430965 3phase-rmfr-noadd3-gimp-nodith011col.gif
308579 3phase-rmfr-noadd3-gimp-nodith011col-opt.gif
378742 3phase-rmfr-noadd3-gimp-nodith010col.gif
263436 3phase-rmfr-noadd3-gimp-nodith010col-opt.gif
293180 3phase-rmfr-noadd3-gimp-nodith009col.gif
180206 3phase-rmfr-noadd3-gimp-nodith009col-opt.gif

At 9 colros and bellow image becomes of too low quality, so I did not investgate
any further.

I will try to EMPHASIZE that though GIMP does pretty good job at optimizing images,
something command-line is required for open-source rendering clusters, and my project leader thinks IM is a good choice.

So, reduction of colors would be a next step that seems to produce huuge savings in space.
GIMP succeds with optimized reduction of pallete to minimize impact on picture quality.

Dithering, however, is ugly, and it destroys compression!

BTW, my copy of IM 6.2.6-4 did not seem to compress images, even with -compress. Is there a switch to turn in on? (Both zlib and bzlib were installed prior to compilation).

I hope this helps and offers some useful iformation. If someone is interested, I can continue experimenting with color reduction.

Adobe ImageReady does some "lossy" compression on GIFs too, increasing further compression in first 10% to 25% of losiness, but I don't know how this works.

It achieves also greater comrpession by selecting a "perceptive" pallete reduction instead of web or selective. (Web give poor quality of animations).

Using transpaernt pixels also improves comrpession by 10% to 30% in both AIR and some freeware like GIFOPtzr.exe

Regards,
Mirsad

PS. I will take a look into layers.c module.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Post by anthony »

Does your image have transparency parts?

Did you reduce the image to a single color table BEFORE the initial save to GIF.
Doing this should avoid most color comparasion problems.

Last friday I finished documenting the color comparistion problems as part of gif animation optimization. I do mention that if you reduce colors of ALL images to a common color tabel BEFORE the inital save to GIF you will get the first BIG improvment in image size and generally solve image comparision faults.

I'll check over the new tutorial and try to make this clear in an 'experts' box.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
mtodorov3_69

Post by mtodorov3_69 »

Yes it would greatly benefit to ducoment it since it is still not clear to me how to do it in IM 6.2.6-4.

In GIMP I would reduce colors when converting to INDEXED palette, BEFORE optimization for GIF and BEFORE saving as GIF.

Frankly, I don't know how to do the same in IM, and there is a lot of room for color optimization since the animation is from POV-Ray.

56 K modem download times of pages aare poor (meaning very long), and some means of better optimization should help. If this is already documented, then I am sorry I bother you. I fit is or when it will be I will try ot make a color reduction/size optimization table similar to that of GIMP.

In particular, how to convert to single global color table is not clear to me.

I see the commands -colors and -colorspace, but I am sort of lacking "feeling" for internal IM's style of work with options... I will do some more research today. I hope the GIMP optimization numbers were useful.

Regards,
Mirsad
mtodorov3_69

Post by mtodorov3_69 »

P.S. Image does not have transparent parts re: background of the page, but GIMP uses transparency when optimizing and it seems to help him do better.

M.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Post by anthony »

Yes it while it does not reduce the actual number of pixels in the animation, it vastly improves the compression that the GIF LWZ compression achieves.
Basically it finds more continuous and repeatable sequences of color indexes, thus producing a higher compression.

This optimization is being added to IM. I just need to polish the programming of it.

I have in fact already written up the tutorial to cover the addition..
http://www.cit.gu.edu.au/~anthony/graph ... #opt_trans

I have even written a bit on LWZ compression which is a mix of transparency and overlay pixels (for pixels that don't change) which is designed to produce even better LWZ compression. This form of compression will not be written into IM unless someone who knows a lot about LWZ compression likes to contribute.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
mtodorov3_69

Post by mtodorov3_69 »

I will have to do some automaterd testing today about color reduction.

In fact, half-automated since images have to be insepcted visualy for artifacts before submitting to production web site to establish the maximum feasibl ecompression and best size reduction/quality rate.

Is there a way to automatize this too.

I.e. -fuzz may do better in YUV space, since eye is much more sensitive to changes in illuminaition taht to hue change?

I had optimizations, and shadows optimized poorly, leaving strange trails unconnected to main shadow. (I don't know exact word in English, sorry).

2. When I was thinking few days ago, I thought of having also an optimon about not allowing single pixel or small group of pixels to extend the area of frame beyodn what id required to visually perceive image w/o error.

IMHO there should be a way to estimate error in picture the way eye sees it. I know some people from Chair for reproduction photography so maybe they could have some theoretic idea.

Some sort of "mean square algorythm" for cumulative error should be used, but in terms of perception of colo(u)r. Meaning for example that vconversion to YUV should be used for each pixel before estimating the error since error is best seen in YUV colorspace.

Also some other graphic industry tricks. There should be a way to leave IM to optimize colors as long as the visual perception of image error becomes higher than a threshold. Don't be scared, I think that's ratehr easy toimplement once we have the MEASURE of error. And provided you find it worthwhile and find time.

M.
User avatar
anthony
Posts: 8883
Joined: 2004-05-31T19:27:03-07:00
Authentication code: 8675308
Location: Brisbane, Australia

Post by anthony »

I do know that -fuzz color matching can do it in CMYK space, but I think
you have to convert the image from RGBA default to CMYK. Probably with -colorspace

No gurantees at this point however. Let me know how it works.
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
User avatar
glennrp
Posts: 1147
Joined: 2006-04-01T08:16:32-07:00
Location: Maryland 39.26.30N 76.16.01W

Post by glennrp »

There's a free application called "intergif" which might be useful to you as a final optimization step. I haven't used it lately but had good luck with it in the past.

Glenn
Post Reply