Closed Bug 8415 Opened 25 years ago Closed 17 years ago

Chrome should use PNG instead of GIF for still images

Categories

(Core Graveyard :: Skinability, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED WONTFIX
Future

People

(Reporter: roland.mainz, Assigned: glennrp+bmo)

References

()

Details

(Keywords: helpwanted)

Attachments

(14 files)

237.58 KB, application/octet-stream
Details
7.02 KB, application/octet-stream
Details
33.53 KB, image/jpeg
Details
241.97 KB, application/octet-stream
Details
218.26 KB, application/octet-stream
Details
1019 bytes, text/plain
Details
289.66 KB, application/octet-stream
Details
9.64 KB, video/x-mng
Details
3.08 KB, video/x-mng
Details
43.71 KB, video/x-mng
Details
3.89 KB, video/x-mng
Details
15.31 KB, video/x-mng
Details
200.00 KB, application/octet-stream
Details
180.36 KB, application/octet-stream
Details
Long ago there was a PNG hype and the good (PNG, free) vs. bad (GIF, owned by
Unisys) war...

Two simple questions:
- Why producing a project under GLP which still uses GIF for it's chrome ?
- Why not moving from GIF to PNG ?

Pro PNG:
- Less space on disk
- No GIF license fee
- 24-bit colors for chrome

Contra PNG:
- Requires to start a converter which converts GIF -> PNG for each image =:-)
- Struggle with some (possible) bugs in the PNG decoder part
Status: NEW → ASSIGNED
Target Milestone: M15
Let's get the browser robust first.
priorities
-pn
Assignee: don → pnunn
Status: ASSIGNED → NEW
Component: Apprunner → ImageLib
QA Contact: leger → elig
Updating QA Contact
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → LATER
Status: RESOLVED → REOPENED
reopening and moving to dawn, since she's actually tested
this.
-pn
Assignee: pnunn → endico
Status: REOPENED → NEW
Dawn.
You've tested them.
You have my vote.....but first you should check with
who ever owns the resource files. They aren't in my domain.
-P
Status: NEW → ASSIGNED
i've tested my png chrome files on linux. need testers for mac and windows.
See my postings in mozilla.xpfe today and yesterday. Images and updated
xul/css files are at http://people.netscape.com/endico/sandbox/  spitzer
will be checking them in tonight.
Resolution: LATER → ---
cool.
-p
Depends on: 6323
Target Milestone: M15 → M9
adding dependency on bug 6323. jpeg and png images don't display on freebsd.
changing milestone to match 6323
how we comin' on this.  at this point if its not ready
we should most likely try and get in during early M10.
I think it is a mistake to push this through. Let's keep
the gif chrome and migrate to png when some build issues
are resolved.  Why couldn't this is set to LATER? Let's
focus on some of the problem that affect functionality....
-pn
s/problem/problems/
-pn
Target Milestone: M9 → M10
I agree with Pam. PNG is wobbly enough on other platforms that this change could
possibly completely break them. Plus, alpha channels on unix is a long way off.
Moving this to m10 for now to remind me to set up png chrome for people to play
with  by hand, but not it make the default. After that's done, I'll later the
bug.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → LATER
Thanks to Steve Morrison from Mozillazine for creating a png theme and adding it
to the Chrome Zone.Lets use this theme instead of moving the entire browser to
png until we're sure png works on all platforms. We don't want the entire gui
rendering as single dots. =)  Marking this as LATER.

http://www.mozillazine.org/chrome/gallery.html
;-((

What about the idea that Mozilla's nightly builds are shipped with multiple
chromes ?
What about a text-only chrome ?
Is it still? I didn't think it worked. I just looked at my aug23 build and
I don't see the chrome switch menu item there any more. I vaguely remember
that the older chrome zone themes were checked in. If so, then maybe steve
could get the new png one checked in too and contact verah@netscape.com to
get instructions on using it into the release notes?
Status: RESOLVED → VERIFIED
Steve Morrison rocks! Verifying later.
Reopening, seeing as now is later ;-)

Seriously, I had a look through the open PNG bugs and it seems we are in pretty 
good shape. Is there anything to prevent us switching to an all-PNG chrome at 
the moment?

Gerv
Status: VERIFIED → REOPENED
Resolution: LATER → ---
Target Milestone: M10 → M20
The only problem I can think of is the lack of mng support, bug 18574 , would
mean the throbber would have to remain an animated gif.
The PNG theme on MozillaZine is so old it's worthless, so last night I started
working on an all png replacement based on the latest nightly (2000052908). So
far I've found two bugs that block going to an all png chrome.

bug 18574 ,which I mentioned last night. There are 3 animated gifs in
chrome/skins/modern/global/skin. loading.gif animthrob.gif and progressmeter-
busy.gif

bug 19283 Windows tranparancy. There are a lot of gifs with transparent
backgrounds in chrome. As an example in Navigator the back, forward, reload, and
stop symbols show up as White boxes with the symbol inside.

I have no permission bits :-( . Could someone please set dependancy on these bugs.

When I finish converting all the chrome I'll submit it to MozillaZine's New
Chromezone.
I think the correct thing to do now with this is to png based skin get
people to try it out, and if it works well on all platforms then eventually
get it in as the default skin.

I would give up on the notion of using animated PNGs though since no one
has expressed any interested in implementing it. Reassigning this to 
Dobbins since he expressed an interest in making a PNG skin.
Assignee: endico → dobbinsj
Status: REOPENED → NEW
Depends on: 19283
taking myself off the cc: list.
I'm interested, but I'm drowning in email.
-P
Accepting
Status: NEW → ASSIGNED
See bug 6963 (WFM) and bug 38638 (LATER).
I have changed all non-animated gifs in the chrome directory to pngs. This
includes the modern skin, the skin for Chatzilla, and the Mozilla logo for the :
about page. After a week of testing on Win 98 and Red Hat Linux 6.2, I submitted
the changes to The New ChromeZone on 6/11/2000. As of now it hasn't been posted,
so I will attach it to this bug. It is based on the latest nightlys in the M16
Branch.
Win 98 test- no noticible loss in performance. Looks like hell due to bug 19283
Linux test- can't tell any differance between png and gif based skin.
Mac test- I don't have one :-( Need some help here.
Attached file PNG Based Modern Skin
Looks pretty good on WinNT 4 sp6a.  Well, let me rephrase that.  It looks as
good as can be expected without transparency.
I'm most regretful of all the spam I must be sending - this is the first time
I've used bugzilla. Anyway, the first new attachment is a .tar.gz that I
extract over nightly build tarballs. It contains a bunch of 24-bit alpha
channel .png files which replace the backgrounds on the four browser toolbar
buttons and the few in Mozilla Mail and Composer. Chief advantages over the
raw .gif images are that there's no dithering artifacts, and that the
"button disabled" images is actually 50% opaque, rather than stripy.

I've also attached a small (~35 KB) .jpg screenshot of the very browser
window I'm typing this comment in. :)
BTW: Does Mozilla 5 ship with a B/W-skin per default (one-bit deep !!) or should
I file a RFE for this ?
On MacOS9 using MN16 final the package looks as good as can be expected and I
haven't found any problems.
I do not understand the reason behind this bug.  I do not currently have any 
desire to see these files changed from GIF files to PNG.  I would like to be 
convinced that there is a serious advantage to this before allowing such a change 
to the Modern Skin.
I'm really concerned about checking in PNG at this point - we all want to ship 
this baby, and switching to PNG sounds like a good way to introduce all kinds of 
new bugs and problems with the PNG decoder, etc.  

It also sounds like we are not just creating the same chrome in PNG vs gif, but 
we are creating a new chrome with a different set of buttons and behaviors. 
Won't this create havok for the gang working on skins because then they would 
have to support and be able to skin multiple UIs?

The timing and risks are bad, and the benefit doesn't seem strong enough at this 
point in the project.  Can we branch and/or do this later, *after* we complete 
the gif based UI and get switching skins to work?
I am unaware of the current state of PNG support in Mozilla. Everything image 
I've loaded has looked fine, but admittedly I've mostly been dealing with 
screenshots and not transparent images. Most chrome graphics use 1-bit 
transparency for icons, or no transparency for things like background images. 
Before checking in a complete patch, one would have to be certain that 

a) it was supported on all platforms (that's right, *ALL* of them, we have to 
maintain the LCD & portability)
b) there was no significant performance degradation on real world hardware.
c) there was *extensive* testing (probably the easiest way to go about 
something like this would be to apply incrementally, test, wait for people to 
squeal, then proceed with caution...)

That said, I have no problem seeing a PNG version of Modern if someone wants to 
go to the effort of creating the graphics and checking it all in. 
> PNG sounds like a good way to introduce all kinds of
> new bugs and problems with the PNG decoder, etc.

No product should ship with a broken PNG decoder.  PNG has been around for years
now, there are no excuses.  If this leads to bugs, it can only be a good thing.

Reasons why this should be done that come to mind:

(a) free software, free format
(b) PNGs are smaller and probably therefore faster due to the CPU/hard disk
access time disparity (don't quote me on that)
(c) the presence of PNG will make people realise that PNG works and therefore
start to use alpha and gamma in their skins
Well, no arguments any more - matty@box.net.au wrote them all.

OK, simple salomonian judgement:
Make the PNG skin the default _NOW_ and keep it until a few weeks after M17
release. If there are too much problems after M17 release: Switch back to GIF
(and send Unisys $1 per downloaded Mozilla archive =:-)
Hey John, unfortunately i took most of the png's out of Aphrodite because of
previous platform specific problems.

However, if you run the current version on Windows, the grippies transparent
background which are still png's are black. So i would say there is 
still a problem. I think they are fine on the mac.

The png images were created with Gimp.

pete

Adding dependancy on bug 18574 per John Dobbins' request on May 30th (oops).

It seems MNG support is in, and bug 19283 (the problem Pete mentions) is being 
worked on.
Depends on: mng
A few points,
1) I do not intend to even try this untill after NS Beta 2 forks. It is too 
close to risk any new bugs.
2) There is no way this can be fully implimented untill after all Windows 
transparancy problems are solved. This means bug 19283 for binary transparancy, 
and bug 36694 for alpha transparancy.
3) Even if there were no blocking bugs, There are a lot of changes to be 
checked in. It's not going to happen all at once.
Someone should probably add bug 36694 as a blocker of this then, right?
I understand the general concerns you mention with the GIF format, I don't like 
it myself because of the surrounding aura of "proprietaryness". However 
the 'modern' skin was entirely created in-house with properly licensed tools, 
and according to the legal powers in the company here there are no problems to 
be expected with this approach.

While I fully understand the benefits of PNG, for this low color iteration of 
the modern skin I don't think its worth the effort changing all image and CSS 
files, but other skins will likely use PNG for higher color rendering. For 8-
bit palette images with transparency compression ratios and performance are 
about on par between GIFs and PNGs, that is what we are using for the modern 
skin to play within the web safe palette. In addition since you started the 
effort, quite a few of the icons and other images have already been changed and 
updated, so I do not feel its worth the effort changing things again. Also the 
rendering of the GIF format in the part has been more stable across all 
platforms we support (not just Mac,Win32, Linux but also other Unixes), thus it 
makes a good format a base skin. Finally animations can only be produced in GIF 
right now (that is until we have MNG working across all platforms) 
Adding dependancy on bug 36694.

German, if I've read you correctly, once PNG and MNG work on all platforms, a 
goal I hope Mozilla is trying to achieve before Mozilla 1.0, the only relevant 
difference between GIF and PNG would be that PNG has a better aura than GIF?

Then, assuming someone's willing to spend the time and effort into editing the 
.css files and creating PNGs which look good even in the web safe palette, and 
willing to make sure it keeps working, then what's to stop Mozilla from adopting 
that, then, as the new default skin? The incentive being that PNG has a better 
aura than GIF.

John Dobbins, in the mean time, would you be willing to create a 
Work-In-Progress ModernPNG theme and make that available for download (.tgz) or 
install (.xpi) somewhere? That way people can test it and give feedback on 
stability / usability.
Depends on: 36694
Other than bugs there is nothing fundamentally wrong with using PNG instead of 
GIF but for the in-house developed modern skin the risk to advantage ratio does 
not work to our benefit given the tight timeframe before releasing NSs beta 2. 
There will no visible end user benefit to putting PNGs onto the modern skin given 
the constraints for the modern skin (8-bit web safe etc) as outlined above.
 
Mmmhmmm, that's understandable. I didn't really expect this to be put in for 
nsbeta2, way too much other stuff needs doing.

So what about somewhere after nsbeta2, but before the release of Mozilla 1.0? 
Would the Target Milestone need updating?
Please submit this skin to mozillaZine's chrome zone so people can try it
out and help find any more bugs remaining in the png implementation. 
http://mozillazine.org/chromezone/ It will get wider distribution there
than it would if it were just left as an attachment to this bug.
Dawn I submitted it but Chris decided not to include it as a regular skin due to 
the Win transparancy problems. There is a news story about it though, 
currentally the top story. It has a link to download the file.
One look at http://home.netscape.com will show that the Modern skin is in fact a 
Netscape skin. One look at Netscape 4.X will show that the Classic skin is also 
a Netscape skin. Since Netscape owns these skins it is entirely up to them what 
to do with thier skins. From what I've seen any work done on the Classic or the 
Modern skin is in effect working on a bug that has been resolved "Won't Fix".
I haven't given up on PNG based chrome though. Skin switching has been 
implemented. Right now the only choices are the Netscape skins. I think I'll 
follow johng's advice and branch. It's time Mozilla had it's own skin in 
addition to Netscape's skins. If Netcenter dosen't like the Mozilla skin then it 
can be left out of the Netscape builds.
I'm open to feedback. Should the focus of this bug be changed to developing a 
Mozilla skin? 
This bug is turning into a major project. UI engineering owns the skins 
currentally in Mozilla, and they are unwilling to make changes. The only way a 
PNG skin will be implemented is as a third skin. I am going to try to get 
approval for Mozilla to have it's own skin. As a first step I started a thread 
on N.P.M.UI. Comments are welcome. I have no idea how long this will take, so 
I'm setting the Milestone to future. This change does NOT mean I have stoped 
work on this bug. It mearly reflects that I am uncertain when this will be 
implemented.
Target Milestone: M20 → Future
You guys should note that 8-bit alpha in PNGs is now working on Windows, except 
for Win98 which will be fixed shortly.
As far as I can tell, all *relevant* aspects of 18574 (MNG tracking bug) that
matter to chrome are fixed.  Things that still don't work are JNG support (at
least on a Win32 2000072008 build) and color correction, but neither matters for
chrome--at least not any more than their current lack in GIF-based chrome
matters.

So I recommend that bug 18574 be removed from the blocking list for this bug. 
(See my comment there for further details.)

Greg
Attached file New PNG Skin
Attachment is a xpi. 
Skin tested on Win 98 and Redhat 6.2 with M18 branch nightlys.
MNG is not working on Win98 in chrome, so the 3 animated files are still GIFs. 
The MNGs are included in the skin. ( throbber.mng, loading.mng, and 
progressmeter.mng) all are in the global/skins directory.
All links to loading.gif/mng have been moved to point to the global/skin 
directory. I didn't test mng support on linux.
Still need tests on M17 branch for all platforms and Mac on M18 at the least.
MNGs not working in chrome is most likely due to bug 41333.

using PNG for the alert icons horks up the alert dialogs. The icon and any text 
are not displayed. For now I have returned these 4 Icons back to GIFs. To cut 
down on spam I have posted the updated version at http://x.themes.org, and will 
make minor updates avaible there. URL for updates added. Only major updates will 
be added here.
I vote for checkin this Neomodern into the tree.
Please ignore my last comment.
Had a look at the new Modern skin, and it's PNG!

And Thank you Netscape for letting me waste my time working on a feature you
were planning on implementing. It was real fun rereading the June 19th comments
from hangas and johng. Were you working on this then?

Reassigning to nobody. Anybody that wants to pick it up and mark it fixed after
Modern 2 finishes landing is welcome to it. I've put enough time in on this, and
won't even spend the time to mark it fixed.
Assignee: dobbinsj → nobody
Status: ASSIGNED → NEW
Do you expect Netscape to plan 2 full months in the future? ;)

Be happy that they use PNG! You might have helped with that.
>Do you expect Netscape to plan 2 full months in the future? ;)

From N.P.M.UI thread "Should Mozilla have it's own skin"
Paul Hangas replied
>This is excellent!  I really want to see mozilla skins start coming to life.  
>The timing on this is perfect.  We are just now doing skin design work for 
>another Netscape 6 skin as well.
>
>paul

I found that after posting my last comment. Since I haven't seen any evidence of 
any other Netscape skins, I have to assume Modern2 is the skin mentioned on June 
22.
If anyone at Netscape had bothered to inform me they were getting ready to 
implement a PNG based skin I would have reassigned this bug to them. Instead 
time I could have spent on other areas was wasted. At best my work was a 
testcase. I could have thrown a test case togather in an afternoon instead of 
trying to create a well crafted skin.
Attached file NeoClassic xpi
So now it looks like Modern will stay GIF leaving Mozilla with no PNG based 
skin. Many of the problems Netscape had trying to implement a PNG based skin 
could have been avoided if Mozilla allready had a PNG based theme. Third party 
skin developers who wish to use PNG are also having problems.

