Closed Bug 45008 Opened 24 years ago Closed 16 years ago

Optimize Color Depth of GIFs in Chrome

Categories

(SeaMonkey :: Themes, enhancement, P3)

Product:
SeaMonkey
Component:
Themes
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: dobbinsj, Assigned: neil)

References

Details

(Keywords: memory-footprint, perf)

Attachments

(13 files, 6 obsolete files)

Optimized GIFs
126.78 KB, application/octet-stream
Details
Handoptimized versions of all the searchplugin icons - Zipped
1.43 KB, application/octet-stream
Details
A few stray pixels found their way to the first handoptimized version the searchplugin icons .. here is a slightly better (and smaller) version
1.41 KB, application/octet-stream
Details
Optimized gifs from the res directory
146.04 KB, application/octet-stream
Details
Optimized RC1 Classic Chrome
255.02 KB, application/octet-stream
Details
Optimized RC1 Modern Chrome
509.46 KB, application/octet-stream
Details
Optimized RC1 ChatZilla.Jar
100.86 KB, application/octet-stream
Details
Optimized RC1 comm.Jar
845.99 KB, application/octet-stream
Details
Optimized RC1 en-US.Jar
625.92 KB, application/octet-stream
Details
Optimized RC1 forms.Jar
20.28 KB, application/octet-stream
Details
Optimized RC1 inspector.Jar
182.05 KB, application/octet-stream
Details
Optimized RC1 venkman.Jar
168.04 KB, application/octet-stream
Details
Logfile of optimization containing detailed statistics
110.35 KB, text/plain
Details 
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.
Attached file Optimized GIFs — 

    
    

    
  
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?
Severity: normal → enhancement

    
    

    
  
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
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
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.
Assignee: ben → hangas
Component: Skinability → Themes
QA Contact: blakeross → pmac

    
    

    
  
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.

Assignee: hangas → 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])."


    
  
Depends on: 53606

    
    

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


    
  
Depends on: 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

Status: NEW → ASSIGNED

    
    

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


    
  
Keywords: footprint

    
    

    
  
*** 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

    
  
Blocks: 7251

    
    

    
  
we should try to resolve this within next 2 milestone
Target Milestone: --- → mozilla0.9.8

    
    

    
  
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



    
  
Keywords: mozilla0.9.9

    
    

    
  
moving out -> 1.0
Target Milestone: mozilla0.9.8 → mozilla1.0

    
  
Keywords: mozilla1.0+

    
    

    
  
not a 1.0 showstopper.
Keywords: mozilla1.0+ → mozilla1.0-

    
    

    
  
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)

    
  
Keywords: mozilla1.0.1

    
    

    
  
Comment on attachment 50875 [details]
Optimized version of the Classic chrome

Obsoleting as per comment 61.

        Attachment #50875 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 50876 [details]
Optimized version of the comm.jar package

Obsoleting as per comment 61.

        Attachment #50876 -
        Attachment is obsolete: true

    
  

        Attachment #50877 -
        Attachment is obsolete: true

    
  

        Attachment #50878 -
        Attachment is obsolete: true

    
  

        Attachment #50879 -
        Attachment is obsolete: true

    
  

        Attachment #50880 -
        Attachment is obsolete: true

    
    

    
  
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.

    
  
Keywords: mozilla0.9.9, 
          
            mozilla1.0.1 → nsbeta1, 
          
            perf

    
  
Target Milestone: mozilla1.0 → ---

    
    

    
  
adt: nsbeta1-
Keywords: nsbeta1 → 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.

    
  
Assignee: marlon.bishop → neil.parkwaycc.co.uk
Status: ASSIGNED → NEW

    
    

    
  
going to close this out since we're using PNGs in the chrome now.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Product: Core → SeaMonkey

          You need to log in
          before you can comment on or make changes to this bug.