Many of the GIFs were created with the color depth set too high. The worst ones only use 2 colors with the depth set to 8 bit, resulting in a file that is about 10 times as large as it should be.

The attachment is the GIFs that had color depth set too high. I reduced the depth to the smallest size that would allow use of the original pallette. Prior to optimizing the total size of the graphics in chrome was 415 KB. Replacing the unoptimized GIFs with these reduces this to 230 KB.

Marking severity enhancement. Anyone wanna compare all those gifs and verify he didn't sneak in any porn? ;-) Btw, those chatzilla images actually turn out to be a few bytes larger than their originals. Is this worth the trouble though? Does it also make a difference (good or bad) in memory usage or rendering speed?

I don't know how big a differance this would make in memory usage or speed. It would probelly show up more on slower computers, say a P133 with 64M of ram. Mozilla is getting too big. Win-32-installer is the smallest download. The current nightly is up to 6.1M. M16 was 5.5M, M15 was 4.9M Thats allmost a 25% increase in the last 3 months. I would like to see this growth slowed down if not reversed. This is a step in that direction.

setting status to New

GIFs should be size-optimizied by: 1. Optimizing the color palette 2. Removing comments

can this be automated in the build process with ImageMagick?

Is this for a specific theme (which one?) If so, this belongs to Themes.

At the time I submitted this both the Classic and the Modern (now Blue) themes had many of the GIFs set at 8 bit color even though very few have more than 16 colors (4 bit). As an example classic/messenger/skin/file-disabled is set to 8 bit. It only uses 9 colors. Current size is 951 Bytes. Reducing it to 4 bit results in a file thats only 188 Bytes, with NO loss of resoulation. I am working on a new theme based on Classic. This is an area I've looked at closely. By reducing color depth and eliminating unused images (see bug 41079) I was able to produce a theme that is 306 kb vs Classic's 491 kb. The size reduction was not achived by reducing function. The Gold theme has more icons that are used than Classic.

Wouldn't it be much better to use pngs and run the 'pngcrush' program on them?

PNGs would be better, if they worked. Currentally transparancy is horked in Windows (bug 50974). Then there are the problems that caused the Modern skin to be switched from PNG to GIF. (See N.P.M.UI "Changing PNGs to GIFs in the new Modern skin" thread). Right now it's hard to find all the PNG related bugs because there isn't a PNG skin in the build, so it dosen't get tested.

Sending to Marlon.

We're planning to do a final batch process on all GIFs that will optimize the pallettes. For PNG - there's a problem with Mozilla's gamma correction algorithm too, in addition to the trns problem. Then the fact that CSS specified colors are not gamma corrected which precludes us from using PNG in a skin. You can never match colors properly without the same gamma correction everywhere. Oh, and alpha channels are also a problem.

So if people ask why Netscape chose to use GIFs instead of PNGs, we should say that it's because Navigator 6's PNG support is so bad that it's impossible to use PNGs?! Also, you *can* write PNGs without gamma information. These shouldn't be gamma corrected.

marlon: bug # for the css gamma problem? huftis: PNGs without a gAMA are corrected to a default file gamma value.

> huftis: PNGs without a gAMA are corrected to a default file gamma value. Should it? And what's the default gamma value?

Tor: I don't believe there would be a bug for CSS gamma correction because it's not part of the spec anyway. Or is it? It would be great if there were. Karl: PNG support is fine for web pages; but not yet for Themes where we need optimal speed and color matching.

From the PNG specification: http://www.freesoftware.com/pub/png/spec/png-1.2-pdg.html#D.Decoder-gamma-handli ng When the incoming image has unknown gamma (gAMA, sRGB, and iCCP all absent), choose a likely default gamma value, but allow the user to select a new one if the result proves too dark or too light. The default gamma can depend on other knowledge about the image, like whether it came from the Internet or from the local system. ipng.cpp sets a display gamma of 0.45455 (1/2.2) for images without a valid gAMA chunk.

Gamma correction is mentioned in CSS1 and CSS2: http://www.w3.org/TR/REC-CSS1#color-units http://www.w3.org/TR/REC-CSS2/syndata.html#color-units If you want this fixed, file a bug. If it doesn't exist in bugzilla, we don't know it's an issue for you.

Some quotes from the CSS 2 rec.: "Conforming user agents may limit their color-displaying efforts to performing a gamma-correction on them. sRGB specifies a display gamma of 2.2 under specified viewing conditions. User agents should adjust the colors given in CSS such that, in combination with an output device's "natural" display gamma, an effective display gamma of 2.2 is produced. See the section on gamma correction for further details. Note that only colors specified in CSS are affected; e.g., images are expected to carry their own color information." "For information about gamma issues, please consult the the Gamma Tutorial in the PNG specification ([PNG10])."

tor, thanks for looking that up. CC'd you on new bug #53597

accepting. since this issue is so late in the game for RTM, i am not sure we couldcrush them and re-checkin the entire application without some hiccups. yesterday we had gifs corrupted during file checkin, at this point we have no room for error. I will consult Hangas on the viability of this, with expected benefit of file and file size reduction

