Layer optimization

[SoniEx2]

For larger images, it may be a good idea to split the APNG into sections and store each section as a separate frame with no delay between them.

Conversely, disassembling should merge 0-delay frames together.

[Kagetsuki]

You mean like some sort of image version of a RAR file?

[SoniEx2]

Uh... What?

[SoniEx2]

If you have a frame set to 0-delay, then the next frame is merged with it. So for example, if you have a 300x300 image but you're modifying two 30x30 regions in opposite corners (say, top left and bottom right), it might be better to store two 30x30 frames instead of one 300x300 frame.

Does that make sense?

[Kagetsuki]

Aaah, yeah that makes perfect sense, but that's actually part of what makes APNG so simple is that it doesn't have that. APNG is meant to be as easy to implement as possible, and adding features like that - essentially features that already exist in video formats - would make implementation that much more difficult. Not to mention it would break essentially every existing APNG decoder.

As for 0 delay frames: if you're treating an APNG file as an archive or source for a sprite they would be very handy - but if they were merged on unpack you couldn't do that. If you'd like to implement some sort of option to merge 0 delay frames on unpacking we'd be happy to take a look at a pull request but it would have to be optional and not default.

[SoniEx2]

APNG does have it, actually.

[Kagetsuki]

Can you point out specifically what you're referring to?

[SoniEx2]

Say you have a 2x2 image:

ab
cd

And the next frame is:

xb
cy

Instead of storing it as:

ab | x  |
cd |  y |

(where empty spaces indicate no change (see blend modes))

It's possible to store it as:

ab | x  |    |
cd |    |  y |

(in this case, empty spaces indicate no data (see frame width/height/pos))

Where the first frame has normal frame delay, the second frame has 0 delay, and the third frame has the desired delay. This causes frames 2 and 3 to get merged into one and treated like in the original case.

For tiny images such as the above 2x2, this is a waste of space, as the size of the fdAT is smaller than the size of the fcTL; but for big animations this might very well save tons of space (and increase decoding speed/performance).

[Kagetsuki]

No, you said:

APNG does have it, actually.

But I have never seen an example of this. It's also confusing why this would even be a feature because the blank space markers are so small they are practically negligible - maybe a few hundred bits at best on a mid sized image. Furthermore, it's a general "rule" in APNG that successive frames hold the same dimensions as the base frame - otherwise you would need dimension and positioning information and extra headers which alone would take up more space than the blank space markers.

[SoniEx2]

If you look at the APNG spec, you'll notice it talks about fcTL and fcTL supports dimension and positioning information.

[Kagetsuki]

Ah! You are correct. The thing is the only place I've seen that used is to centre frames with different sizes. apngasm currently has no manual control of this and if I'm not mistaken there was actually some other issue with different sized frames that we didn't "fix" because we couldn't find a parser that could handle them properly to begin with. I've certainly never seen them out in the wild. Would you happen to have a sample we can check against?