Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

PNGs loaded with Image.FromFile save GIFs as corrupted files #2

Open
danielcrenna opened this issue Dec 19, 2013 · 10 comments
Open

PNGs loaded with Image.FromFile save GIFs as corrupted files #2

danielcrenna opened this issue Dec 19, 2013 · 10 comments

Comments

@danielcrenna
Copy link

^^^ 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
Copy link
Owner

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

@pdavis68
Copy link

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
Copy link
Author

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 [email protected] 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
Copy link

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

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
Copy link

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
Copy link

@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
Copy link
Author

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 [email protected]
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
Copy link
Owner

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
Copy link
Author

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

On May 15, 2014, at 4:22 PM, Mark Nelson [email protected] 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
Copy link
Owner

DataDink commented Apr 5, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants