Closed Bug 48893 Opened 24 years ago Closed 17 years ago

MNG decoder should be used for decoding PNGs

Categories

(Core :: Graphics: ImageLib, defect, P3)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: ola.jaensson, Unassigned)

References

Details

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).
Taking bug.
Assignee: pnunn → tor
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
Status: NEW → ASSIGNED
QA Contact: elig → tpreston
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)

Blocked by bug #18574.
Depends on: mng
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.
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.
Assignee: tor → nobody
Status: ASSIGNED → NEW
Since bug #18574 has been marked WONTFIX, this one should be marked WONTFIX too.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.