If PNG is a subset of MNG, shouldn't the MNG decoder take care of the PNG files as well? It already decodes multiple file formats (JNG). It would perhaps help solving bloat and optimization issues. (and less code == less bugs) Or I may be completely misinformed. (1:st bug report)
Eventually this would be a good thing to do, but for now libpng works well with mozilla and has had much more testing. The MNG decoder also has some integration problems with mozilla (see the dependent bugs of 18574).
Now that the MNG Decoder is activated by default, this would be possible to do. The actual code changes are trivial. But how will we proceed with this bug? Will we just switch to the MNG Decoder on the trunk after 1.0 has branched and wait for user feedback?
Three things that would need to be fixed for this: * MNG decoder always keeps its own copy of the image. Should check if it's dealing with a one frame image and only use a line buffer in that case. * libmng/necko mismatch means we keep an extra copy of the whole image stream (bug 79944) * interlaced PNGs loaded with libmng display as a black image with just the known samples showing, instead of pixel replicated. While I happen to like the effect, others would object. libpng has been around for quite a while and is probably more robust dealing with various edge cases or invalid/corrupt images.
I have the impression that the PNG decoder is even used for MNG images that have the PNG signature and start with the PNG IHDR chunk. A step in the direction of implementing this recommendation would be to let the MNG decoder handle such files. We could thus develop some experience with the MNG decoder by simply renaming files (for example as I did at http://libpng.sf.net/crashers) Glenn
vaguely related to bug 163737 (but please don't make this one block that one)
Just occurred to me... isn't JPEG a subset of MNG too? Eventually, libmng could handle practically everything except GIFs and BMPs ;)
It uses libjpeg already, so that's not an issue (it would use libjpeg anyway). MNG requires only a subset of JPEG afaict. For example, I don't know think bug 44781 could be resolved if it went only on the JNG standards.
If libmng goes back in it will most likely not be supporting 16-bit-per-channel images. We'd still need libpng support to see those.
Reliability issues aside, what is less costly? - Having libMng handle PNG images, and restoring the 16-bit support in libmng? or - Having libPng handle PNG images, and removing the 16-bit support in libmng?
Typically, the solution to trusting newer code replacing older code is validation. I found this page on the PNG site: http://www.libpng.org/pub/png/png-sitemap.html#images which has lots of sample images, but surely somebody must have a corpus of thousands of PNG's for testing already? A small group could probably write a test suite to render them with both libs and report discrepancies. Any difference would need to be evaluated and marked as OK or cause bug fixes. If such a corpus does not already exist, I'll volunteer to hack out a spider to build one. Of course with MNG out of the trunk, this is one hell of a Catch-22, but one has to start somewhere, and this has the potential to be a high-value optimization.
Ah, there's a good test suite here: http://www.libmng.com/MNGsuite/ Still, I suspect these are all good, valid, non-buggy PNG's. There might still be a use for a set of PNG's from the wild.
One last time: PNG Validation Suite, including corrupt images: http://www.schaik.com/pngsuite/pngsuite.html
Since glenns patch sets of Bug #18574 you can define using libmng for png's instead of libpng ... would nice if someone can test it.
I have tested this since the "integrated" patches came out in bug 18574 on both OS/2 and Linux. The people who use my unofficial builds for OS/2 test this as well, and for the last half year nobody has complained. I think by now everything works well. Some PNG testsuites require the MNG_BUILD_FULL_MNG configuration, to make 16bit stuff (?) display correctly. As the patches in bug 18574 do quite well what this bug is about, one could mark this one as a dupe now.
Since bug #18574 has been marked WONTFIX, this one should be marked WONTFIX too.