Bugs item #1776135, was opened at 2007-08-17 03:18 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=757416&aid=1776135&group_id=144022
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Render Artifact Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: dooglus (dooglus) Assigned to: Nobody/Anonymous (nobody) Summary: gif rendering has several problems Initial Comment: 1. some frames have pixels rendered as transparent when they shouldn't be. the code is checking whether the index to the pixel's color in the palette has changed from one frame to the next, and setting it to be transparent if it hasn't. the problem with this is that the palette changes from frame to frame, so we need to check whether the color of the pixel has changed, not the index into the palette. this code is in synfig-core/src/modules/mod_gif/trgt_gif.cpp - just after the comment saying "lossless version" 2. the code which creates the palette for each frame does so by randomly looking at a limited number of pixels in the image and using those colors. in simple images with less than 256 different colors, this almost always results in the palette missing some of the colors that are present in the rendered scene, even though there is space for them in the palette. I've seen cases where an image contains 30 different colours in its .png version, but when rendered to .gif it contains only 4 colours, due to the random sampling not stumbling upon any pixels of the other 26 colours (since they are rare, and only used around the edge of shapes, for anti-aliasing). this code is in synfig-core/src/synfig/palette.cpp - search for rand() 3. there is a hardcoded option in the gif rendering code to enable or disable 'dithering' - a technique where errors due to palette limitations are distributed to surrounding pixels. the idea is that if one pixel is too red, due to the desired color not being present in the palette, then the neighbouring pixels should be made slightly less red than desired to compensate. when combined with (2) above, this can lead to large messy artifacts ( see http://dooglus.rincevent.net/synfig/dither-artifact.gif ) - those 2 circles are supposed to be of uniform colour, but because some of the colours used for anti-aliasing were missed from the palette, the dithering has spread a few shades of slightly darker red diagonally down through the red circle. I would expect the effect of dithering to die out within a few pixels, but as can be seen, it doesn't. this code is in src/modules/mod_gif/trgt_gif.cpp - search for "if(dithering)" ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2012-03-23 11:03 Message: rf7IgL Thanks-a-mundo for the article.Really thank you! Will read on... ---------------------------------------------------------------------- Comment By: dooglus (dooglus) Date: 2008-02-11 03:56 Message: Logged In: YES user_id=1546005 Originator: YES There's a new target called 'magick++' which uses the ImageMagick library to create gif images. It does a much better job than synfig's own 'gif' target and is now the default for rendering to .gif files. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=757416&aid=1776135&group_id=144022 ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl