Closed Bug 204520 Opened 22 years ago Closed 18 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: 18 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: