Skip to main content
2
201010
Inspiring
November 15, 2016
Answered

File size optimisations, Animate, OAM, Muse

  • November 15, 2016
  • 1 reply
  • 945 views

Hi,

I'm hoping somebody might have some suggestions for file size optimisation in the above workflow. I am comparing output for Animate CC 2017 for HTML 5 with the same for AS3. This is for an animated header for a responsive site for an iOS game, so Flash is not an option (good name for a movie???)

The issue I'm having (summary: the OAM file is too big) seems to relate to Animate / Muse doing a pretty dreadful job of packing assets for export. I'm assuming this is a limitation either of OAM or HTML 5, but either way it seems to be increasing the overall file size of my output, not reducing it. The symptoms are duplicate data, poorly packed sprite sheets and others.

If anyone has an optimisation method for the above workflow it would be very much appreciated. Otherwise I'm going back to quills, magic markers and carrier pigeons.

    This topic has been closed for replies.
    Correct answer 201010

    I guess I've answered my own question; some of my solution may be really sophomoric but I'll mention it here in case anyone else finds it useful. The underlying problems are i) in coming at this from a Flash background ii) the publish dialogue being a bit on the clunky side iii) not being able to find documentation on my specific issue.

    So, to get your animation from 7.8Mb to 1.6Mb, bear in mind that HTML 5 does not appear able to use those nice Flash tricks such as having jpeg masks for alpha channels. It seems therefore to be a good idea to sort what background elements you can into flattened jpeg images and accept that any transparent PNGs are going to be pretty much full-fat in your final output.

    All of the usual image-specific optimisations still seem to apply, so right-clicking in the library and deciding which images can be highly compressed using photo jpeg is still valid. However, separating jpeg content from transparent PNGs and treating them separately seems to be helpful too.

    The kicker though, and I'm guessing a bunch of people have been looking at my previous post, knowing this already, and were just figuring out the polite way to tell me, is that you need to select 'both' when exporting sprite sheets. With hindsight this is pretty dam' obvious, but then with hindsight so is everything. You can probably afford to crunch your jpegs quite considerably, but of course PNGs with alpha are just something you're stuck with if you are animating transparent elements, so the best optimisation available seems to be to contain these components within a single sprite sheet (if possible).

    With respect to the clunkiness of the publish interface, the issue for me was simply that within a target folder it will overwrite files but not delete unused content. This turned out to be useful in that my so-called optimisations caused the HTML folder I was examining to jump up in file size by a couple of megs, making the cause fairly obvious.

    So that seems to work; HTML 5 isn't quite as bad as I thought it was, and I apologise to those nice people at Adobe for questioning their parentage

    1 reply

    2
    201010AuthorCorrect answer
    Inspiring
    November 15, 2016

    I guess I've answered my own question; some of my solution may be really sophomoric but I'll mention it here in case anyone else finds it useful. The underlying problems are i) in coming at this from a Flash background ii) the publish dialogue being a bit on the clunky side iii) not being able to find documentation on my specific issue.

    So, to get your animation from 7.8Mb to 1.6Mb, bear in mind that HTML 5 does not appear able to use those nice Flash tricks such as having jpeg masks for alpha channels. It seems therefore to be a good idea to sort what background elements you can into flattened jpeg images and accept that any transparent PNGs are going to be pretty much full-fat in your final output.

    All of the usual image-specific optimisations still seem to apply, so right-clicking in the library and deciding which images can be highly compressed using photo jpeg is still valid. However, separating jpeg content from transparent PNGs and treating them separately seems to be helpful too.

    The kicker though, and I'm guessing a bunch of people have been looking at my previous post, knowing this already, and were just figuring out the polite way to tell me, is that you need to select 'both' when exporting sprite sheets. With hindsight this is pretty dam' obvious, but then with hindsight so is everything. You can probably afford to crunch your jpegs quite considerably, but of course PNGs with alpha are just something you're stuck with if you are animating transparent elements, so the best optimisation available seems to be to contain these components within a single sprite sheet (if possible).

    With respect to the clunkiness of the publish interface, the issue for me was simply that within a target folder it will overwrite files but not delete unused content. This turned out to be useful in that my so-called optimisations caused the HTML folder I was examining to jump up in file size by a couple of megs, making the cause fairly obvious.

    So that seems to work; HTML 5 isn't quite as bad as I thought it was, and I apologise to those nice people at Adobe for questioning their parentage

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices