Hi.
I have faced an issue, that some of image assets (PNG files) was not optimised. So, I have used Image Optim and
saved 493 KB out of 1.8 MB. 29.6% per file on average (up to 91%).
Looks like spinner-* was already optimised, added in screenshots as a reference.
Thanks for saving this planet :)!
Saved 493 KB out of 1.8 MB. 29.6% per file on average (up to 91%)
Usually we use pngcrush on newly added files. C.f. https://github.com/bitcoin/bitcoin/blob/22e301a3d56dc9e6878380ee92c7d19ca43119d2/contrib/devtools/optimize-pngs.py#L48
Interesting that still so much can be saved. Maybe it was overlooked...
optipng at high levels usually does somewhat better than pngcrush in my experience.
I don't really like this. Yes, in the distribution archive the pngs will be somewhat smaller, however the old files will stay in the repository forever, this just adds a (smaller) copy, so for development this makes things slower.
Quick reference: 83.81 MB – full repo size 24.5 MB – v0.15.0rc1 So savings is up to 2% of build size.
Due a security concerns in #3341 (comment) (my machine could be possibly compromised, for example), and @laanwj comment that currently main goal is dev-speed, I believe that best solution would be close this PR, and create issue-ticket for improving bitcoin/contrib/devtools/optimize-pngs.py functionality (29.6% per file is HUGE savings).
By the way, looks like it's not first PR with such proposal: Lossless image optimization #3341.
P.S. I'm sorry guys for your time.
P.S. I'm sorry guys for your time. @popenkomaksim No problem, sorry for being party pooper here.
I agree that there is a large gain in some cases, and for the images that get included into the Qt GUI executable you could certainly make an argument that this should be done at some point (would it make sense to do it as part of the build process? nah, we don't want pngcrush and whatnot as build dependencies...). What I'm a bit afraid of, though, is some kind of competition about who can compress the PNGs the most, PR after PR, resulting in N different copies of the same image in history... well you understand.
(However: most of the images included in the executable are very small icons, so the gain in bytes is small there. The large images in doc/gitian-building aren't included in the binary distributions because they relate to building from source using gitian. So making them smaller doesn't help.)
Due a security concerns in #3341 (comment) (my machine could be possibly compromised, for example),
That could be avoided by, indeed, updating optimize-pngs.py, and making sure the process is deterministic. If a few people can follow the steps and get the same result, worries about individual's computers being compromised are alleviated.
The large images in doc/gitian-building aren't included in the binary distributions because they relate to building from source using gitian. So making them smaller doesn't help.
Which reminds me, maybe it would be better to move that whole thing to the wiki instead.
Closing this after the discussion above.