The latest version of Neoclassic is attached. It is based on the classic theme 
and is in sync with it as of 20:00 PT last night. If this is checked in, the PNG 
bugs will be a lot easier to find, and there will be an easy way to reproduce 
them.

Also PNG Transparancy is horked in Windows. bug 52088 has been filed.
Per the mozilla.ui thread, has anyone verified that, indeed, CSS colors are
*not* being gamma corrected?  (Simplest way to test:  create a PNG with some
mid-range colors, mark it sRGB--I think pngcrush will do that--and compare with
an HTML page with CSS colors on different platforms.)  If so, is there a bug
filed yet?  Sorry, I've been swamped with other things.

(The upshot is that, per the CSS spec, CSS colors should be gamma-corrected. 
And regardless of whether there's a preference for the user's display gamma,
the algorithm for doing the gamma correction must match what's used in the PNG
code.)

Btw, is Eli really the QA contact still?
Depends on: 53606
Depends on: 53597
Here's a test page (hope I did this right). I don't have a non-sRGB display to 
test it on, though. If Mozilla on Mac fails, a bug should be opened.
http://home.mieweb.com/jason/testbed/srgb/
triaging...

As mentioned earlier, one of the blocker bugs for fixing this bug is that we
hardcode the alert icons to be GIF. Is there a bug covering this exact issue?
Assignee: nobody → ben
Component: ImageLib → Skinability
QA Contact: elig → blakeross
Depends on: 59091
Pretriage of skinnability bugs, marking nsbeta1-, not going to get to this for 
beta1
Keywords: nsbeta1-
Jason, Hixie: Mozilla Win32 currently fails the test on the page Jason gave. We 
need to open a bug about that. I would, but I'd have no idea what to say.

Also, re: PNG/MNG in skins. AIUI, Modern2 is a PNG skin, but presumably uses 
animated GIFs for e.g. the throbber, because MNG in skins doesn't work. Is that 
right?

Gerv
CCing hewitt.

Hewitt: is there any chance the new modern could make this switch? At least to 
PNG, if not to MNG (as no-one seems to know if it works in chrome or not.)

Gerv
QA Contact: blakeross → pmac
Mass move skinability bugs to nobody@mozilla.org, helpwanted. 
Assignee: ben → nobody
Keywords: helpwanted
*** Bug 38638 has been marked as a duplicate of this bug. ***
Depends on: 121230
Depends on: 107225
Can we go ahead with this all the way now?  Is there anything else that could
cause an issue?  This should be a direct conversion-- no new features will be
used initially, which means alpha, gamma, etc. should have no bearing.
Blocks: 162764
I made a bash script to convert skins from GIF to PNG and MNG.
Unzip, cd to the skin directory, run the script, zip the results.
Calls lots of utilities:
convert (from ImageMagick)
gif2png
pngrewrite
pngcrush
replace (mysql utility?)
No longer depends on: 107225
This bug has been broken by a patch that pavlov@pavlov.com checked in several
hours ago.
Status: NEW → ASSIGNED
taking assignment.
Assignee: nobody → randeg
Status: ASSIGNED → NEW
Blocks: majorbugs
Glenn: Do you plan on doing the PNG part of this (convert all still GIF
images to PNG format) before or after MNG comes back?
Summary: Chrome should use PNG instead of GIF... → Chrome should use PNG (and MNG) instead of GIF
Yes, one of those.  Note that the motivation for switching *everything* from
GIF disappears with the lapse of the LZW patent in the US in a few days.
So I will be concentrating on those where there are technical reasons for
switching such as ones that are transparent and should be antialiased (e.g.
the Firebird throbber), and ones that compress better as PNG than as GIF.
> Note that the motivation for switching *everything* from
> GIF disappears with the lapse of the LZW patent in the US in a few days.

<cough> Er, the patent is still valid in the UK and other countries for at least
another year. And, even after it's expired, a lot of hackers' copies of the Gimp
won't have GIF support. We should switch to PNG throughout to avoid patent
problems in any country, for consistency, for ease of modification, and because
of the message it sends.

