Closed
Bug 1054916
Opened 10 years ago
Closed 10 years ago
Losslessly optimise Fennec's PNGs with `trimage`.
Categories
(Firefox for Android Graveyard :: Theme and Visual Design, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Firefox 34
People
(Reporter: ckitching, Assigned: ckitching)
Details
Attachments
(1 file)
496.35 KB,
patch
|
lucasr
:
review+
|
Details | Diff | Splinter Review |
Meet `trimage`, a script that uses advpng, opt-png, pngcrush, pngrecolor, and pngstrip to make images smaller, losslessly. Running it on Fennec's images shaves off a few kilobytes (for free!). Seems like a good idea...
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #8474430 -
Flags: review?(lucasr.at.mozilla)
Comment 2•10 years ago
|
||
Comment on attachment 8474430 [details] [diff] [review] Apply trimage to Fennec pngs Review of attachment 8474430 [details] [diff] [review]: ----------------------------------------------------------------- I assume you're confident this is actually a lossless optimization. Last time rnewman tried pngquant (which is lossy, yeah) on all our images, it resulted in color banding issues. Mind sharing this script somewhere? Sounds like something we should be running on all new images being added to the repo.
Attachment #8474430 -
Flags: review?(lucasr.at.mozilla) → review+
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Lucas Rocha (:lucasr) from comment #2) > Comment on attachment 8474430 [details] [diff] [review] > Apply trimage to Fennec pngs > > Review of attachment 8474430 [details] [diff] [review]: > ----------------------------------------------------------------- > > I assume you're confident this is actually a lossless optimization. Last > time rnewman tried pngquant (which is lossy, yeah) on all our images, it > resulted in color banding issues. > > Mind sharing this script somewhere? Sounds like something we should be > running on all new images being added to the repo. Ah, you give me too much credit: http://trimage.org/ I didn't do anything actually *clever* here, I just did `for i in $(find mobile/android/base/resources -name \*.png); do trimage -f $i; done;`. Well, actually, I did the following which is equivalent to the above, just with greater parallelism: for i in $(find mobile/android/base/resources -name \*.png) do trimage -f $i& while [[ $(jobs -p | wc -l) -ge 32 ]] ; do sleep 0.33; done done echo "Waiting for remaining jobs..." wait So. Yes. This should be lossless, for it claims to be so. Do you have a bug number for Richard's adventures with pngquant? I suspect the problem he may have run into is the dodgy support for indexed PNGs with alpha channels (for which neat workarounds do exist). Lastly, has the use of theoretically lossy algorithms such as the one provided by the https://tinypng.com/ service been considered? Running Fennec's PNGs through tinypng resulted in a 32% reduction in size and no visible change in the images (at least, none that I could spot with side-by-side comparison of several of the images). I can provide examples of the results of this for your consideration, if you like.
Assignee | ||
Comment 4•10 years ago
|
||
https://hg.mozilla.org/integration/fx-team/rev/5dff3b17d59a
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/5dff3b17d59a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 34
Updated•3 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•