Well, you can just add the -coalesce option to your original resize command. I don't think you need a separate command.
I can't access the page that you are talking about, so, maybe you can put an example of your problem somewhere accessible?
Resizing animated gifs
-
anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
IM Examples and GIF animation Resizing update...
As I have mentioned on the IM examples, resizing gif animations has a number of problems.
The simplist method is to scale the image instead, but the result can be far from desirable.
First when you resize an image using -resize, IM attemtps to smooth the image using various filters
http://www.cit.gu.edu.au/~anthony/graph ... e/#filters
For it to do this well, IM needs to see all the colors within each frame of the image, as such you need to -coalesce the image before resizing.
This color smoothing addes lots of extra colors to an image and GIF images have a limited color set, and boolean transparency. A very big task.
When an image with transparency is also resized, you will get lots of semi-transparent pixels which depending on your version of IM will result in unpredictable result. Basically GIF can't handle semi-transparent pixels so IM needs to do something with them, and that is very dependant on IM version.
http://www.cit.gu.edu.au/~anthony/graph ... ats/#trans
The best idea is to handle GIF transparency after resizing but before performing any color quantization, to reduce the number of colors to fit the result back into a GIF animation (see the above).
However for animated GIF's you not only need to reduce the colors to allow the image to fit into a GIF image file format, but you need to reduce the colors of all the frames to the same color table, or you will get different problems.
First each frame will have a different color table, and that costs a lot in terms of the final image file size. Secondally as different color tables were used for each frames, a pixel of a specific color may map to different colors in different frames, resulting in that pixel changing color, when it is actually the same color.
To fix that you have to do the color reducion, as a single image, so a single color table will be generated for all frames. This is known as quantization and IM examples just produced examples in this area in the last coupleof days
http://www.cit.gu.edu.au/~anthony/graph ... or/#colors
This color table is then applied as a mapping to each individual frame, so all frames get the same color pallette. See GIF color table optimization
http://www.cit.gu.edu.au/~anthony/graph ... ics/#color
NOTE: this is best done to the images BEFORE they are saved (and color reduced) to GIF format, so keep the intermedite images as MIFF or PNG format untill this is done. Their is also the selection of the 'quantize' colorspace to consider in this step.
http://www.cit.gu.edu.au/~anthony/graph ... /#quantize
Now we have another matter that needs to be addressed, dithering. As the number of colors in an image is limited IM will by default dither the color mapping into the images, producing a pattern the the eye sees as a different color, that what is actually used. See for example
http://www.cit.gu.edu.au/~anthony/graph ... color/#map
The problem is that this dither pattern by default is a semi-randomized pattern, and a small change in a image will produce a diffferent pattern.
For an animation that mean that the pixel pattern changes enormously from one frame to the next producing a very poor optimization on images containing color gradients, or other color mixing.
The solution to this is the use of some type of ordered color dithering, unfortunatally this is a aspect I am currently studing under IM so I can't give a example of how this is done.
Sorry!
What I have this final piece of the resize and color handling puzzle for GIF animations, the 'How to Resize GIF animations' Section will be filled in and completed.
The above now replaced the current 'Under Construction' Resize GIF animation section
http://www.cit.gu.edu.au/~anthony/graph ... ns/#resize
As I have mentioned on the IM examples, resizing gif animations has a number of problems.
The simplist method is to scale the image instead, but the result can be far from desirable.
First when you resize an image using -resize, IM attemtps to smooth the image using various filters
http://www.cit.gu.edu.au/~anthony/graph ... e/#filters
For it to do this well, IM needs to see all the colors within each frame of the image, as such you need to -coalesce the image before resizing.
This color smoothing addes lots of extra colors to an image and GIF images have a limited color set, and boolean transparency. A very big task.
When an image with transparency is also resized, you will get lots of semi-transparent pixels which depending on your version of IM will result in unpredictable result. Basically GIF can't handle semi-transparent pixels so IM needs to do something with them, and that is very dependant on IM version.
http://www.cit.gu.edu.au/~anthony/graph ... ats/#trans
The best idea is to handle GIF transparency after resizing but before performing any color quantization, to reduce the number of colors to fit the result back into a GIF animation (see the above).
However for animated GIF's you not only need to reduce the colors to allow the image to fit into a GIF image file format, but you need to reduce the colors of all the frames to the same color table, or you will get different problems.
First each frame will have a different color table, and that costs a lot in terms of the final image file size. Secondally as different color tables were used for each frames, a pixel of a specific color may map to different colors in different frames, resulting in that pixel changing color, when it is actually the same color.
To fix that you have to do the color reducion, as a single image, so a single color table will be generated for all frames. This is known as quantization and IM examples just produced examples in this area in the last coupleof days
http://www.cit.gu.edu.au/~anthony/graph ... or/#colors
This color table is then applied as a mapping to each individual frame, so all frames get the same color pallette. See GIF color table optimization
http://www.cit.gu.edu.au/~anthony/graph ... ics/#color
NOTE: this is best done to the images BEFORE they are saved (and color reduced) to GIF format, so keep the intermedite images as MIFF or PNG format untill this is done. Their is also the selection of the 'quantize' colorspace to consider in this step.
http://www.cit.gu.edu.au/~anthony/graph ... /#quantize
Now we have another matter that needs to be addressed, dithering. As the number of colors in an image is limited IM will by default dither the color mapping into the images, producing a pattern the the eye sees as a different color, that what is actually used. See for example
http://www.cit.gu.edu.au/~anthony/graph ... color/#map
The problem is that this dither pattern by default is a semi-randomized pattern, and a small change in a image will produce a diffferent pattern.
For an animation that mean that the pixel pattern changes enormously from one frame to the next producing a very poor optimization on images containing color gradients, or other color mixing.
The solution to this is the use of some type of ordered color dithering, unfortunatally this is a aspect I am currently studing under IM so I can't give a example of how this is done.
Sorry!What I have this final piece of the resize and color handling puzzle for GIF animations, the 'How to Resize GIF animations' Section will be filled in and completed.
The above now replaced the current 'Under Construction' Resize GIF animation section
http://www.cit.gu.edu.au/~anthony/graph ... ns/#resize
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/
-
anthony
- Posts: 8883
- Joined: 2004-05-31T19:27:03-07:00
- Authentication code: 8675308
- Location: Brisbane, Australia
I am sorry but resizing GIF is too complex a matter.
You can download the src.rpm file and build a new RPM
I do this nearly every day.
This is what I use to generate new IM rpm and perl IM rpm
You can download the src.rpm file and build a new RPM
I do this nearly every day.
This is what I use to generate new IM rpm and perl IM rpm
Code: Select all
rm -rf /usr/src/redhat/RPMS/*/* /usr/src/redhat/{SOURCES,SPECS,BUILD}/*
rpmbuild --nodeps --rebuild ~/dl/ImageMagick-*.src.rpm
rpm -Uhv --force --nodeps /usr/src/redhat/RPMS/i386/ImageMagick-[6p]*.i386.rpm
cp /usr/src/redhat/RPMS/i386/ImageMagick-[6p]*.i386.rpm ~/dl/
chown anthony ~/dl/ImageMagick-*
rm -rf /usr/src/redhat/RPMS/*/* /usr/src/redhat/{SOURCES,SPECS,BUILD}/*
Anthony Thyssen -- Webmaster for ImageMagick Example Pages
https://imagemagick.org/Usage/
https://imagemagick.org/Usage/