Gerv
I believe Moz only reads GIFs, and the theory all along has been that reading
isn't covered by the patent.  So as long as all GIFs were created in the US
after 20 June 2003 we should be OK.  I can as a part of this project recompress
them all so they get a timestamp after 20 June and a comment "Made in the USA"
or something to that effect.

Things are going to be rather complicated for freeware that makes GIFs during
the next year.  Unisys has said that they plan to enforce the patent wherever
it still is valid.

I agree with gerv about sending the right message, but why start now?  If we
really do want to start sending a better message, I'll be pleased to do the
all-GIF-to-PNG conversion.

Note that some of the work has been done already in the attachments to this
bug and to bug #38638
> So as long as all GIFs were created in the US after 20 June 2003 we should be 
> OK.

So only US citizens can contribute skin updates for the next year? Not very
"free software" :-| IMO, we should continue with the "all PNG/MNG" plan - when
we work out what's happening with MNG.

Gerv
Not "US citizens" but anyone who has shell access to a computer in the US.
Or who write uncompressed GIFS and could ask someone here to recompress
their files, or they could use commmercial licensed software.  The last is
the only alternative for anyone right now; I hope all the GIFs in the tree
were compressed with licensed software.  I don't think there are any uncompressed
ones there.
Note, another motivation is the other feature that PNG brings with it: alpha
blending.  GIF files are restricted to only level of transparency.  While that's
not an issue for the current skin; it could become one for future revisions. 
Besides, with drop-in replacement PNGs, new skins could be a little quicker to
produce at least when mod'ing the default and standard skins, and
hopefully/possibly with some nice effects.  Imagine buttons with alpha blended
borders/highlights to give a soft dome feel over a textured background.  You can
have pseudo gloss with alpha blended masks and you don't have to worry about
placement over a particular backround if you wanted to use an image as the
shading/beveling could be an overlay.

Technically, there might not be much to gain.  Politically and from a legal
perspective, there's a lot of unnecessary baggage that can be shed by persuing this.
"and ones that compress better as PNG than as GIF."

This should be most of them. PNG's deflation has better average performance
than GIF's LZW, and deflation with Paeth filtering is much more powerful
than LZW without filtering.

This bug seems to cover conversion of the Classic and Modern theme
content from still GIF to PNG.  Shouldn't it be in component "themes"?
Or are there significant underlying theme engine bugs (other than
bug 18574 to put MNG back in) that preclude the switch?

(Removing dupe from depends.)
No longer depends on: 53606
Many of the GIF images in the tree are only a couple hundred bytes, where
PNG's 53-byte chunk header overhead overwhelms the better compression.
Throbbers, on the other hand, are larger files that compress much better
as MNG than as GIF.

A few days ago I put some comparisons of MNG versus GIF images of the
Classic/Modern throbber and the Firebird Throbber as attachments to
Bug #195280 (shortly I'll move the new throbber images over here). 
The latter is a nice example of how much better MNG looks; the GIF has
ugly white haloes when displayed against a dark background.
This throbber appears twice in the tree, under "modern" and "classic",
in 32x32 and 16x16 sizes both places.

Total size of GIFs: 65684 bytes.
Total size of MNGs: 26032 bytes.
Firebird throbber, GIF: 8643 bytes
Firebird throbber, MNG: 3985 bytes
QUOTE:
>Contra PNG:
>- Requires to start a converter which converts GIF -> PNG for each image =:-)

