Closed Bug 204520 Opened 21 years ago Closed 17 years ago

MNG imgmng library takes up too much disk space

Categories

(Core :: Graphics: ImageLib, defect)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: SkewerMZ, Assigned: glennrp+bmo)

References

Details

(Keywords: memory-footprint)

Attachments

(7 obsolete files) 

Split off from bug 195280: The decoder library for MNG images is too large.

Quote tor@acm.org:

  * mng decoder module is roughly the same size as all the other
      image decoders and libpr0n logic combined.

      Linux sizes:

        261796  libimglib2.so
        241492  libimgmng.so

      MS-Windows sizes:

        155024  imglib2.dll
        170336  imgmng.dll


I disagree that this is a problem, however it is valid cause for a bug. If it
becomes WONTFIX or an eternal Future bug, I won't be surprised.
This probably has to do with the fact that the mng standard allows more
variation than all the other image standards combined (for example, you can have
JPEG images as single frames inside MNG animations).... 
How are the numbers affected by removing MNG write support?
i.e., comment out line 120 of libmng_conf.h

Glenn
> (for example, you can have JPEG images as single frames inside MNG
> animations)....

As indicated in bug 195280, there's currently code-duplication for the JPEG lib.
The JPEG code inside libmng isn't the biggest issue. Though it adds 4 (not
counting jpeg-12, which is off by default) to the 15 different PNG formats. All
of the formats have to be handled for various effects. Storing temporarily,
slapping onto the canvas, promoting (left-bit replicate or zero-fill) to
differet format, delta onto the canvas, delta onto stored image, promote/degrade
during delta-operation and then some.

> How are the numbers affected by removing MNG write support?
> i.e., comment out line 120 of libmng_conf.h

That's the default behavior. When *not* built as a .DLL or .SO it results in a
lean decoder without frills.

There's other optimizations for Moz though. Like removing support for
text-chunks and letting them be handled by the unknowm chunk handler. Anyway,
there's plenty that can be done. And I'll get to it when time permits and
MNG/JNG support is sure to stay.

Gerard

Duplicating a comment I posted over in bug #18574: I will work within libmng
to look for ways of reducing its footprint.    Glenn
Looking at the tar distribution for 1.4a (could not find 1.4b), the
Makefile for modules/libpr0n/decoders/mng seems to be missing a dependency
of libimgmng.so on the objects in modules/libimg/mng/libmng. I have to
remove libimgmng.so manually before running "gmake install", or it doesn't
get updated. 
Glenn
There is a footprint savings of about 25kbytes when libmng-1.0.6 from
the current libmng CVS is built with the following appended to Mozilla's
mozilla/modules/libimg/mng/Makefile and Makefile.in:

# eliminate unused features from libmng
DEFINES         += -DMNG_OPTIMIZE_FOOTPRINT
DEFINES         += -DMNG_SKIPCANVAS_ABGR8
DEFINES         += -DMNG_SKIPCANVAS_ARGB8
DEFINES         += -DMNG_SKIPCANVAS_BGR8
DEFINES         += -DMNG_SKIPCANVAS_BGRA8
DEFINES         += -DMNG_SKIPCANVAS_BGRA8_PM
DEFINES         += -DMNG_SKIPCANVAS_BGRX8
DEFINES         += -DMNG_SKIPCANVAS_RGBA8
DEFINES         += -DMNG_SKIPCHUNK_iCCP
DEFINES         += -DMNG_SKIPCHUNK_tEXt
DEFINES         += -DMNG_SKIPCHUNK_zTXt
DEFINES         += -DMNG_SKIPCHUNK_iTXt
DEFINES         += -DMNG_SKIPCHUNK_bKGD
DEFINES         += -DMNG_SKIPCHUNK_pHYs
DEFINES         += -DMNG_SKIPCHUNK_sBIT
DEFINES         += -DMNG_SKIPCHUNK_sPLT
DEFINES         += -DMNG_SKIPCHUNK_hIST
DEFINES         += -DMNG_SKIPCHUNK_tIME
DEFINES         += -DMNG_SKIPCHUNK_eXPI
DEFINES         += -DMNG_SKIPCHUNK_fPRI
DEFINES         += -DMNG_SKIPCHUNK_nEED
DEFINES         += -DMNG_SKIPCHUNK_pHYg

I'll leave it to one of the regulars to turn it into a proper
patch.

Similar treatment of the libpng Makefile, with no changes to
libpng itself, yields 50kbyte savings, on the FreeBSD system with
gcc 3.2.1 compiler that I'm using.

Should I post the libpng patch here or open a new "libimg2 library
takes up too much disk space" bug and post it there?  Seems simplest
to just put it here.

Glenn
Glenn,
first, thanks a lot for that work! On my GCC 3.3 mozilla build, it saves ~40 KB.

for that png changes, I would file a separate bug.
Attached patch patch (obsolete) — — Splinter Review 
ok, this patch updates the in-tree libmng version to the current libmng cvs, as
of a few hours ago and also adds the defines mentioned by gjuyn.

however... I am not sure if a non-release version of an external library should
be included in mozilla...
I agree it shouldn't be checked in until libmng-1.0.6 is released.  My
patch was only intended for testing by interested persons.  The patch is
moot now anyhow, since bug #195280 has been "FIXED" and MNG/JNG support
removed from the trunk.  I suppose this one can be marked RESOLVED INVALID
for now, until MNG support is resurrected either in libimg or extensions.
shouldn't Severity be raised now, as this is the only chance to get it back?
I agree. Severity should be raised now that support has been removed. i don't
beleive that marking this bug as INVALID would help to get support back.
Should someone open a bug for "Add MNG/JNG support back in" and make it depend
on this one?
I now see bug #18574 to re-implement this.
> a "normal" severity bug, since this bug has caused MNG to be backed out from
the trunk.
Severity: trivial → normal
Status: NEW → ASSIGNED
taking assignment
Assignee: jdunn → randeg
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
One note: Try not to do anything that will make it any more difficult to fix bug
195280 - currently MNG doesn't obey the animation pref (loop forever, once, or
don't animate at all).
Skewer:  I think you meant to refer to bug #121927 which deals with animation
handling.
Skewer: if it is bug #121927 you are referring to, that's really got nothing to
do with libmng, but with the glue code. Glenn and I are only concentrating along
the libmng shrinkage path (well mostly Glenn...).
I'm also looking at the glue code, but I don't expect there will
be changes there with respect to reducing the library size.   Glenn
Oops. Well in the big picture I meant to refer to bug 161109. But definitely not
bug 195280.
What is the metric for successful fixing of this bug?   Because MNG does
much more than the other formats combined, it's not surprising that the code
is about the same size.  I did demonstrate savings of 25k (40k unstripped),
but evidently that wasn't enough. A good deal more can be achieved if we
give up 16-bit sample support and accept the possibility that some 16-bit
images might be displayed with incorrect transparency.
For simpler maintenance, the defines should be put in a mozlibmng_conf.h
file that is included by libmng_conf.h, instead of in the Makefile (see
bug #208607 comment #5 and 6).
Sizes of the various image decoders, based on the text segment size
from a linux optimized build.  For the purposes of these measurements
MNG was included in imglib2, so it's not suffering from a second copy
of jpeglib.  Size of final linked imglib2 was measured, so any linker
excludable code doesn't count against the decoder.

Both the mng and png reduction patches (bug 204520, bug 208607) have
been applied.

core imglib2:  40K
xbm:            3K
bmp/ico:       12K
gif:           19K
png:           38K
jpeg:          54K
mng:          162K

wow, that saves around 200K... find another 70K and both libs together will have
the same size as imglib2 before! ;)
Thanks tor for the report.  If indeed libpng and libmng were combined in one
library, then libmng could use some of libpng's utility routines such as the CRC
calculator and save a few more k.  The main potential savings I can see beyond
that is #ifdef'ing out the 16-bit support in libmng.

Just to put things in perspective, Mozilla's lib directory contains 25.4 Megs of
optimized, stripped *.so.  Who is going to notice if we succeed in reducing
libmng by 70k and the total drops to 25.33 Megs?  I know the fraction is bigger
in Firebird, but is it significant?

Right now bug #18574 has 222 votes.  When will the total be considered significant?
uhm, I would say apply that 2 patches, reenable MNG-Support and then start to
get rid of the other duplicate functions, as you said. Afterwards somebody
should look at other libs, if we have more unused code...;)
Why should we drop 16bit support, if it would add the risk to see broken
transparency? Remember the crying web developers about MSIE's broken PNG
transparency!
AIUI, the #ifdef would simply make MNG reuse the 16-bit code from imglib2...
please correct if wrong.
Skewer:
That's not what Glenn is suggesting. There's a ton of 16-bit functions in libmng
relating (obviously) to all the specific MNG mechanisms with regards to
image-manipulation. There are really very few area's where I'd expect 16-bit
animations to popup just yet, and removing that code can save a few dozen more
KB's. But it would break a MNG with one or another level of 16-bit manipulation.
No, there isn't any MNG 16-bit code in imlib2.  The images would get reduced to
8-bit immediately upon being read, and then processed as if they had been 8-bit
all along.  This can be done safely, but as I mentioned before there is a
possiblity of some pixels being displayed with the wrong transparency (this
would probably only happen in carefully-crafted 16-bit MNG files designed to
exhibit the shortcoming).  Another approach which is also safe and isn't
vulnerable to this problem, but consumes more resources while processing MNG
files, is to promote everything to 16-bit--probably a useful tradeoff of speed
and memory use versus disc space for rarely used functions.
but the ability to display 16bit images is the biggest advantage of MNG over
animated GIF
By 16-bit gerard and I mean 16 bits per sample (64-bit pixels).  GIF has 8-bit
pixels and the advantage you are talking about is PNGs 24-bit and 32-bit pixels.

ah, ok... I don't see any real use of 64bit pixels ;)
Glenn:
When I think about it I don't really the 'promote all to 16-bit' approach.
libmng already uses a fair amount of memory and suddenly changing all inline
images to 16-bit RGB(A) will certainly not improve it. And then the next reason
to cut MNG support is its copious memory-requirements, which is more of an issue
in the embedding area than diskspace....

