Feature request: save as Animated PNG?

[Rin Tohsaka]

I tried out the built-in recording/exporting function for the first time today and realized that a "save as Animated PNG" function could be a good intermediate between a full-fat lossless video recording and a 256 color-limited GIF. Now normally Animated PNGs with their full 24bit color palettes can get pretty large, but the GBA's 240x160 resolution is small enough and the graphics typically pixelated enough that animated PNGs of GBA games tend to actually compress pretty well, especially if they're optimized accordingly with regards to inter-frame compression (which I only mention because unfortunately there's quite a bit of APNG-creation software that creates completely unoptimized animations whereby each frame is fully stored as full-resolution PNGs, even if only one quadrant of the image actually updates) I don't know how useful the following would be for mGBA, but APNG Optimizer seems to be the go-to example of efficient inter-frame optimization and it does have a source available: https://sourceforge.net/projects/apng/fi...Optimizer/

[endrift]

The best lossless compression I've found is with H.264 in lossless mode. I used to have it store a series of PNGs in a matroska file but it was much bigger and not well supported. I can see if FFmpeg supports APNG too, but I suspect it'll have similar issues.

[Rin Tohsaka]

The best lossless compression I've found is with H.264 in lossless mode.

Technically the best would be x265 in lossless mode, but I don't think anybody in the FOSS world should be touching that absolute mess of licensing and patents. (and I don't think AV1 encoders incorporate a lossless mode yet)

Regardless, the idea wasn't so much reducing the file size to the smallest possible but to have things still in an image format for convenient internet-posting use without the quality reduction associated with GIF or lossless 4:2:0 chroma subsampled video codecs since browsers can display APNG files as-is, especially since browsers can't decode lossless x264 (at least from my testing that is).

I used to have it store a series of PNGs in a matroska file but it was much bigger and not well supported. I can see if FFmpeg supports APNG too, but I suspect it'll have similar issues.

Animated PNG doesn't use a video container though but rather is a straight-up modification of the PNG format and is in fact decoded via a modified libpng or the like which is also how it's able to fall-back to just displaying the first frame if opened in software that only supports non-animated PNG.

[endrift]

Ok, I'll add APNG support. Looks like it shouldn't be that much work.

E] Newest dev builds should support it now

[Rin Tohsaka]

Ok, I'll add APNG support. Looks like it shouldn't be that much work.

E] Newest dev builds should support it now

Less than two hours? That was fast - you're right I guess it wasn't that much work.

I also appreciate you renaming the menu option to "Save GIF/APNG" rather than following the more modern yet inaccurate use of the term "GIF" where it simply means any and all types of animation.


AFAICT everything works fine, though selecting APNG from both the record window of the save drop-down is a bit wonky, and the same goes for when changing the settings back from APNG to GIF.

Personally I think a much more elegant solution is to just ditch the file extension drop-down altogether and just do it how the "Save state file" work - that is, when the user does not type in the file extension, mGBA automatically appends the according correct file extension when saving the file.

So the idea is that, if the user has a save path of "C:\recording" without specifying .gif or .png, mGBA would then just automatically add the according file extension based on whether they've selected GIF or APNG from the "Record GIF/APNG" window.


Also I just want to say that running an APNG created via mGBA through APNG Optimizer still results in something like the file size being cut to anywhere between two-thirds (MK:SC daytime intro) and half (MK:SC nighttime intro). Going through frame-by-frame in XnView shows that APNG Optimizer looks to even be removing pixels from inside of the frame and not just cropping the individual frames as much as possible.

For example, during an APNG recording of the title animation in Mario Kart, this is what the original 6th APNG frame created by mGBA looks like:


While this is what it looks like after APNG Optimizer has been ran on the animation:


(now obviously it doesn't look like that when animating because of the way APNG's inter-frame optimization works, so the end result of the complete animation is identical and still completely lossless)