I'll convert all your GIF files to PNG/MNG in the chrome if you implement it.
I have a batch converter that converts GIF to PNG. I bet there is something
similar for MNG too. I will attach it so anyone who is interested can have a look.
Attachment #129983 - Attachment description: Conversion and optimization tools GIF -> PNG (1) → Conversion and optimization tools GIF -> PNG (RAR Archive, Part 1)
Vedran:
I believe the conversion could be quite easily done with ImageMagick, I doubt
another tool would be needed...
Perhaps now that MNG's gone, we should break off the MNG side of this into
a separate bug so that it no longer depends on 18574, which is unlikely to
get fixed soon.
That's OK with me, although a "chrome should use MNG" bug would probably get
immediately marked "invalid".  Go ahead and give it a try.  Since the "(and
MNG)" part of the summary of this bug is invalid now I'm removing it.
Summary: Chrome should use PNG (and MNG) instead of GIF → Chrome should use PNG instead of GIF
Which means we can remove the dependency on bug 18574 (restore MNG support).
No longer depends on: mng
We should probably add an additional bug for conversion of animated gifs to MNG,
which then should be dependent on our beloved MNG resurrection bug.
Man I'd hope to see progress there...
Is this now dependent on bug 257197 (APNG)?
It depends on having some sort of PNG-based animation capability.  So it depends
on either 251197 or 18574 but not both.  Marking dependency on APNG for now.
Depends on: apng
Other than the animated one, shouldn't the rest be PNG by now?  
Would it be best to morph this bug into a bug for still images and branch
throbber discussion to a separate bug?
No longer blocks: majorbugs
So, what's the status on this bug? Is it separate for toolkit and for XPFE? Is there some backend code involved? etc.
Eyal, it's a theme issue and actually separate for every theme. Of course, this makes it a separate matter for toolkit and xpfe as well, but what toolkit is used actually doesn't matter here. Not having any animated non-GIF format makes us all stuck with GIF throbbers though, for now.
Re Comment #100, changing the summary from
"Chrome should use PNG instead of GIF"
to "Chrome should use PNG instead of GIF for still images".
This might let us get to work on it instead of debating the issue.
Summary: Chrome should use PNG instead of GIF → Chrome should use PNG instead of GIF for still images
This is probably WONTFIX.  The patents have expired, and there are cases where GIFs are smaller.  I believe we used GIFs for SeaMonkey's autoscroll icons specifically because it was smaller than PNG in that case.
There are indeed cases where GIFs are smaller, but there is an opportunity to save some space by converting those where the PNGs are smaller.  I find 1322 GIFs on the trunk, in a Seamonkey checkout.  Of those about 38 are animated so forget them for now.  Of the rest, 1099 are smaller as GIF (each about 4 bytes smaller on average) and 185 are smaller as PNG (each about 800 bytes smaller on average).  A savings of 162 kbytes could be realized by converting the 185 that are smaller as PNG.
Ok, have an up-to-date patch against trunk?
I actually think changing the theme images right now is probably a waste of time. The new images we're using with bug 348720 are PNGs anyways (created from SVGs) and I don't think it makes much sense to convert the current old images when new ones are being created anyways.
(In reply to comment #106)
> Ok, have an up-to-date patch against trunk?
> 

Nope.  Converting the images themselves isn't too big of a deal, but finding
all the references to them and fixing those, and finding the symbolic links
and fixing any references to those is hard to automate.  Also there are several
*.gif files that aren't really GIFs.  Would you be interested in a patch that
only replaces a few files, those that show the most savings when converted?
Does the image loader go on extension or on magic characters? If the latter, who says we need to rename the files? ;-) OK, it's a hack, but 165k of savings is not to be sneezed at. (Although I'd be interested in seeing figures of what that translates to in download size, after the overall compression is applied.)

Gerv
On a related note, the image files in chrome that are already PNGs could be made much smaller.  Most of them have unnnecessary chunks, such as tEXT, pHYs, iCCP, gAMA, and cHRM (latter three could be removed by converting to sRGB and saving as an untagged file).
Removing unneeded chunks and compressing IDAT (pngcrush -rem alla) shrinks the current PNGs in toolkit and browser by 108K total uncompressed, 64K compressed.

Gerv: I think the image loader would do the right thing with a *.gif
that actually contains a png, but I'm not sure that would happen under
all usages.  Also, neither PNG nor GIF files are very compressible, so
the effect on download size is probably the same as the raw filesize
differences.

Here are the 10 most-improveable files.  The figure at the left is
the size reduction after converting to PNG and pngcrushing.  Improvement
would be 13 bytes less per file if an sRGB chunk were added.  I used
GraphicsMagick's "convert" to do the conversion.  Better compression
is achievable sometimes, by rearranging the palette.

4453 mozilla/layout/html/tests/block/images/tech-banner2.gif
4456 mozilla/themes/modern/editor/icons/btn2.gif
4967 mozilla/content/xml/tests/books/kerouac.gif
5141 mozilla/layout/html/tests/table/images/rock_gra.gif
5346 mozilla/layout/html/tests/block/images/tech-banner1.gif
7171 mozilla/themes/modern/navigator/icons/btn1.gif
8369 mozilla/layout/doc/SpaceManagerClasses.gif
14502 mozilla/themes/modern/messenger/icons/btn1.gif
16225 mozilla/themes/modern/editor/icons/btn1.gif
18502 mozilla/layout/html/tests/block/images/animated_gif.gif
(In reply to comment #109)
> Does the image loader go on extension or on magic characters? If the latter,
> who says we need to rename the files? ;-) OK, it's a hack, but 165k of savings
> is not to be sneezed at.

