PNGs loaded with Image.FromFile save GIFs as corrupted files

[danielcrenna]

^^^ as described. I have two simple PNGs with a transparency channel and the resulting GIF with 100ms delay per frame is unreadable by any program.

[DataDink]

Just posting to let you know I have seen this but won't have time to look into the issue quite yet.

[pdavis68]

I am seeing this as well. It was creating animated GIFs just fine and then all of a sudden they're all corrupted.

My code is very simple:

    static void BuildGIF(string filename, Image[] images)
    {
        using (MemoryStream ms = new MemoryStream())
        using (GifEncoder encoder = new GifEncoder(ms))
        {
            foreach (Image image in images)
            {
                encoder.AddFrame((Image) image.Clone(),0, 0, TimeSpan.FromSeconds(10));
            }
            using (FileStream fs = new FileStream(filename, FileMode.Create, FileAccess.Write, FileShare.None))
            {
                ms.WriteTo(fs);
            }
        }
    }

I need this working ASAP, so I'm going to go ahead and see if I can find the problem before I resort to another library. Nice library, by the way. Despite the issue, it's really nicely written.

[danielcrenna]

I ended up hacking my own together using WPF for the image assembly and bits of NGif to write the custom timings. Ugly. Works.

Sent from my iPhone

On May 15, 2014, at 9:02 AM, pdavis68 notifications@github.com wrote:

I am seeing this as well. It was creating animated GIFs just fine and then all of a sudden they're all corrupted.

My code is very simple:

static void BuildGIF(string filename, Image[] images)
{
    using (MemoryStream ms = new MemoryStream())
    using (GifEncoder encoder = new GifEncoder(ms))
    {
        foreach (Image image in images)
        {
            encoder.AddFrame((Image) image.Clone(),0, 0, TimeSpan.FromSeconds(10));
        }
        using (FileStream fs = new FileStream(filename, FileMode.Create, FileAccess.Write, FileShare.None))
        {
            ms.WriteTo(fs);
        }
    }
}

I need this working ASAP, so I'm going to go ahead and see if I can find the problem before I resort to another library. Nice library, by the way. Despite the issue, it's really nicely written.

—
Reply to this email directly or view it on GitHub.

[pdavis68]

To help diagnose, I tried to load the image here: http://www.smiliegenerator.us/index.php?pid=41 (never been to this site before, but it gave some diagnostics, so that was cool). This is what it said:

gifsicle: Error while reading '/home/smilie/public_html/applications/animation/disassemble/temp/0193576001400157938.tmpout.gif' frame #0:
gifsicle: unknown block type 97 at file offset 808

• /home/smilie/public_html/applications/animation/disassemble/temp/0193576001400157938.tmpout.gif 4 images
  logical screen 960x720
  global color table [256]
  background 0
  loop count 1
  extensions 8
  • image #0 960x720
  • image minor change, specifying frame delay on a per-image basis #1 22152x44393 at 39590,56522 transparent 116

So I traced through the code and byte 808 is the very first byte written in WriteImageBlock()

WriteByte(header[0]); // Separator

Anyway, I don't know if that helps to identify the issue.

I find It interesting that it was able to determine the dimensions of Image#0 correctly, as those are written in bytes 813-816...

[pdavis68]

Looking through the format specs from various places, it appears that the image separator should be 0x2C, but header[0], in my case is 97 decimal.

I replaced WriteByte(header[0]) with WriteByte(0x2C) and the site I referenced above read in and displayed all the frames from the GIF without complaint, but all the images were corrupted. :(

Not sure what my next step is.

[pdavis68]

@danielcrenna Sadly, I've had to switch to NGif. It creates a usable animated GIF. If BumpKit gets fixed, I'd much rather use it because NGif is a pox on my SVN repo. It's so hideously ugly. It's also horribly slow. It takes about 2 minutes to generate my animated GIF vs. BumpKit which did it in about 5 seconds. :(

[danielcrenna]

The thing is the WPF encoder works just fine if you don't care about timing information. So it got me thinking to prepare the frames using WPF, save the file, then open it again and just make edits to the well known control blocks for timings. This way I'm not using NGif I'm just cribbing the bits that set the metadata that WPF doesn't provide. Best of both worlds. Maybe I'll throw it on github.—
Sent from Mailbox

On Thu, May 15, 2014 at 10:16 AM, pdavis68 notifications@github.com
wrote:

@danielcrenna Sadly, I've had to switch to NGif. It creates a usable animated GIF. If BumpKit gets fixed, I'd much rather use it because NGif is a pox on my SVN repo. It's so hideously ugly.

Reply to this email directly or view it on GitHub:
#2 (comment)

[DataDink]

Understood. Really sorry I haven't had time to pick this project back up. I'll post here when I get some time to make updates the the GIF engine.

[danielcrenna]

Hah, don't apologize. My GitHub is a massive wasteland of projects gone by.

On May 15, 2014, at 4:22 PM, Mark Nelson notifications@github.com wrote:

Understood. Really sorry I haven't had time to pick this project back up. I'll post here when I get some time to make updates the the GIF engine.

—
Reply to this email directly or view it on GitHub.

[DataDink]

Hey guys,

I am not actively maintaining this project. If you find a solution to these issues please feel free to submit a pull request for the change. I will leave these issues open for others to address.