[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-09 06:53 Message: I really like and appreciate your article.Thanks Again. Will read on... -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-06 03:04 Message: Thanks for sharing, this is a fantastic article post.Thanks Again. Much obliged. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-05 08:45 Message: Thank you ever so for you blog post.Much thanks again. Want more. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-05 04:29 Message: Appreciate you sharing, great blog. Fantastic. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 06:23 Message: Fantastic article.Thanks Again. Really Great. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- For Developers, A Lot Can Happen In A Second. Boun
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-06 03:04 Message: Thanks for sharing, this is a fantastic article post.Thanks Again. Much obliged. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-05 08:45 Message: Thank you ever so for you blog post.Much thanks again. Want more. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-05 04:29 Message: Appreciate you sharing, great blog. Fantastic. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 06:23 Message: Fantastic article.Thanks Again. Really Great. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Synfig-devl mailing list
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-05 08:45 Message: Thank you ever so for you blog post.Much thanks again. Want more. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-05 04:29 Message: Appreciate you sharing, great blog. Fantastic. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 06:23 Message: Fantastic article.Thanks Again. Really Great. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-05 04:29 Message: Appreciate you sharing, great blog. Fantastic. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 06:23 Message: Fantastic article.Thanks Again. Really Great. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-03 06:23 Message: Fantastic article.Thanks Again. Really Great. -- Comment By: Nobody/Anonymous (nobody) Date: 2012-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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-04-03 04:49 Message: Very neat blog article.Really thank you! Keep writing. -- 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 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second resolution app monitoring today. Free. http://p.sf.net/sfu/Boundary-dev2dev ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
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
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
Bugs item #1776135, was opened at 2007-08-17 12:18 Message generated for change (Comment added) made by dooglus 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: dooglus (dooglus) Date: 2008-02-11 12: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.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl
[Synfig-devl] [ synfig-Bugs-1776135 ] gif rendering has several problems
Bugs item #1776135, was opened at 2007-08-17 12:18 Message generated for change (Tracker Item Submitted) made by Item Submitter 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: Open Resolution: None 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)" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=757416&aid=1776135&group_id=144022 - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ Synfig-devl mailing list Synfig-devl@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/synfig-devl