(ps. I'm starting to dislike these midair collisions...)
We could restrict the `promote to 16-bit' approach to certain rarely-used
features.  I've tried it with just the MAGN chunk processing and saved about 6k.
Run-of-the-mill simple animations would not be affected.
I've checked in some changes to the libmng CVS which should reduce the library
size another 12-15k or so.  The main change is that all objects are promoted to
16-bit RGB or RGBA before processing the rarely-used MAGN chunk.  There's no
change in the macro set described in patch id=124314 that is attached to this bug.
Hardware: PC → All
In case it's not obvious to everyone here, you can't test the new libmng against
the current Moz CVS without reinstalling MNG.  Instead, revert to moz-1.4b. 
Remember to record the "before" size of
lib/mozilla-1.4b/components/libimgmng.so.  Then copy the *.c and *.h files from
libmng's CVS into mozilla/modules/libimg/mng and edit libmng_conf.h to add the
#defines from comment #6 above.  Rebuild, then record the "after" size of
libimgmng.so.  There are links to libmng's CVS from http://www.libmng.com .
Hi, this is something new to me but i'd like to add my two cents.

I guessed libmng already made use of libpng and libjpeg functions so not to
duplicate code. If that's not completely the case, it's obvious the api's and
code should be reworked to reuse everything. Maybe implementing a common library
with all interesting functions.

I see the mng specification defines two subsets, MNG-LC and MNG-VLC. Maybe it
would help to compile the library to just support some of this subsets. Besides,
it could be good to define a new subset of minimal features interesting for the
web and modify the library so we can compile it to support only that subset.
Later it could be extended when appropiate to the complete specification.

In order to get MNG support back in Mozilla we must work 2 fronts, the libmng
implementation and the Mozilla integration (maintainer). I hope to see those
solved soon.

Is there a MNG mailing list to discuss this?

Bernardo
It uses libjpeg but is independent of libpng.

I don't see saving a few 10k as a good reason for crippling the existing libmng
to support a smaller feature set.

The main reason that it is a lot larger than libpng is that libmng is writtin in
a 21st century coding style that doesn't worry much about 10s of kilobytes of
code size.  If there are 10 slightly different things to do, it uses 10 slightly
different functions to do them, while the older libpng would use multpurpose
functions with internal switches.  The libmng style is faster and easier to
read.  Who would have thought saving a few 10k would be critical in an
application with 25megs of shared libraries? (or 16megs in the case of Firebird?)

Notice that if libmng were crippled to remove the SHOW chunk, which would
probably be one  of the first to go, I would have to rearrange the throbber MNGs
(see bug #195280) so that decoding the embedded PNG file would take place every
time around the loop instead of just once, which would have an adverse effect on
resources consumed while decoding and playing the animations.
Forgot to mention that the mng discussion list is
mng-list@ccrc.wustl.edu -- write majordomo@ccrc.wustl.edu to subscribe.

I'll try to quantify how much the library size could be reduced by removing
the Delta-PNG support.
that's the problem with this bug: it's to do something nobody except pavlov
would care of :p
of cource it's understandable, if we try to make the Mozilla-firebrd tgz
smaller, but there are other placed, where we can get 500K compressed and nobody
does it!
Glenn: how much is saved, if we use libpng for everything, where it is possible?
This could be a compile-pref in libmng like --use-libpng ;)
Glenn: I wasn't refering to changing the code style, I wouldn't do that, but
trying to reuse as much code as possible. Maybe libpng could be updated to use
functions from libmng that could go into a common library. The way I see it they
could share a lot of code. I haven't ever seen the code so I can't talk much
about it.

The problems are: low usage and excessive footprint. The first one is gonna get
worst now, if we only could maintain a certain level of mng support in
mozilla... maybe finding a maintainer and doing a custom compilation without
crippling the base code. Maybe isn't worth the work, I know.

Could the xisting extension be packaged with the installation package at least
as an optional module? It would make sense, it's been supported natively for a
long time.

Excuse me if my comments aren't appropiate, I'm just trying to see the possible
solution.

Bernardo
Kai, Glenn: Re: comment 41 -

PNG is a strict subset of MNG, right? Could we save 38K (or more) by using
libmng for all our PNG decoding, and drop the use of libpng completely? That
would get us incredibly close to the original size of libimg2, and would
probably be easier than rewriting libmng to use libpng. Am I on track here?
Kai: I don't know how much would be saved.  Not a whole lot; just some of the
utility things like CRC calculation, error handling, etc., could be combined.

The libpng-based MNG codec in ImageMagick is 94k but it doesn't handle
delta-images, PAST chunks, the important SHOW chunk, and a few other things that
libmng does.  It does have write capability and handles PNG and JNG.

I've made a quick cut at #ifdef'ing out Delta-image support from libmng and
it looks like about 26k savings, maybe 30 if I worked harder at it.  I don't
think that's enough (no one has answered my comment #21 about what is enough) to
warrant crippling the library and the ensuing confusion when browsers can
support delta-encoded MNGs if the system library is used but not when the
embedded library is used.  The other changes I have already suggested have no
impact on the feature set.

Ballard:  Using libmng for all PNG processing has been suggested before and was
rejected because libpng is more mature.  I suggested that to make more testing
possible, PNG files with the .mng extension should be processed with libmng (in
1.4b they seem to be processed with libpng).  That way you could just copy
file.png to file.mng and then view them side by side.  If we gain enough
confidence in libmng that way we could dispense with libpng and save the 38k.
Remember that part of the equation is that the throbbers are smaller and
better-looking as MNGs.  See the attachments to bug #195280.
well, he said me this yesterday:

"<stuartk> when tor comes to me and says we can add mng support for 25-35k we'll
discuss it"

..we had 84k at that situation, -38 for libpng, -30 for delta (how "usefull" is
that?) gives only 16kb - now he REALLY needs new arguments ;)
re comment 43: see bug 48893 about using the mng decoder for decoding PNGs
I tried to vote for activity, not to destroy this library.  Did I do that? 
Also,  check out http://encompass.sourceforge.net it reminds me of a good
browser i used once. I made the mistake of thinking java web thingies would make
the web more fun.  Please don't make the same mistakes i made.  It is so important.
Carol:  I guess you voted for activity, as did I, but votes on this bug could
be considered ambigious.  MNG fans and MNG opponents will probably both count
them in their favor.  Cast votes for MNG restoration in bug #18574 and votes
against in bug #195280.

The most useful comments here will be of the form "I followed the instructions
in comment #46 on xyz platform with gcc-x.y.z compiler and here are the
before/after sizes".
 ...instructions in comment #36 not 46.  grrr.
would it be possible, to recreate the XPis based opon the modified libmng? This
might be a base to show, that it's possible to make this smaller...
generally yes, but I currently lack the time to do so.
Note that the gcc3 linux xpi was made with a slightly updated libmng, after the
first attempt to reduce footprint (using my patch attached to this bug & libmng
from cvs at that time)
It's interesting to note that although libimgmng.so is larger than
libimglib2.so, its redundant coding style makes it somewhat more
compressible,so its effect on download size is relatively smaller:

    227808 libimgmng.so
    218152 libimglib2.so
     89553 libimgmng.zip
     90096 libimglib2.zip
     89428 libimgmng.so.gz
     89970 libimglib2.so.gz
     87494 libimgmng.so.bz2
     89325 libimglib2.so.bz2

(These figures are for my current working version on FreeBSD/gcc-3.2.1)
Ah, good info to have if I or somebody else gets a chance to complete bug 55930.
In bug #18574 comment #148, Cosmin suggested:

"In my personal opinion, it is a good idea to drop the 16-bit support since only
8 bits are rendered anyway, but it is not a good idea to drop Delta-PNG.
Notwithstanding the portability of MNG files, Delta-PNG is one of the key
features of MNG, that can make a big difference in compression, compared to GIF.

"I also wish to make a suggestion: since efforts are concentrating towards
reducing the libmng footprint, isn't it possible to redirect some of these
efforts towards replacing the entire libpng with libmng, for PNG rendering? I
understood that libpng is older and more reliable -- which means that more
efforts should be concentrated around more libmng testing. What else would be
required?"


We cannot drop 16-bit support without also dropping Delta-PNG support, because
the binary transparency (GIF-like) feature couldn't be trusted.  Suppose
graylevel 0x0000 is opaque and graylevel 0x0001 is transparent.  If they
are reduced to 8-bits, both will become 0x00 and the transparency information
gets lost or at best ambigous, if the object is used later in a Delta-PNG.

We also shouldn't drop 16-bit support if libmng is to be used to render PNGs,
since 16-bit PNG images are likely to exist, relatively more so than 16-bit
MNG images.

If/when Gerv gets back to us with the requirements, we'll know more about
which features can be retained and which will have to be sacrificed.
My comment #21, asking for filesize goals, has gone unanswered
for a month now, despite Gerv doing some prodding.  Rather
than wait longer for an answer I'll just state what can be
achieved.

I've checked in changes to libmng-1.0.6 (follow link to
CVS at http://libmng.sourceforge.net/downloadlibmng.html)
which, with the appropriate set of #defines (as shown in
the attachment), reduces "size" of libimgmng.so (as found
in Mozilla-1.4) by about 105k on my FreeBSD/gcc-3.2.1 platform.
Another 20k reduction can be achieved by removing 16-bit support,
and still another 20k by removing Delta-PNG support, via
additional #defines.
I wrote: "Another 20k reduction can be achieved by removing 16-bit support,"
but that 16-bit support is already removed by the default settings that got
the 105k reduction.

Incidentally, 16-bit datastreams are still viewable because libmng
converts them to datastreams with 8-bit samples before processing them.  As
mentioned earlier, this does pose a risk that the transparency will be
incorrectly rendered or ignored in 16-bit files using GIF-style transparency.
I think the risk is small, though, because 16-bit files are only going to
appear on the web as test files.  Real content is likely to be limited to
files with 8-bit samples.

../glennrp
Measured in the same manner as comment 23, the current cvs tip
libmng/mozlibmngconf.h gives a MNG decoder footprint of 112K.

tor,

comment 23 already contained some optimization IIAC. Can you give an indication
of the total savings from the moment this fun exercise began?
Again measured as in comment 23:

  MOZILLA_1_4_BRANCH libmng:         189K
  tip libmng-devel/mozlibmngconf.h:  112K

tor's result is fairly consistent with mine.  It reflects the "removal
of unused functions in libmng" and "removal of 16-bit support in libmng"
totaling 79k reduction of filesize of libimgmng.so on FreeBSD/gcc-3.2.1,
that I had reported recently in bug #18574:

"Current situation with MNG reduction, on a particular platform
(FreeBSD/gcc-3.2.1) is about 179k:
  62k removal of redundant and unused functions in libmng,
  50k removal of unused functions in libpng,
  17k removal of 16-bit sample support in libmng, and about
  50k merging libmng and libimg2 to avoid storing two copies of the jpeg
library, as demonstrated by tor.
  IMHO that is enough.  How about putting MNG back on the trunk now?
  Additional 7k could be obtained by removing Delta-PNG support but I don't
recommend that, and about 13k by removing JNG support but I don't recomend that
either."

Can someone provide figures for Windows?

It would really be nice to get MNG back on trunk to facilitate fixing and
testing the fix for bug #196670, which needs to be fixed for 1.4.x
Glenn:
   
I might be able to provide some statistics, but I'm using MingW here. So someone
with MSVC should also do. 

(Damn guys in 195280 backed it out of the tree entirely! Arrgh!. But for some
reason --enable-image-decoders=mng still gives a MNG enabled makefile)

CC'ing myself
I received a private answer to comment #21 yesterday from pav.  I assume it'll
be posted shortly.  It isn't very generous and doesn't allow any credit for
recent and future savings achieved elsewhere in libimg or in throbbers.
Even if libimg can be revised to restore MNG support and not lose any of
its current functionality, while being no larger than the libimg in moz-1.4,
that wouldn't be enough. (I can't achieve that yet but have gotten within
about 30k of that goal, depending on platform, compiler, compiler options,
and how much functionality is removed from the MNG decoder).
Glenn: What kind of requirements were you given? And if they are just simply
impossible to meet, have you discussed this with drivers?
Here is what was sent:
----------------------
To restore MNG to the tree, we require that a serious maintainer for the MNG
decoder step up.

The footprint requirement depends on the MNG profile chosen to implement.  For
Linux optimized builds, we'd like to see the additional code footprint to
imglib2 be the following (not cumulative):

   * MNG-VLC + JNG: 10K
         o Should be able to add on to the PNG decoder using libpng for
           well under this size
   * MNG-LC + JNG: 20K
   * MNG + JNG: 50K
         o Will likely require removing libpng...

If the method taken to achieve the footprint requirement involves removing
libpng in favor of using libmng for PNG decoding, the following additional
requirements come into effect:

   * libmng must be up to the quality/stability level where the libpng
     developers are willing to recommend using libmng for PNG handling
   * libmng+decoder must be no slower than libpng+decoder when decoding
     PNGs
   * libmng+decoder must use no more memory than libpng+decoder when
     decoding PNGs

We'd rather not lose libpng, as it's a known and trusted codebase.

My guess is that you don't want a partial MNG implementation, so lets look at
the full numbers.  The latest numbers for an optimally compiled MNG decoder is
112K.  A 50K drop from its previous size, but still too big.  If libmng was able
to replace the PNG decoder in its current state you could reduce the overall
number by another 38K or so bringing you down to 74K, leaving 24K.

I realize these numbers are tight, but I strongly believe that they can be met.
 I am willing to help.  You have said said removing Delta-PNG and JNG would
remove about 20K... That would put MNG really close.  If you want to do that and
continue to shrink the library by tightening code and at some later point when
you have enough savings turn them back on that could work. 
----------------------
Stuart: why didn't you just say "I don#t want MNG back ever"? Then Glenn didn't need to do all this 
work. You know, that it's silly to say "reduce libmng to 30% of it's file size". 
 
Glenn: I thing KDE/konqueror could need somebody to implement JNG-Images and fix some 
problems with MNG, I think your work is much more welcome there. 
The real problem
----------------
Most of us will now have recognized that this bug is not only about technical
arguments anymore. Emotions and bad communication play a major role. This is
nothing special in any company or community. It's not too difficult to solve
either, as long as we recognize it and are able to forgive and forget.

The solution
------------
I propose to:
- Fix the most voted bug by putting the improved MNG code back in the tree.
- Thank Glenn for the good work done optimizing the MNG code.
- Thank Pavlov for all the good work that he put in Mozilla.
- Leave this bug open to reduce the MNG code size even more.
- Glen and Pavlov get together to drink a few beers. 

Afterthought
------------
Arguments like this is what will make talented coders like Glenn and Pavlov
leave. We should not allow that.
Current "size libimgmng.so" of my working copy on
the FreeBSD/gcc-3.2.1 platform is 100283 bytes.
"size -t libmozmng.a" is 70005 bytes.  These compared
to the original Mozilla 1.4 sizes of 288429 and 182715
bytes, respectively.


It's crippled, though, with JNG, DeltaPNG, 1, 2, 4, and
16-bit sample support and PAST chunk support removed.
MNGs with sub-8-bit and 16-bit samples are viewable; the
samples get promoted or demoted to 8-bit for processing
(the same way they were handled in libpng all along).
People who use the system-libmng would regain those features.

I don't think 50k can be achieved.

Skewer:  Some of us involved in MNG support did write to
drivers on 27 July but haven't heard anything from them.
Can we remove the BMP image decoder to make room for MNG? I think it's unanimous
we'd rather have MNG than BMP.
That wouldn't work.  Savings in other areas of libimg don't count.  Also
no one seems to care about saving a few k anyway.  My patch for reducing
libpng another 5-10k in addition to 50k already saved by me to make room
for MNG support has been lingering in bug #208607 for a couple weeks
without any response.  I have also reduced my own copy of the jpeg library
significantly, too, but why bother?
We'll have to wait on drivers then... It's ultimately up to them to decide if
MNG is a valuable thing to have in Mozilla or not. Fortunately the option is
always open of starting a new distribution of Mozilla with MNG hacked in.
MNGzilla, we could call it...
New mozlibmngconf.h for use with libmng-1.0.6 that was checked in to CVS today
17 August 2003.  Sets #defines to build 50-kbyte MNG-VLC-supporting library. 
Can be manually edited to provide other levels of support up to full MNG
support.
Attachment #124314 - Attachment is obsolete: true
Attachment #127203 - Attachment is obsolete: true
Blocks: majorbugs
What happens when a valid MNG, but invalid MNG-VLC file is loaded?  Should that
depend on how much of the required featureset is not available?  The
content-type and extension are the same for both file types, so there is no way
to tell the difference until the bits/chunks are read.
Also, is there an easy way to turn full support on without editing any files?
(Just a build option).  If not, there really really should be.
Thanks for your work thus far Glenn.
When a valid MNG containing chunks outside the MNG-VLC feature set is processed,
the user receives the generic "image could not be displayed because it contains
errors" message.

There will be an easy way of turning on limited or full MNG support via
a configuration option such as "--with-mng-vlc" or "--with-mng" or and
"--with-jng".  This particular patch doesn't provide
those because it changes libmng, not the glue.

This should make it relatively easy to create "unofficial builds" with
various degrees of MNG support.  How many such degrees are worth supporting?
Maybe just the two: mng-vlc and full MNG with JNG. Drivers have requested
MNG-VLC by default and full MNG configurable.
>When a valid MNG containing chunks outside the MNG-VLC feature set is processed,
>the user receives the generic "image could not be displayed because it contains
>errors" message.

I know it may be difficult to work around, but I don't think that error message
is appropriate at all.  In reality, the image does not contain errors.  I would
suggest one of three alternatives:
- the chunk is ignored and whatever can be salvaged is displayed
- a message explaining that full MNG is not supported is displayed
- the image is replaced with a placeholder
In each of these cases, a click, popup, or notification (info icon in status
bar) could lead to a full MNG download page

If this isn't done, I can imagine the large number of bugs that will be reported
and resolved Invalid by people with full MNG images who try to use Mozilla.
> Drivers have requested MNG-VLC by default and full MNG configurable.

I wonder why drivers are so obsessed with the total size of the MNG library? Is
there any valid reason to limit MNG support to MNG-VLC?

As I recall version 1.4 of the Mozilla Application Suite and all older versions
contain a fairly correct working implementation of MNG.

Even after a size reduction the drivers still reject MNG as a main part of the
application. (Actually i wonder why MNG support was removed at all, however the
drivers might have valid reason to accept such a patch).

In my opinion it is better to have no MNG than to have a crippled version of it
(like IE's implementation of PNG). If we want to move the web forward we must
implement the standard well, or we shouldn't implement the feature at all.

I can't think of a Mozilla without MNG, but it seems the drivers have a
different meaning, as you can see in bug #18574. Even though MNG has been in
Mozilla for ages they have formed the opinion that its not important to have
full MNG support in the next stable release...
I didn't say the generic error message is appopriate.  I'm just telling you what
happens.

Libmng will produce a nice error message saying that an unrecognized chunk is
present.  Unfortunately Mozilla ignores any helpful error messages from libmng,
libpng, or libjpeg, and displays the quasi-useless generic "image has errors"
instead.  That should probably be the subject of another bug report if it isn't
already.
This mozlibmngconf.h is for use with libmng-1.0.6 from libmng's CVS 18 Aug 03. 
It understands MNG_CFLAGS=MNG_BUILD_VLC, MNG_BUILD_LC, or MNG_BUILD_FULL_MNG,
which can be passed in via the configure script.
Attachment #129962 - Attachment is obsolete: true
Yep, my point is that there's a ton of extra work going in/will need to go in to
support a lesser standard.  Completely illogical.  Anyway, let's try to keep the
noise down in here and keep this to technical issues only.
Bug 216538 has been added for custom image decoder errors.
Strictly speaking, MNG_BUILD_LC is a misnomer because the resulting library does
 quite a lot more than the MNG-LC specification requires.  For example, it
processes MOVE and CLIP, can deal with multiple objects, and process JNGs.  The
name MNG_BUILD_VLC is fairly accurate although it does a little more than
required; I couldn't bring myself to remove gAMA, sRGB, BACK, and TERM support,
although the #ifdefs are there to remove them if someone insists.

I'm interested in seeing the results (library sizes and whether they work) of
building Mozilla-1.4 (or Firebird 0.6) with the three configurations,
MNG_BUILD_VLC, MNG_BUILD_LC, and MNG_BUILD_FULL_MNG, on various platforms.
More accurately,
I'm interested in seeing the results (library sizes and whether they work) of
building Mozilla-1.4 (or Firebird 0.6) with the three configurations

MOZ_MNG_CFLAGS=
MOZ_MNG_CFLAGS=-DMNG_BUILD_LC
MOZ_MNG_CFLAGS=-DMNG_BUILD_FULL_MNG

on various platforms.  On FreeBSD5.0/gcc3.2.1, I obtained

                        size libimgmng.so   size -t mozlibmng.a
Original MNG-1.4                288429           182715
MNG_BUILD_FULL_MNG              239922           150008
MNG_BUILD_LC  (includes JNG)    174797            86198
New Default (MNG_BUILD_VLC)      77526            50973

                   


Whoo! That means that, thanks to the butting in of our anti-MNG Mozilla
superiors... we've saved our 56K users about *20 SECONDS* of download time on
the default build by sacrificing any reasonable implementation of MNG. And our
broadband friends will save about ONE second.
I agree. This borders on the realm of absurdity. However, all the hard work that
was put in to this bug is still appreciated.
I wrote: On FreeBSD5.0/gcc3.2.1, I obtained

                        size libimgmng.so   size -t mozlibmng.a
Original MNG-1.4                288429           182715
MNG_BUILD_FULL_MNG              239922           150008
MNG_BUILD_LC  (includes JNG)    174797            86198
New Default (MNG_BUILD_VLC)      77526            50973

I left off two interesting configurations:

MNG-1.5                              0                0
MNG_BUILD_LC (without JNG)      104422            73329

Note that these are all uncompressed sizes.

JNG is big. So MNG-LC - JNG is the best solution for now. 
JNG is about 13k uncompressed.  It only *looks* big when enabled in Mozilla-1.4.
 In the future it would be integrated with libimg so we don't get the penalty of
an extra copy of libjpeg in the library.  That has already been demonstrated.
That may well be, but lets go in baby steps.

Drivers: Based on the information listed in the sizes above, will MNG-LC -JNG Be
an acceptable starting point?

This would seem to allow for an animated GIF replacement, allow for cost savings
in other parts of Mozilla (Chrome), and give us what I believe is a firm basis
for work on the MNG format.

Following this, the 'G' team can work on integrating PNG by replacing the
libjpeg duplication, and so on.. a step at a time as approved.

MNG-LC without JNG seems to me to be the best compromise - it allows for GIF
replacement, while keeping the size small as well.

How about it Drivers?


  JNG is about 13k uncompressed.  It only *looks* big when enabled in
  Mozilla-1.4. In the future it would be integrated with libimg so we don't get
  the penalty of an extra copy of libjpeg in the library.  That has already been
  demonstrated.

How much work would be involved for you to do that now? It's probably better to
integrate MNG/JNG/imglib all in one now, which would likely fix this bug and
also help make sure that MNG and JNG are always a part of Mozilla.
Integrating MNG with the rest of imglib in libpr0n would be the job of the new
libimg maintainer, not me.  Also I think it would interfere somewhat with the
modularity and configurability.  I'm perfectly willing for the default to be
MNG-LC (plus) while JNG is configurable but not in the build by default.  The
"baby steps" way that has been mentioned several times would be to first put
things back the way they were in moz-1.4, then apply my library reductions to
whichever configuration is acceptable to drivers, then work on integration of
libmng and libjpeg.  I can provide optimization to libjpeg that would offset a
large part of the 13k that the JNG support requires.
The header file now recognizes macros
   MNG_BUILD_FULL_MNG
   MNG_BUILD_WEB_MNG
   MNG_BUILD_WEB_JNG
   MNG_BUILD_LC
   MNG_BUILD_LC_JNG
   MNG_BUILD_VLC
The MNG_BUILD_WEB_MNG was previously MNG_BUILD_LC
and MNG_BUILD_LC now builds approximately according to the
specification for MNG-LC.
Attachment #129982 - Attachment is obsolete: true
Restored PAST chunk support to MNG_BUILD_WEB_MNG and MNG_BUILD_WEB_JNG
configurations.  These two configurations become about 5kbytes larger.
Attachment #130145 - Attachment is obsolete: true
Added MNG_BUILD_MOZ_MNG configuration which is a full mng implementation with
only features actually unused by mozilla removed.  It does support JNG and
DeltaPNG.  16-bit support is handled by downgrading to 8-bit while reading.

Sizes: mozlibmng.a is 107877 and libimgmng.so is 200835 bytes on my platform.
Attachment #130171 - Attachment is obsolete: true
Glenn:
according to what drivers said, can't MNG be checked into the trunk now,
configured completely off from default builds? We could apply your size-reducing
patches then and do test builds as well as personal builds with MNG or subsets
of it enabled.
Or do we need a maintainer for the few hundred lines of libimg2 glue first? Who
does volunteer for that?
Yes, it could.  I think all that would need to be done is to put it back in
exactly as it exists in Moz-1.4, then remove " mng" from the
MOZ_IMG_DECODERS_DEFAULT configuration variable.  Then add a "--with-mng"
configure option to put " mng" in that variable.  Only problem is we need
someone who is both empowered and willing to do so.  Then we could proceed
with r/sr of the footprint-reduction patch that creates MNG_BUILD_MOZ_MNG
configuration (maybe waiting until Gerard releases libmng-1.0.6), and continue
debate about what version could be included in the default configuration.

Yes, we need a maintainer for the MNG-related libimg glue.
There is so much activity here, I cannot catch up with this mess and save myself
financially here in the good ole' usa.

I am in need of a good browser with mng support, and any other free file format
that might come along, without all the ****.

Later today, I hope to set up a file sharing system and web site for a personal
browser I am in desparate need to build.  Hopefully there will be a maillist
also.  I even have a logo in mind as well and a need to work through a tutorial
that will show me how to say "Hello World" with GtkWindow.

If you are interested; or if you have already completed this tutorial and know
how to hook gtkhtml2 up to a GtkWindow or better yet, know how to speak to
andersca (I have had very little success with this myself) please drop me an
email at carol@det-tour.org.

Also, anyone have a good suggestion for a bug reporting system?  This one seems
to be broken.

http://www.ckdhr.com/hrose/songs/ship_of_fools.html

also, since this bugzilla.mozilla.org thing seems to be all about money, please
send your messages here as well
https://www.paypal.com/xclick/business=carol%40gimp.org&item_name=det-tour+browser+project&item_number=003&no_note=1&tax=0&currency_code=USD

thanks for all of the bugzilla practice :)
Carol... Please refer to Bug 18574 for general pro-MNG advocacy and discussion.
This bug is for technical discussion about putting MNG back into the Mozilla-trunk.
Thanks ;-)
libmng-1.0.6beta1 is available for testing.  Get it from the download area
or from CVS at libmng.sf.net.  Try it with moz-1.4.
Flags: blocking1.6a?
Flags: blocking1.7a?
Flags: blocking1.7a? → blocking1.7a-
libmng-1.0.6 final is released for a long time ... and I will make a mozilla
distribution with enabled MNG.

Have someone patches for the trunk so I can try?
Go to mozillazine.org and search the "Firebird Builds" forum for
message topic

Nova Win32 G6's: [01/01 w/MNG,DOMi] [12/21 Installer w/MNG]

See also patches in bug #18574 and at http://mngzilla.sf.net
After uploading some MNG enabled mozilla builds to mngzilla.sf.net and updating
the MNG patch on #18574 I will step into the code reduction patche / adding
parameter to configure and try to resolve #121927

If there is no one who want Maintain the mng glue code, I will do it if nobody
is against this.
As this bug is about MNG size let me post this here rather than in bug 18574.

With the current discussion on aPNG I got interested in how large MNG really it.
So I built a few configurations of imagelib and MNG on the weekend. I used the
current trunk on OS/2 and opi's latest patch to create optimized, stripped OS/2
DLLs.

These are the numbers I got:                   total size  difference
(hope this table comes out well in            imglib2.dll+
 Bugzilla)                                      imgmng.dll

--enable-image-decoders=default                 108.0 KiB    ---

--enable-image-decoders=default,mng
--enable-mng-type=MNG_BUILD_WEB_NO_JNG          164.4 KiB  +56.4 KiB

--enable-image-decoders=default,mng,-png
--enable-mng-type=MNG_BUILD_FULL_MNG            206.9 KiB  +98.0 KiB

--enable-image-decoders=default,mng,-png
--enable-mng-type=MNG_BUILD_MOZ_NO_JNG          147.4 KiB  +39.4 KiB

--enable-image-decoders=default,mng,-png
--enable-mng-type=MNG_BUILD_WEB_NO_JNG          139.6 KiB  +31.6 KiB

--enable-image-decoders=default,mng,-png,-jpeg
--enable-mng-type=MNG_BUILD_FULL_MNG            170.5 KiB  +62.5 KiB

--enable-image-decoders=default,mng,-png,-jpeg
--enable-mng-type=MNG_BUILD_MOZ_NO_JNG          111.9 KiB   +3.9 KiB

If I understood the discussion correctly, the second option is the GIF
equivalent (which can then not be used as PNG replacement because of
transparency issues), but I might be mistaken. The second last option does not
seem too bad and gives an indication how "heavy" MNG is in itself, after
combined into imglib2 and the doubled JPEG can be saved. 1/3 or the total
imagelib size does not seem excessive to me, JPEG also seems to be 36.4 KiB. (I
guess JPEG is only doubled if JNG is built as well, so the last option is rubbish.)

>If I understood the discussion correctly, the second option is the GIF
>equivalent (which can then not be used as PNG replacement because of
>transparency issues), but I might be mistaken.

I don't know whether or not you would want to use it.  The transparency issue
is only that "cheap transparency" cannot work with 16-bit samples.  I doubt
that such files will exist in the wild but only as test files to demonstrate
that it doesn't work.  But libpng is so small now that who really cares?
Compare two of your cases where the only difference is one was built with
mng and the other with mng,-png and you can calculate it yourself: about 25k.
When libpng-1.2.7 lands it will be even smaller.  And, although I have not
test data, I think libpng is always going to be faster than libmng, because
it is tuned to single-image decoding, whereas libmng generally doesn't know
ahead of time whether the PNG it is decoding will need to be saved or can
just be splatted on screen and forgotten.

Notice that only FULL_MNG took the 200-300k that is always bandied about,
and it was a lot closer to 200 than 300.  Libmng-1.0.9 will also bring down
the sizes of all configurations except FULL_MNG, if I happen to check in
my latest set of changes.  If you want to establish the upper limit, post
results for MNG_BUILD_FULL_MNG/default,mng (but recognize that fixing the
double-jpeg problem will save some 35-40k).
I think the best is MNG_BUILD_MOZ_MNG profile.
The MNG_BUILD_WEB_NO_JNG profile is the one that was requested by drivers.
(In reply to comment #102)
> And, although I have not
> test data, I think libpng is always going to be faster than libmng, because
> it is tuned to single-image decoding, whereas libmng generally doesn't know
> ahead of time whether the PNG it is decoding will need to be saved or can
> just be splatted on screen and forgotten.

This advantage is probably void once aPNG is implemented. But that is something
I will try: measure page loading of a page with lots of PNGs once with mng,-png
and once without mng.

> Notice that only FULL_MNG took the 200-300k that is always bandied about,
> and it was a lot closer to 200 than 300.

I don't understand what you are saying (only->once?). But in the 1.4.x OS/2
builds MNG was still 151.9 KiB.

(In reply to comment #103)
> I think the best is MNG_BUILD_MOZ_MNG profile.
> The MNG_BUILD_WEB_NO_JNG profile is the one that was requested by drivers.

Will build this one, too, and post the results.
(In reply to comment #103)
> I think the best is MNG_BUILD_MOZ_MNG profile.
> The MNG_BUILD_WEB_NO_JNG profile is the one that was requested by drivers.

These are the numbers I got:                   total size  difference
                                              imglib2.dll+
                                                imgmng.dll   

--enable-image-decoders=default,mng,-png
--enable-mng-type=MNG_BUILD_MOZ_MNG             186.9 KiB  +78.9 KiB

That configuration should probably not used to replace the PNG decoder (like in
the posted configuration), because the 16bpp (?) transparencies don't work. But
as the difference between this +PNG and FULL_MNG -png is negligible one could as
well use FULL_MNG where this works. Well, I will continue to build FULL_MNG -png
and report any unusual behaviour.

(In reply to comment #102)
> And, although I have not
> test data, I think libpng is always going to be faster than libmng, because
> it is tuned to single-image decoding, whereas libmng generally doesn't know
> ahead of time whether the PNG it is decoding will need to be saved or can
> just be splatted on screen and forgotten.

OK, did that comparison:

--enable-image-decoders=default,mng,-png (MNG_BUILD_FULL_MNG) gives:
Avg. Median : 769 msec		Minimum     : 380 msec
Average     : 918 msec		Maximum     : 3724 msec

--enable-image-decoders=default,mng gives:
Avg. Median : 767 msec		Minimum     : 390 msec
Average     : 932 msec		Maximum     : 3780 msec

with the pageloader testsuite from
<http://weilbacher.org/Peter/png-testsurls.zip>. So there is no real difference
between both configurations. But as this was done with a few days old trunk
checkout on OS/2, I guess someone should try to reproduce it on another platform...
> the 16bpp (?) transparencies don't work.

What doesn't work is PNG "cheap transparency" (that's GIF-style transparency
where you name a single color as being transparent) with 16 bit-per-sample
images (i.e., 16-bit-per-pixel grayscale or 48-bit-per-pixel RGB).
Are there any real numbers on the difference in code size between a build with 
PNG support and a build with MNG support, using the settings that would be 
checked in if they were to be checked in, on either Windows or Linux?
(i.e. the difference between a build based on fresh cvs tip pull, and a build 
based on an fresh cvs tip pull with the patch applied.)
Re comment #107: Amano reported the following code sizes on Windows:

  I turned off the picure caching feature in Windows XP and removed all
  of the hidden Thumbs.db files. Here the updated results (from the Windows
  "Properties" dialog):

  MNG, PNG &#9658; 14.770.733 Bytes
  MNG,-PNG &#9658; 14.729.758 Bytes
  PNG &#9658; 14.672.368 Bytes

  all with the same 352 files and 21 subfolders.

i.e., about 98k increase when adding the MNG_BUILD_FULL_MNG configuration,
and saving about 41k when removing libpng support from that.

Opi posted a new patch today to bug #18574 but it won't have much effect on
the sizes.
With latest patch set (with mng inside libimg2) we have new results for my
system: see http://opiswelt.de/plog

Would be nice to get new comparisons from Amano.

After all I would mark this bug as Invalid or duplicate of the mng reintegration
bug, cause the reintegration patch have all known space reductions in it.
Here are some sizes (size *.so) with Opi's latest (mng-1.0.9, 4 Feb 05)
patch, on the FreeBSD platform:

   Mozilla-1.8b w/libpng, no MNG support:             214618 bytes
   MNG_BUILD_MOZ (full MNG support, no libpng):       307083
   MNG_BUILD_WEB_NO_JNG NO MAGN NO 16BIT with libpng: 295076    
   MNG_BUILD_WEB_NO_JNG +16BIT NO MAGN no libpng:     265859

Note 29k savings achieved by restoring 16-bit support to the WEB configuration
and using it to supply PNG support.  Manually removing MAGN support saved
about 7k, and required a minor change to libmng_display.c which has been
checked in to libmng's CVS.
No longer blocks: majorbugs
Comment on attachment 130175 [details] [diff] [review]
Mozlibngconf.h with MNG_BUILD_MOZ_MNG configuration

More recent patches in bug #18574 have made this patch obsolete.
Attachment #130175 - Attachment is obsolete: true
Why don't you resolve it as FIXED/DUPLICATE/MOVED to bug 18574, as it doesn't truly block that bug any more.
(why don't you resolve it)
Either that, or we could move the patches over here.  The patches serve two purposes: reduce the footprint of libmng (this bug), and restore mng/jng to the trunk (bug #18574), so they are appropriate to upload to either bug.
So, has been a year.
Is this bug considered fixed?
Just as a user who keeps hoping to use JNG someday.
Current patches and executables are at mngzilla.sf.net in the DOWNLOAD area.
Aye, I know and appreciate the patches personally.  Just hoping things are moving forward to having the tech be sufficiently accessible that a reasonable fraction of people visiting could view JNGs instead of the PNGs.

So, was wondering if this bug was considered resolved, and if that would finally allow things to move forward, or if someone was just kind of hoping MNG would crawl off in a corner and die.
> Aye, I know and appreciate the patches personally.  Just hoping things are
> moving forward to having the tech be sufficiently accessible that a reasonable
> fraction of people visiting could view JNGs instead of the PNGs.

As things stand, the size issue this bug here is about is just a pretext. Current image lib module owners simple just don't want MNG/JNG. Their alleged replacement APNG never got anywhere.

> So, was wondering if this bug was considered resolved, and if that would
> finally allow things to move forward, or if someone was just kind of hoping
> MNG would crawl off in a corner and die.

Some may, I don't.
The currently only reasonable way I see is a MNG component in SeaMonkey, somewhere under /suite, and I do think there is a good chance to make that happen. 



The size issue was fixed years ago but never checked in, but now that
bug #18574 has been marked WONTFIX, this one should also be marked WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: