I'm trying to convert my avatar to apng to see if it can be smaller than agif (probably not). The only way I know how to do that, however, is to optimize the images myself. Unfortunately, every time I assemble the pngs in some assembler, it recalculates the frames, ruining my compression.

I'm attempting to hex all the parts together, but it seems that every time I do, I end up messing up somewhere, what with the crc. Anyone have any tips on debugging? I can't tell where I went wrong.

anyone have any programs they know of which simply smush a few pngs together without changing the compression?
http://animatedpng.com/index.php/software/
Has a list of the known editors.
Virtualdub doesn't handle palettes.
APNG anime maker compresses
apng edit compresses
animat compresses
japng isn't responding
animated png manager isn't responding
GIMP just doesn't work
Paint.net is plain bad at handling animations
apngasm compresses
apng assembler 2.0 compresses

You missed gif2apng on that link...

25792 bytes =

18236 bytes =

Photoshop?

I was going to write something that just mashed pngs together, but I then downloaded apng instead.

Bad example. It's corrupt.

gif2apng increases size:
20769 vs 16402


Photoshop is an image editor, meaning it actually edits the image. That means I lose my compression, since Photoshop is known for bloating pngs. Also, I'm fairly certain PS hasn't included apng support.

It's not corrupt. Opera displays both just fine.

It's just Firefox being buggy. Next Firefox will fix that.

It's all explained on http://gif2apng.sourceforge.net/

Someone will write APNG plugin sooner or later.

The problem with PS is that you can't have layers in indexed mode.

I could get it so much smaller if I could just combine the pngs properly. It still doesn't help me for 16 bit pngs.

Elaborate on that? How would you combine them better, comparing to those programs?

Try pngcrush to compress...

compare the IDATs of the animation I posted and this one. 0a a1 vs 0b 17. That's 118 bytes, then consider that for each frame. Based on my pngs of the file, the total IDAT+fdATs should be around 14000, with 800 PLTE, IHDR, IEND, and 442 fcTL. I suppose I can just replace each fdAT with my own IDAT, but the problem arises when extracting the images out, since I don't know if I can extract the true frame from the fdAT or what's actually being displayed on the screen, or whether or not the png used is the same as the png I would use.

pngcrush is terrible. pngout achieves the smallest compression of all of them, except for on large jpgs and tiny, tiny images (where optipng works best).

Also, gifs don't support 16 bit color, like apng and png do. Granted, I'll have to work super hard to get an actual 16 bit image, since compressors can't handle it either, and neither can gimp.

Is it possible that your single file compression is incompatible with animated files?

All that matters is that they are compressed in the same way (which they are). I don't really understand zlib, so I suppose it's possible that you can't use different huffman tables, which would indeed mean they are incompatible. Most of the zlib stuff is stored within the dat chunk, so I can't see how it would need to be all in the same compression.

I'll have to try replacing the first frame.
Edit: looks like it works.

Post has been edited 1 time(s), last time on Jul 2 2010, 1:30 pm by rockz.

Sure, pngout could get you 118 savings on that first frame, maybe even 1-2 bytes more if you run it multiple times.

But even if you consider 118 bytes savings for every frame (unlikely), for 17 frames you''l get 2000 bytes of total savings.

So I don't see how you could make 19000 -> 14000 bytes compression for IDAT+fdATs.

gif2apng isn't optimizing the frames with transparency, making the idats much bigger than they need to be. Instead it's simply finding the change in frame, then cropping the frame, and replacing the old frame with the new frame.

my compressed frames total:
27,754 bytes
Header = 8
IHDR = 25
PLTE = 780
tRNS = 13
IEND = 12

27754 - 17*(8+25+780+13+12) = 14246 IDAT total.

Each additional frame requires:
tRNS = 13
fdAT = 4+current IDAT
fcTL = 38
And one extra fcTL for the first frame.

That leaves:
acTL = 20
PLTE = 780
IEND = 12
Header = 8
IHDR = 25

So 20+780+12+8+25+38+16*(13+4+38)+14246 = 16009 bytes.

If you still can't see it, I can always upload the pngs.

Theoretically it can. But that optimization is turned off, because buggy Firefox can't display those optimized animations.
After Mozilla released next Firefox with a fix, next gif2apng release will turn on that optimization.


I wonder how you were able to compress them so much.
pngout?
Did you make sure to keep the same the palette for all frames?

Actually I have a couple of programs that do the conversions you need -
pngsequence <-> apng
They are not exactly ready for release, but I can clean them up a little bit, and post them here.

I used pngout /n1 /f0 /c3 /s0 /v /r /kp on all of the frames except the first, which had /n2, and repeated a number of times.

I found a program called tweakpng. While it doesn't exactly have support for apng, it can easily copy/paste chunks, I think.

Here the tools I promised.

http://rapidshare.com/files/404768160/apng_tools.zip

1. Run apng2pngseq.exe anim.png
2. It will extract frames and apng2pngseq.txt
3. Optimize frames (pngout)
4. Rename the text file into pngseq2apng.txt
5. Run pngseq2apng.exe

This would be perfect if it had directions put into it. Otherwise it's almost exactly what I wanted. Thanks SO much. Now I just have to get the palette correct (png transparency is different from gif transparency )