Hype 4 Fallback Images New Feature Feedback

Advertising
1

I’ve just given the fallback feature a go with an ad set in production and wanted to call out a few concerns.

Overall, it’s a very welcome to have support for this, but it falls short in one important area: the optimization of the fallback image is significantly larger than a “normal” fallback image I would create in another tool. One factor is that including an oversized fallback image makes the bundled ad unnecessarily larger, sometimes exceeding the common 150-200k limit.

This is a bit of a gray area since our ad network media partners don’t communicate details on if a fallback image is counted against the maximum ad size allowed, so for years we’ve simply made our fallback images to the same specification used for a static image ad (and in that way they can be used in both contexts). Static ad banners should not exceed 40k, and as always the smallest, best-looking, optimized format is the goal.

Here’s an example of how my process went:

I already had a lossless, optimized PNG of intended fallback content generated from Adobe Illustrator which was ~40k or less, all good-to-go.

If I capture a fallback image within Hype 4 Pro, it’s significantly larger than the optimized version I created when exported as a PNG or JPG. Obviously there are lots of manual options that come with image optimization, so this isn’t surprising given that the feature is very automated and only allows for picking which format is desired.

I assumed that if I replaced the automatically captured fallback image with my fully optimized fallback images Hype would simply use those as is. Instead Hype 4 transcoded those as the designed image format, which is renamed to “poster.xxx”. Where it gets funky is that those poster images were recompressed to twice the size of my original optimized images. In one case this bumped the ad file size over the limit.

I can of course manually hack this by either running all the generated “poster.xxx” images through an optimization “fixer” tool like TinyPNG just before publication, or manually replace the poster images with my own after compiling the ads, but that is actually more work than simply continuing to batch out static fallbacks from the same Illustrator source file I use to concept and create all the sprites/art for the ads in the first place.

In summary, it would be great if this feature improved the built-in image optimization in some way, or did not bloat up and recompress my manually re-assigned fallback images. Otherwise it’s pretty much unusable for large ads that are close to the file size limit already.

2 Likes
2

You can also use ImageOptim (allows dropping a folder onto it) but +1 for more control of “fallback” images and generating images in general (for other purposes). I am not to happy about the size based solution and wished for a more generic image generation engine (including some more settings on file types and compression levels). But at least there is a tool for now.

3

ImageOptim is also great, I just prefer TinyPNG’s quality and speed — I use the TinyPNG desktop app, since it’s faster than the browser-based workflow: https://www.betweenelements.com/tinypng-app

I’d think that most any web-based designer is going to have one or more of those kinds of tools available, but having to manually add that step at publication time isn’t something I can get behind. It’s also the kind of added step that really complicates training other team members (who usually aren’t as up-to-speed about image optimization).

1 Like
4

I have this same problem Eric, when I’m building ads I just turn off image optimisation inside of Hype ( uncheck ‘auto optimize when exporting’ in Resources panel ) and handle it manually myself with tinyPNG or Photoshop. Like you I find that Hype does not optimise images correctly and can make my prepared images larger in file size.

I’ll use Hype for the main animation build, use the export script, then manually go into each folder and optimise the images myself whilst checking the total folder file size until its under the required limit.

Its definitely something Tumult developers could look at as a feature as simple as a checkbox with ‘optimise full export folder to be under [enter size here] kb/mb’ when exporting - but until then Im optimising all images myself.

5

One could probably use tweak the export script to use the python version of tiny png. See https://tinypng.com/developers/reference/python

The sample export script has also an example how to process individual files if that isn’t already in the export script you are already using.

Hope that helps

6

but having to manually add that step at publication time isn’t something I can get behind.

Come on...:wink: That's 10 second "work". Export Hype project, grab the folder (which you'll always have to do), drop it on an image compressor and move on. :grin:

7

Come on…:wink: That’s 10 second “work”. Export Hype project, grab the folder (which you’ll always have to do), drop it on an image compressor and move on. :grin:

Sure, it's not a huge time killer to batch after-the-fact. However even when you manually batch through TinyPNG/ImageOptim/etc., the files don't optimize that much — so I'll possibly still be over the performance budget, which I have to manually check and fix as needed.

My feedback is more towards eliminating some of the manual QC'ing in the publication process, which is more important if this can't be (entirely) automated, especially with ad batches as large as 48 folders.

My feedback is regarding a built-in feature that supposedly eliminates the need to do fallback versions externally (or to include those when Hype projects are compiled). The feature works, but only up to the point where performance budgeting needs to be handling manually.

I've already been including fallbacks manually for the past few years and have that process automated with tools from Adobe, etc. I will probably need to continue to design ad fallbacks separate from Hype since the creative content sometimes has to vary for those.

Thanks to @Jaywing pointing out that disabling "Automatically optimize when exporting" should "pass through" the existing fallback art. I'll probably be testing this more today when my current project goes to publication.

8

Small update: disabling “Automatically optimize when exporting” doesn’t have any affect on poster/fallback image optimization. It’s always “on” and will recompress your custom images to 2-4x their original optimized size requiring you to manually replace them after ads are compiled.

1 Like
9

Awesome feedback; thank you for your usage of the feature. We’ve added this to our issue tracker - I consider this a bug in its behavior.

We want to make sure as many automatable steps in the ad flow are automated as possible. There are certain limits to what file compression we can use (many good ones use a license incompatible with Hype), but we can make sure integration is as painless as possible (by letting it go to an external editor or not rewriting on export), or at least give reasonable baseline compression.

2 Likes
10

Anyone tried using CodeKit for this? You can set it up top watch a folder and it will do whatever you set it up to do: compress images, minify/obfuscate code etc. Maybe something that could be useful - at least until Hype does it for you?

1 Like
11

I’ve successfully duplicated and modified one of the Python export scripts to add a customization to satisfy a funky third-party vendor issue, so this is probably possible for a savvy person.

I’d think the biggest challenge is that you’d still need to link to an existing image optimization API that isn’t included within Hype; For example, the TinyPNG API requires you generating a unique personal key to use it with third-party apps, and even with that set up the script would need to shoot the images to the TinyPNG servers, then overwrite the ones on disk (which is not a default option).

If you linked to a localized ImageOptim or similar process, that would still need to be set up and installed in a common way that Tumult may not be able to provide in a way that “just works”.

That said, the Python export scripts (which in turn use the MacOS Automator system) are pretty impressive examples of extending the application.

1 Like
12

Sorry for my belated reply — I was on vacation for a bit, and then busy…

Just to provide my $0.2, my preferred behavior for the poster feature is that it stay the same as you have it now — ideally with some kind of improved optimization defaults - especially for PNG which has lossless abilities.

The biggest roadblock for my workflow is that I can’t assign pre-optimized custom poster frames as collectable assets without getting them re-compressed to a much worse file size or format.

I mostly build ads for financial industry clients. Most of these have different content restrictions on the fallback ad versus the animated ad, simply due to how we have to provide disclosure-related content in the available space. So we actually have to design two versions for every ad size anyway.

I’m sure other Hype users are more than happy to be able to generate a poster from an existing animation and call-it-a-day, but it’s more common for me to be generating static fallbacks in Adobe Illustrator (or whatever) and including them as an asset.

So my request is that if I assign a “custom” poster graphic it is simply “passed-through” when the ad(s) are compiled.

2 Likes
13

Thanks for your additional thoughts and elaborating on your usage - very helpful. I agree that if you supply your own it should not be rewritten (and/or at least provide an option like with other images).

1 Like