Activity for APNG
-
APNG released /libpng/libpng16/libpng-1.6.56-apng.patch.gz
-
-
-
-
-
-
-
-
-
Sam Tansy posted a comment on discussion Main Forum
How to turn off colour depth optimization? It is automatic, and does a good job, but sometimes it is desirable or required to keep original colour depth as receiver expect it or does not support a new one (specially indexed one).
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Pelo Pako modified a comment on discussion Main Forum
Hello, When writing an APNG, this code seems to leak memory because for every frame image written, it allocates new memory on the png_ptr struct that overwrites a pointer to memory allocated on the previous frame image written. I suspect because libpng was originally written to only write one image there's no leak in that case, but the apng patch isn't taking this into account to free the memory before writing the second (and each subsequent) frame image. For example, prev_row is leaking memory....
-
My loop to add frame images looks like this: png_write_frame_head() png_write_image() png_write_frame_tail() As far as I know this is correct. In the current implementation there's no way to free the memory before writing another frame image except by destroying the complete png_ptr which I'm confident to say isn't supposed to be done. Code added to png_write_reset: /* Free our memory. png_free checks NULL for us. */ png_free(png_ptr, png_ptr->row_buf); png_ptr->row_buf = NULL; #ifdef PNG_WRITE_FILTER_SUPPORTED...
-
My loop to add frame images looks like this: png_write_frame_head() png_write_image() png_write_frame_tail() As far as I know this is correct. In the current implementation there's no way to free the memory before writing another frame image except by destroying the complete png_ptr which is clearly isn't supposed to be done. Code added to png_write_reset: /* Free our memory. png_free checks NULL for us. */ png_free(png_ptr, png_ptr->row_buf); png_ptr->row_buf = NULL; #ifdef PNG_WRITE_FILTER_SUPPORTED...
-
Hello, When writing an APNG, this code seems to leak memory because for every frame image written, it allocates new memory on the png_ptr struct that overwrites a pointer to memory allocated on the previous frame image written. I suspect because libpng was originally written to only write one image there's no leak in that case, but the apng isn't taking this into account to free this memory before writing the second (and each subsequent) frame image. For example, prev_row is leaking memory. Every...
-
-
-
-
-
-
-
-
-
-
Max Stepin posted a comment on discussion Main Forum
Thanks for letting me know! Fixed in 1.6.43
-
-
-
-
Clinton Ingram posted a comment on discussion Main Forum
Howdy @maxst, Thanks for maintaining this patch. I've been using the other APNG patch for a while, but it hasn't been updated in a few versions, and I thought I'd give this one a try. I'm getting build errors, however. This patch does not update the ordinals for DLL exports in png.h correctly since the addition of png_get_eXIf_1 and png_set_eXIf_1, resulting in a mismatch with the ordinals defined in symbols.def (which was updated). Specifically, the PNG_EXPORT lines from 401 to 464 in the patch...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
I added libdeflate compression to apngopt and gif2apng. Compression result is similar to 7z-deflate, sometimes slightly better, sometimes slightly worse but it's many times (on average about five times) faster than 7z-deflate with 15 iterations. I wonder what you think of it. I also changed way iterations work for zlib and libdeflate compression - they are level of compression now. As iter defaults to 15 it implies maximum compression level anyway, 9 for zlib, 12 for libdeflate. Here are results...
-
I added libdeflate compression to apngopt and gif2apng. Compression result is similar to 7z-deflate, sometimes slightly better, sometimes slightly worse but it's many times faster than 7z-deflate with 15 iterations. I wonder what you think of it. I also changed way iterations work for zlib and libdeflate compression - they are level of compression now. As iter defaults to 15 it implies maximum compression level anyway, 9 for zlib, 12 for libdeflate. Here are results of few tests: beach ball from...
-
I added libdeflate compression to apngopt and gif2apng. Compression result is similar to 7z-deflate, sometimes slightly better, sometimes slightly worse but it's many times faster than 7z-deflate with 15 iterations. I wonder what you think of it. I also changed way iterations work for zlib and libdeflate compression - they are level of compression now. As iter defaults to 15 it implies maximum compression level anyway, 9 for zlib, 12 for libdeflate. Here are results of few tests: beach ball from...
-
Orivej Desh posted a comment on discussion Main Forum
I have already asked this at https://sourceforge.net/p/libpng-apng/bugs/7/ , could you reply there?
-
-
-
-
-
-
-
pointer posted a comment on discussion Main Forum
apngopt could not use absolute path under macOS terminal becaus of the line:1455, szOpt[0] == '/'
-
Shazy posted a comment on discussion Main Forum
Hey maxst! This is no doubt a great piece of software that you have written, many thanks! With the world moving on to 64-bit architecture processors & OSes and talks going around that support for 32-bit softwares will be eventually dropped, I request you to kindly release a 64-bit version of your software to ensure "apngopt" remains relevant in the future. If you decide to update the software, I would request further additions to make it even better. So my request are these: Could you please make...
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1 >
