Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add option to limit output image size #55

Open
marekventur opened this issue Jun 5, 2015 · 18 comments
Open

Add option to limit output image size #55

marekventur opened this issue Jun 5, 2015 · 18 comments

Comments

@marekventur
Copy link

Some browsers (most notably iOS Safari) have a limitation as too how large a single image can be: https://developer.apple.com/library/mac/documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html#//apple_ref/doc/uid/TP40006482-SW15

I know this might be problematic in a few ways, but are there any plans to support an option that limits the output file to a given pixel amount (say 3 megapixels) and exports multiple pngs if necessary?

Texturepacker (used mostly for game sprites) has a similar option of limiting the maximum output size: https://www.codeandweb.com/texturepacker/documentation#settings-layout

@marekventur marekventur changed the title Add option to limit output filesize Add option to limit output image size Jun 5, 2015
@twolfson
Copy link
Owner

twolfson commented Jun 6, 2015

This is a duplicate of #35 but when thinking about this problem again, I want to give it more thought.

The ideal solution is to actually break at a given size and generate multiple spritesheets. There are a few problems attached to this:

  • There is no convention for multiple spritesheets for dest
    • If we move to a templating approach, then we open a can of worms for everyone wanting their custom naming scheme for the numbers themselves
    • If we move to an array of names, then users will have to keep this up to date with the length of spritesheets. However, it also breaks integrations with grunt-newer
  • When we have maximum size and retina spritesheet generation
    • We need to make sure that any spritesheet breaks at the normal level are replicated in retina format
    • The same templating solution that is used for dest (normal spritesheets) must exist for retinaDest (retina spritesheet)

One much simpler solution that dodges this can of worms would be to have a max-size option that will fail the task if the calculated spritesheet dimensions will exceed the given size.

@marekventur
Copy link
Author

Fair enough, I was expecting it to be quite complicated.

I have no real solutions to the problems you raise and my use case might be a bit too niche to warrant full-scale refactoring and breaking compatibility. A max-size option would be nice though, I'll have a look and see whether there's an easy way to add that, I'll open a separate PR in that case.

@twolfson
Copy link
Owner

twolfson commented Jun 6, 2015

After thinking even more, the first option has more issues:

  • We would need to support outputting multiple spritesheets in the same template
    • This would wind up breaking existing custom templates

The simpler solution is probably our best bet (i.e. to error out if max-size is exceeded).

@twolfson
Copy link
Owner

twolfson commented Jun 6, 2015

Although, it would be maxSize or maximumSize as our options are camelCased.

@ericlathrop
Copy link

ericlathrop commented Jun 11, 2016

I just wanted to chime in with my use case. I'm making HTML5 video games using WebGL. WebGL requires that textures are constrained to power-of-two dimensions. Also, different graphics cards have different maximum texture sizes, with the low-end being 2048x2048, and a common limit of 4096x4096.

Something like spritesmith is valuable to me because I can put it in my build process, and don't have to require that everyone install texturepacker because spritesmith gets installed with a normal npm install.

Since the issue is a year old, can I get some feedback on what kind of PR would be accepted for this feature if I were to implement it?

@twolfson
Copy link
Owner

I think this issue stopped due to a lack of what behavior people would expect (e.g. multiple spritesheets but how would we handle names, erroring out). Based on other issues by @marekventur, it looks like they opted to do the layout handling themself and using the image creation libraries directly (e.g. gmsmith):

twolfson/gmsmith#14

@marekventur
Copy link
Author

marekventur commented Jun 13, 2016

Hi! Sorry @twolfson for not following up on my gmsmith pull request, everything got rather busy. As to the game packing issued @ericlathrop is talking about, we have written a more game-specific texture packer Gamevy/pixi-packer (it's pretty generic, it doesn't need pixi.js to work). The main different to spritesmith is that it creates multiple spritesheets (based on size) rather than just one. Under the hood it's using gmsmith to do the actual drawing.

As an aside: I've done some research of my own into PowerOfTwo textures for webgl and contrary to what some web resources say I couldn't find any performance benefits of forcing images to be POT compatible, all it did was increase the download size. YMMV.

@twolfson: Since this issue is somewhat orthogonal to the way spritesmith work, shall I close it?

@twolfson
Copy link
Owner

Ah, neat. Thanks for doing the benchmarking =)

I think we will start pointing people to pixi-packer for this scenario then (i.e. multiple spritesheets).

You are definitely using spritesmith properly as intended so kudos on that. We split up the engines into separate modules for reuse in cases like this =)

I think we are good to close this issue as long as @ericlathrop has no opposition to using pixi-packer

@ericlathrop
Copy link

@twolfson I don't want to require people to install ImageMagick (or anything else that doesn't come from NPM), so pixi-packer won't work for me.

@twolfson
Copy link
Owner

Unless I'm missing someting pixi-packer should be able to let people choose their engine like spritesmith, right @marekventur?

@marekventur
Copy link
Author

marekventur commented Jun 14, 2016

I haven't actually implemented a config option yet, but it should be relatively straightforward to make the spritesmith engine configurable. There are two other things that I'm doing with imagemagick though (cropping and scaling), so it would be a bit more work to replace those with pure node.js equivalents.

@twolfson
Copy link
Owner

Can you elaborate on what cropping/scaling are being used for? And I thought imagemin was only for minifying images (e.g. stripping metadata, reducing quality in invisible manner).

@marekventur
Copy link
Author

sorry, I didn't mean "imagemin", I meant "imagemagick", my mistake :(

This is the file that has all the image processing stuff that would need to be translated into pure node code: https://github.com/Gamevy/pixi-packer/blob/master/lib/image_processor.js

@ericlathrop I'm happy to help if you're interested in adding a non-imagemagick option. Open an issue and we can go from there.

@SupremeTechnopriest
Copy link

Pixi Packer looks like its broken. Its trimming the entire image. Issue has been open for over 3 months. Looks like the project is abandoned. Any chance we can get this feature added to Spritesmith? Defining max image size and outputting multiple sheets would be awesome.

@twolfson
Copy link
Owner

twolfson commented Oct 8, 2021

I'm open to discussing implementation/taking a PR for this but spritesmith isn't really designed for this =/

It might be easier to tweak pixelsmith to be more packing aware and use that directly

@SupremeTechnopriest
Copy link

Thanks for quick reply :) I will take a swing at making a wrapper.

@aapavlov1994
Copy link

@SupremeTechnopriest i made somekind of wrapper, take a look
https://github.com/aapavlov1994/multi-sprite-creator

@SupremeTechnopriest
Copy link

@aapavlov1994 Thanks for the heads up! I will definitely check this out!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants