Add option to preserve identical consecutive APNG frames when saving

[Delgan]

Hi again.

I'd like to be able to save animated PNGs without Pillow merging the consecutive identical frames. As far as know, this is not cleanly possible with the current API.

Related (for GIFs):

• How to generate GIFs with duplicate frames? #7809
• Animated gif skips frames #8397

I would like this feature for two reasons:

1. I have dynamically generated APNGs that sometimes fail to .save() because of this. It causes ValueError while the individual frame delays are correctly representable, but their sum is not (numerator exceeds 65535)
2. I would like to preserve the original number of frames distinctly, as they are meaningful for my workflow when the APNG is reopened later for editing or studying. I would like the frames and their durations to be saved losslessly so that the process is reversible.

Here is a reproducible example regarding the first point (with pillow==12.3.0):

from PIL import Image

frame_a = Image.new("RGB", (1, 1), "green")
frame_b = Image.new("RGB", (1, 1), "red")

# ValueError: cannot write duration
frame_a.save(
    "output.png",
    format="PNG",
    save_all=True,
    append_images=[frame_b, frame_b],
    duration=[100, 32768, 32769],
)

Would you please consider adding a save() option to help with these use cases?

[radarhere]

Hi. You're trying to encode information into your image that no human would ever discern, only code. I wonder if a tEXt chunk wouldn't be better for this, allowing you to store a string with whatever information you want?

Alternatively, point 1 seems interesting. The delay numerator for a fcTL chunk is 2 bytes, hence the 65535 limit. You'd like to workaround that limit by splitting the same image over multiple frames. If we split the frames when the duration is greater than 65535 by default, without an additional setting, would that be enough to resolve your problem? I'm imagining a 65535 frame and then a 2 frame, to make the same total as 32768 + 32769.

[radarhere]

@niukanen1 65535 seconds is a little over 18 hours. I'm sure the team who came up with this specification thought to themselves 'No one will ever need an image frame that lasts more than 18 hours'

Did you want to elaborate a bit more on why you need this functionality, and why you can't store the information in a comment or something?

[Delgan]

To be fair, the 32768 + 32769 duration was chosen to make the reproducible example minimal. Here's another way to trigger the error, even though the duration are perfectly reasonable:

from PIL import Image

frame_a = Image.new("RGB", (1, 1), "green")
frame_b = Image.new("RGB", (1, 1), "red")

frame_a.save(
    "output.png",
    format="PNG",
    save_all=True,
    append_images=[frame_b, frame_b, frame_b],
    duration=[100.0, 83.71353149414062, 83.71353149414062, 1000.0],
)

I create APNGs based on sequence instructions and assets extracted from a video game. Keeping all frames allows me to generate an output that I can map back to the sequence defined in the game. This is desirable for preservation of information, and also to be able to programmatically validate the output or manually edit it.

I see this in much the same way as the sBIT field (which I also use). It has no visual significance, but it preserves useful information about the original source.

Using tEXt to encode that feels a bit like reinventing the wheel, to be honest. I'd rather not have to implement and document a custom protocol like that, while individual APNG frames with a specified duration map very naturally to my use case.

That being said, I just realized that Pillow doesn't merge the frames when no duration is specified? In that case, I'm fine with editing the fcTL chunks on my own, after Pillow has encoded the APNG. It's not much of a hassle, and that's probably the workaround I'd choose.

[radarhere]

Ah, ok, thanks.

See what you think of #10070. I think it's a simpler solution than #10064

[Delgan]

Yeah that seems right. 👍