I would not like to see a bunch of *.gif that were really png, but how about this:
add file.png, and replace file.gif with a symbolic link to the new png?  It's still a hack, and wastes 8 bytes per file, but it's a little more evident to future gurus what's happened.  When they type "ls -l btn1.*" they see
  lrwxr-xr-x  1 glennrp  visitor     8 Jan 17 11:55 btn1.gif -> btn1.png
  -rw-r--r--  1 glennrp  visitor  9538 Jan 17 10:57 btn1.png
Not all platforms support symbolic links like that.
I think all of Glen's top 10 are not actually shipped in Firefox.

Glen: are you able to install Firefox, unzip the JARs in the chrome directory, do a "find -name "*.gif"" and see what you can do with those files?

Gerv
Gerv:  I did a checkout of Firefox from CVS and found no JARs in the
chrome directory.  However, there are 577 plain GIF files in various directories.  Of those, 551 are good single-image files.  132 of those are smaller as PNG.  Here are the top 21 (all files that exhibit 1000 bytes or more savings when converted to PNG):

1005 ../mozilla/layout/html/tests/table/images/tbl-border-conflict.gif
1126 ../mozilla/xpfe/global/resources/content/logo.gif
1135 ../mozilla/layout/html/tests/table/images/bnr_all.gif
1213 ../mozilla/layout/html/tests/table/images/l_logo.gif
1220 ../mozilla/layout/html/tests/table/images/cnn.gif
1243 ../mozilla/layout/html/tests/block/images/vert_pixel_ruler.gif
1244 ../mozilla/layout/html/tests/table/images/next.gif
1249 ../mozilla/parser/htmlparser/tests/html/bg2.gif
1284 ../mozilla/layout/html/tests/block/images/mozilla-banner.gif
1284 ../mozilla/layout/html/tests/table/images/mozilla-banner.gif
1329 ../mozilla/layout/reftests/bugs/mozilla-banner.gif
1511 ../mozilla/layout/html/tests/table/images/smblue_paper.gif
1555 ../mozilla/layout/html/tests/table/images/edge.gif
2327 ../mozilla/layout/html/tests/attributes/mapimg87.gif
2562 ../mozilla/layout/html/tests/table/images/rclogo460.gif
3494 ../mozilla/layout/html/tests/mynet.gif
4419 ../mozilla/layout/html/tests/block/images/tech-banner2.gif
4429 ../mozilla/extensions/irc/xul/skin/images/blue_rock.gif
5107 ../mozilla/layout/html/tests/table/images/rock_gra.gif
5312 ../mozilla/layout/html/tests/block/images/tech-banner1.gif
8455 ../mozilla/layout/doc/SpaceManagerClasses.gif
Glenn -

What Gerv was saying is that even though they may be in CVS, they are not necessarily packaged and shipped.  If you have a Mozilla product installed, go to the application directory and look for .jar files in the chrome folder.  For example, you would want classic.jar from Firefox.

The files that you listed are often in the "tests" folder.  I don't believe that is shipped by default.

-Alan
I have a particular 3rd party build of Firefox 2.0 for Windows.  It has a "classic.jar" that contains 42 GIF files.  None of those are smaller when converted to PNG.
OK. So it looks like there's not much gain to be had here in terms of improving the download size of Firefox. You could try with Thunderbird, Seamonkey etc. as well if you liked, but I suspect you'd get the same results.

Close as WONTFIX?

Gerv
Seems to me PNG is on the whole more space efficient and it's better to just switch everything to it and have a uniform format rather than fiddle with which files compress better with GIF. Also, PNG allows 24-bit color which GIF doesn't. 

So I for one still think switching everything to PNG is a Good Thing.
But we're not talking about theoretical files, we are talking about the files we have. They don't need 24-bit colour, and PNG is not smaller. Or, to put it another way, *GIF* is smaller. So you are advocating switching from one format to another, the only effect of which would be to give someone some work to do, and increase the download size. I don't see that as a win.

There are no longer patent problems with GIF. If anyone can demonstrate a download size reduction for any Mozilla project application via converting from GIF to PNG (or vice versa, for that matter), please open a new, specific bug listing the files you want to convert and the size decrease expected.

Gerv
Status: NEW → RESOLVED
Closed: 25 years ago17 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: