189803 - smaller images (decreased file size for various composer images)

Status: VERIFIED FIXED

(SeaMonkey :: Composer, enhancement)

Description

[Brant Gurganus]

I have made several images from Composer in CVS losslessly smaller

Comment 1

[Brant Gurganus]

Attachment: smaller images

Comment 2

[Andreas Kunz]

I don't think composer is a real reviewer, it's just a placeholder name and I
guess nobody will take it too personal and do the review...

Do you have some numbers of the old/new file sizes?
Is the size decrease significant?
Have you tested if the transparent background is working where necessary?

-> enhancement, more specific summary

Comment 3

[Brant Gurganus]

The savings are typically about 33 bytes per file.  Image depth, etc. are not
affected.  The size change is due to removal of comments in the files that some
editors add.  Few programs other than those editors display the comments, so
there is no sense in having them.

Comment 4

[Kathleen :Brade]

Comment on attachment 112076 [details]
smaller images

r=brade (assuming the only changes are removal of comments)

Comment 5

[Brant Gurganus]

From Status whiteboard, this apparently needs super review also.  Also, I do not
have CVS commit access to the source tree so once the super review comes, could
somebody check them in.  The ZIP should put the images in the correct places if
you unzip it at the root of the tree.

Comment 6

[jag (Peter Annema)]

-> me

Comment 7

[Brant Gurganus]

jag: Don't check anything in yet.  I received word from another project where I
made smaller images that transparency was affected so I will have to check these.

Comment 8

[Andreas Kunz]

In that directory there are 114 images; 95 of them exist in a modified version
in the attached zip file.
Previously they took up 31,333 bytes (as windows tells me), after replacing the
modified files they have altogether only 21,227 bytes.
This is more than 10,000 bytes of binary data less, which is quite good IMO (I
have to admit I was a bit sceptical when first reading this bug).

But:
Some smiley images were also reduced in pixel size, e.g. smile.gif was 17x17
pixel large, now is 15x15 pixel large.
Only transparent background was removed, but might this change trigger problems
(with alignment or something)?
Unfortunately I don't know where in composer they are used...

Second problem: transparency. This seems to work with the HTML-tag icons (I
loaded www.amazon.com which shows quite a lot of them and they were ok) and also
most of the others, but smile_active.gif smile_disabled.gif and smile_hover.gif
look a bit odd...

Comment 9

[Brant Gurganus]

Andreas: Thanks for that detailed analysis.  I will file a bug with the GIF
optimizer program I was using and see if I can find one that will do this in
batch without messing with transparency.

Comment 10

[Andreas Kunz]

Don't give up so fast!
I found that the three files with dubious transparency already had this problem
(or feature?) in their original version, so your conversion did no bad.
Actually I could verify by dragging all of those icons into a new composer
window with colored background that transparency was not changed in any of the
files.

What *was* changed, is the size (the 15x15 thing...).
(This also has reduced filesize most (about 500 bytes per icon) while removing
comments has only decreased file size by 33 bytes each.)
And for telling if that could be I problem I have to know how/where these
smileys are used in composer. Lxr tells me that they are only referenced in
EditorExtra.css for "the smiley menu" but also mailnews uses some of them for
composing html mails via editorSmileyOverlay.xul.
But that does work well and the reduced pixel size isn't about to make problems
(as opposed to larger pixel size which could push elements somewhere generally).
Worries about future use are also not necessary, because people have to deal
with the size of these icons anyway, no matter what it is.

Compressed comm.jar size is decreased by about 6 kB (0.64%) with the new images
(using WinZip, max. compression).

All in all I personally think taking the new gifs is safe and recommended.

Comment 11

[Brant Gurganus]

Andreas, since you are using the smaller images, those smilies can be accessed
via the HTML compose bar I think.  I have sent a message to the program maker
anyway.  Also, rereading the documentation for the image optimizer, I think it
also removes unused colors from the color pallete.
If you don't end up seeing any issues, you could superreview it and then I could
get 1.3b or later approval and get somebody to check it in.

Comment 12

[Samir Gehani]

Composer triage team: nsbeta1+/adt2

Comment 13

[jag (Peter Annema)]

Comment on attachment 112076 [details]
smaller images

sr=jag.

Comment 14

[Brant Gurganus]

Someone with CVS checkin privs can now check this in since it has its reviews
(after 1.3b lockdown is over of course).  cvs.mozilla.org access for me in
addition to gila.mozilla.org is currently pending.

Comment 15

[Andreas Kunz]

Brant, 1.3 also requires approval.
Only after that one, for 1.4a, there are no further requirements.

Comment 16

[Samir Gehani]

Jag, now the trunk is open for 1.4a development is open can you please check
this in?  Thanks.

Comment 17

[jag (Peter Annema)]

I checked in all images but tag-ol.gif and tag-ul.gif. The transparent box at
the top of those images was used for alignment purposes so the tag ended up
underneath the bullet/number. Insert a bulleted or numbered list in composer and
go into html tag mode and you'll see what I mean.

Also, it looks like the s_*.gif images are unused, could/should they be removed
from the build?

What about the 19 images that didn't get replaced? Was there no gain there?

Marking this bug fixed for now to get it off my radar, please reopen it if you
want to make any of the other images smaller.

Comment 18

[Brant Gurganus]

Verifying checkin according to Tinderbox/Bonsai.

Comment 19

[Pascal Chevrel (relman team) -> :pascalc]

Is there a technical reason for keeping these images interlaced ? We would gain
a few bytes per image without interlacing.

Comment 20

[Brant Gurganus]

Pascal, go for it.  I'm currently setting my system back up clean so I don't
have all my tools handy at the moment.

Comment 21

[Pascal Chevrel (relman team) -> :pascalc]

Attachment: icons without interlacing if a gain

New version of icons with interlacing option off for some images when it
resulted in a size gain

Comment 22

[Pascal Chevrel (relman team) -> :pascalc]

This is a very small gain overall (77 bytes), I deactivated interlacing only
when it resulted in a gain, for many images it had no effect or resulted in a loss.

I noticed that one of the images has a 21 colour palette (tab-ngr) while all
others have 4 to 16 colours and could be optimized.

Most of the images have more than 8 colours (usually 9), if they were set to 8
colours, we might gain a bit of weight because of the use of an 8 colour palette.

I also notice that the border of tag images is using 4 colours alone (black + 2
grays + transparency) and that the text is antialiased. Actually, I think that
anti-aliasing makes it more blur than readable ;-)

IMO 4 colour images for tag images without transparency in the corners, a simple
border and slight antialiasing would be better, we would have more readable text
and smaller gifs. The drawback being that recreating all gifs would be
time-consuming. I created two simpler tag buttons, one with 4 coulours (2
colours for the border, 2 colours for the text) and one with 3 colours (2
colours for borders 1 color for black text without anti-aliasing) and I gain
about 50 bytes per image, that would be probably between 4KB to 6KB in total.

If some people are interested, I can post examples of simplified tag images and
let you judge if this small footprint gain is worth it.

Comment 23

[Suresh]

I think either this bug or bug 83774 caused smiley regression in commercial
tree. Smileys do not display in commercial tree (bugscape 22977).