Themes Triage Team P3, need to know how much room we would save before allowing checkin

*** Bug 96992 has been marked as a duplicate of this bug. ***

Shame on me for not submitting some optimized version sooner. I started off ligth with only a few images - however I handoptimized them.. doing detail work on single pixels. This really improve the quality and visibility of some of them .. particularly the NetscapeSearch.gif I zipped them up because they are easier to handle that way - though with perfectly optimized gifs , zipping them actually increases the filesize. Based on that notion I wonder if having the Chrome UI's in JAR archives is benefitial at all (ofcourse the JAR's contain more than just images so they might still do fine)

I used the 2001092503 windows build as a source for the optimized packages. All the content i the chrome dir have now been optimized. If a specific package was not attached to this bug it is because it was either already optimized to begin with or it did not contain any images. I compiled and used the "Optimizer" demo program for the TGIFimage delphi component available from www.melander.dk to optimize theese gif's. It's optimization is great , but it's interface is sorely lacking in userfriendliness - If someone have a bit of Delphi experience they could add an option to optimize directories recursively .. making the gif-optimization of the entire mozilla project a matter of pushing ONE button .. I have the compiled exe , so if you want it just mail me. Note that the sizereduction in the jar files does not come exclusively from sizereduction of the gif-files , because I used WinAce (with max compression) to compress and create the jar packages. It's simply a more efficient compressor.(maybe I should create a rfe bug on optimizing the jar packages and the installpackages .. all of which can be compressed more efficiently)

OK , with the final images from the res directory , the Gifs (all of them) are now optimized .. until a 2D artist designs new ones or alters theese. The res.zip is meant to be extracted to the root dir where the orginal res directory resides. The zip only contains the updated images with directorystructure so it's safe to extract onto a res dir where other content (other than the images) have changed since the 2001092503 build. This is however not true for the jar packages attached earlier .. they contain _everything_ .. with directory structure.

Soo .. what happens next .. isn't someone going to react and either OK or dismiss the alterations I made ?

CeeJay: could you tell us the size difference this makes? Gerv

On the gif's or the jar-packages ? I dont have the original jar's from 2001092503 , so I can only tell you the current size of them (helpful since bugzilla dont show this) ChatZilla : 89 K Classic : 288 K Embed : 319 K En-US : 483 K Modern : 592 K Comm : 680 K If I compare with 9.4 thats about 150 K smaller total .. but there have been changes between the two .. f.x. the 9.4 dont include the embed.jar as the newer build do. I think we're looking at about 10 - 15 % overall reduction on the jar's .. and I'd guess the real reduction .. that of the gif's is around 30- 40 % overall .. but thats just a guess. Some gif did'nt shrink at all .. some became 20 times smaller. I like the fact that I by handoptimizing can get both smaller AND better results .. the icons really look better and more crisp.

umm.. if they look "more crisp" that would mean that colors have actually been modified/changed/removed. An optimalisation should leave the original images looking exactly as they do today. Anything else would be a change the theme as such.

You're right , they have been modified/changed/removed .. but only the searchplugin icons (4 different little 16 x 16 pixel gif's) .. for two reasons : 1. To see how much more could be gained doing it by hand. 2. Because IMO the current seachplugin icons looked like they were done quickly .. I knew I could improve the quality. .. ALL the other images have not been altered in anyway .. all the pixels are intact .. the searchplugin icons were just a testcase to show it was possible to improve on both size and quality even when reducing the amount of colours. Would you like some non-altered optimized versions of the seachplugins ?

i did a quick once over, and through a random sampling of gif files, the colors appear to all be intact after the optimizations were made. the overall savings was around 8 bytes per gif file. sometimes as much as 100 bytes were saved on larger images. however we shouldn't compare modern mozilla to modern netscape, the two jars vary by quite a large number of bytes. Mozilla's throbber is trice as large as netscape's, for example. but netscape's modern has a number of other images, not included in the mozilla version. the savings however is not 600k. i can't remember the exact number but i believe the savings in mozilla modern vs. optimized modern mozilla was around approx 100k, but feel free to correct me on that.

CeeJay, could you possibly try running this on a recent Netscape (6.1) version of Modern, and tell me what results you get? I would be very interested in your method if it saved us say more than 100k total, and if we could find which images saw the most savings. thanks

we should try to resolve this within next 2 milestone

I agree .. I will be optimizing the Mozilla 0.9.6 and Netscape 6.2 soon. I just need to find some software that will help compare the filesizes before and after .. there are hundreds of images so it would be tedious work doing it manually

