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

Reply via email to