Filesizes are larger than they could be
Closed this issue · 6 comments
I have a set of roughly 80 sprites. When I run spritesheet followed by pngcrush:
spritesheet-js --trim -f easel.js *.png pngcrush -ow -reduce -brute spritesheet.png
I end up with a 1.9mb file. When I use imagemagick manually:
convert -append -background none *.png spritesheet.png pngcrush -ow -reduce -brute spritesheet.png
I end up with a 1.1mb file.
From what I can tell, spritesheet-js is using imagemagick so such a huge difference baffles me.
The spritesheet-js file is 763 × 8,196 (6,253,548px) where as the manual spritesheet is 600 × 54,064 (32,438,400px). That's a huge difference in physical size, but the file difference is totally on it's head!
Any ideas how I can fix this?
My feeling is that a consistent vertical stacking will result in a smaller file size?
You can now select packing algorithm:
- growing-packing: the old one
- binpacking: same as growing-packing but with fixed width and height (you should to pass them manually)
- vertical: images are next to each other vertically
- horizontal: images are next to each other horizontally
Let me know if this solved your problem and what are file sizes now.
I made a quick test:
- binpacking: 400x1500, 421KB
- growing-binpacking: 764x761, 426 KB
- vertical: 355x3673, 431KB
- horizontal: 4291x355, 450KB
It looks like packing algorithm don't have big impact on file size. Maybe after running pngcrush there will be differences, but I didn't check it.
Try using animation frames. Maybe there is more file size saving when there are more repeating patterns?
Ok, I'll try. What are your results now?
TBH, at present I am playing with this
https://github.com/sublimehq/anim_encoder
Pretty hardcore though!
On Thu Oct 3 20:04:58 2013, Krzysztof Opałka wrote:
Ok, I'll try. What are your results now?
—
Reply to this email directly or view it on GitHub
#3 (comment).