Solution for optimizing and comparing - use shell-script (4DOS, 4NT, bash or anything). There are plenty of nice commandline-tools for optimizing. I use that kind of script for PNGs, but I guess that PNG is not an option here .. For 4DOS/4NT it's something like: global /i for %%a in (*.gif) do (optimize %a %@name[%a].opt && if %@filesize[%a,b] lt %@filesize[%@name[%a].opt,b] del %@name[%a].opt && move %@name[%a].opt %a) I haven't tried if that works, but it is supposed to process all GIFs in current directory and all subdirectories with "optimize", which gets two parameters - original file and the file to write to. After optimizing it compares sizes of resulting files and chooses the smaller one. Fully functional demo-versions of 4NT/4DOS can be downloaded from http://jpsoft.com/download.htm

moving out -> 1.0

not a 1.0 showstopper.

Why can't we have png instead of gif now (or may be after the fixing of bug 53597)? I think the support of png format in mozilla is quite complete and the reason why don't use png file instead of gif file is already two years old. and ... adding myself to CC ...

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!

I took another turn at optimizing all the images in the chrome packages of Mozilla 1.0 RC1. This time using Absolute GIF optimizer because that tool could log the process and also process subdirectories. The TGIFImage GIF Optimizer demo program I used previously could'nt process subdirectories leaving me to seek out all the images .. a process that took time. This time it only took a comfortable 10 seconds to optimize 814 images. Add to that some repeat runs because Absolute GIF optimizer does not optimize all the images perfectly on the first run .. much like TGIFImage GIF Optimizer .. in fact exactly like TGIFImage GIF Optimizer .. the two programs look so similar that I'm 90% certain that Absolute GIF optimizer is based directly on the opensource delphi TGIFImage component by Anders Melander. Absolute GIF optimizer costs money so if someone wants the Chrome developers to have a effective and free tool , it would be simple to add the ability to process subdirectories to the demo program (it comes with source) - I can't myself as I'm not a delphi programmer OK .. back to the optimized files. Here are the statistics : Before : 649.693 bytes (100%) After : 560.186 bytes ( 86%) Repeat : 560.027 bytes ( 86%) Saved : 89.666 bytes ( 14%) I'll be attaching optimized .jar files right after this comment. I compressed them with WinAce using Maximum compression to get a slighty smaller footprint This can be done with all the jar files to get a smaller footprint from them too .. I did this too but will only be posting the .jar's containing images If you want smaller .jars in Mozilla and thus save just a few extra bytes , then I reckon it will take a new bug similar to this. I'll also be attaching detailed statistics for each image.

You may notice that toolkit.jar also contained 1 image, but since that was already optimized I did not include it's jar among theese attachments. The repeat runs only removed 159 bytes total so I figured it was not worth showing the logs for them

Marlon do you still want an optimized recent Netscape 6.x ? Btw.. My email have changed since i started using bugzilla .. can I change my email somewhere (i have looked to no avail) or do I have to make a new profile and just forget about the old one ? Another thing .. could someone please obsolete the "Optimized version of ..." attachments. I would do it myself but I do not have the accessrights to do it .. even if I originally posted them

for Chu Alan in comment #49 : If you search for PNG in Bugzilla you will still find bugs that could make the transition to PNG chromes difficult. PNG support in Mozilla is however making good progress so it will most likely happen one day. Bug 8415 covers this subject

Maybe you file bugs against the "mozilla.org" product, Bugzilla misc component (NOT the bugzilla *product* which is for bugs in bugzilla code, not the specific mozilla.org installation of bugzilla) If that doesn't work mail asa@mozilla.org -Dan Veditz

currently to change your bugzilla account, you have to ask a bugzilla admin, asa, dawn, myk, ... some time w/in the next few releases you'll be able to change your account on your own.

Comment #64 worked for me - Thankyou. I can be emailed now with questions , comments or whatever your heart desires ..(sans spam)

Comment on attachment 50875 [details] Optimized version of the Classic chrome Obsoleting as per comment 61.

Comment on attachment 50876 [details] Optimized version of the comm.jar package Obsoleting as per comment 61.

May I recommend gifsicle? http://freshmeat.net/gifsicle I use it to automatically optimize GIFs for web display.

[Gifsicle] It sounds like it could be just what the doctor ordered. It can do batchoptimizing and it's multiplatform. Unfourtunatly I can't test it because the link to the windows compiled executable is broken. You wouldn't happen to have a working link or and executable you could mail to me ?

Gifsicle Maybe we can use GraphicConverter to convert the files in batch ? That's the workhorse for all graphic professionals. I can do it if you like.

Gifsicle doesn't seem to be updated anymore (their website seems to be gone) Maybe we can use GraphicConverter to convert the files in batch ? That's the workhorse for all graphic professionals (but Macintosh only). I can do it if you like.

adt: nsbeta1-

gifscile project seems to be up and running. Last update was yesterday. I am happy to help if anyone states what is the exact status for the bug. http://www.lcdf.org/gifsicle/

I would like to note that this gif issue is not present in Firefox since it uses PNG for everything except animating graphics (which can't be in MNG yet because bug 18574 still haven't been fixed) I haven't yet checked to see if this is still an issue with Mozilla Suite as I haven't used that for a while .. I'll install it one of theese days and find out.

going to close this out since we're using PNGs in the chrome now.