Support for webp image format

7

Oh I didn’t mean to have that in there – left it in from some testing. It adds some nice features for responsive images based on media queries. You could pair this markup with Hype’s responsive layouts to speed up image loading for smaller layouts:

<picture>
  <source srcset="examples/images/extralarge.jpg" media="(min-width: 1000px)">
  <source srcset="examples/images/art-large.jpg" media="(min-width: 800px)">
  <img srcset="examples/images/art-medium.jpg" alt="…">
</picture>

In Hype, you may need to run picturefill(); ‘On Prepare for Display’ to ensure it is triggered. But it automatically will run on a browser resize.

DEMO: https://scottjehl.github.io/picturefill/examples/demo-03.html

8

There’s a few companies that capitalize on the complexity of this stuff (feature detection, image rendering, serving, processing). Cloudinary is one: https://cloudinary.com/documentation/responsive_images / https://cloudinary.com/documentation/responsive_images#automating_responsive_images_with_javascript

1 Like
9

Current support is looking pretty strong. Any plans for this capability to be added to Hype, so they can be manipulated the same as any png or jpg? I'm happy we can use them already, they're just a bit more cumbersome to deal with in comparison.

10

In the meantime check out … live transcoding of images in Hype once you put your project online.

11

That's pretty cool! I don't think I'll be able use this approach for HTML5 banners, but maybe...?

12

That is true, you probably need to have everything in the resources' folder for these. Here is another approach that allows you to add a WebP version to your resources folder, and it switches the file dynamically if supported. You still need to create the WebP files, though.

You could use something like this …

13

i guess this won't drecrease the ads weight? it'll be one more file within the ad-zip ...

14

Well, yes and no. The PNG file will never be downloaded if WebP is supported. If you mean that the ad network might decline your ad because of weight of the ZIP-file itself, that's another discussion to be had. You could always just ditch the support_format_webp() check and function and force the WebP onto the end user, but that would inherit the risk of using a relative new format on an older browser. This choice cannot be avoided even if Hype would support it native.

1 Like
15

yeah, sry. i thought the thread is about ads :slight_smile:

16

My thoughts are to use WebP images only (with no fallback) within the display ads, served locally from the packaged ad. I don't plan on using this in every ad produced, but I'm thinking of trying this out for image-heavy ads that would otherwise be impossible to fit within ad server specs. Safari is the only browser support that gives me pause.

If I wanted to use fallback images for when WebP isn't supported, I feel like ad servers would be more accepting of CDN delivery rather than packaging all images, knowing all wouldn't be served. I've run into instances where they count static backup images as part of the total K-weight, which makes zero sense.

I know that support of these is no different whether Hype has native support or not. My desire is for WebP images within Hype to have the same functionality as other images.

17

Out of curiosity … I just dragged a WebP into Hype and it seems to works… IDE and Previews.

CleanShot 2021-03-07 at 17.02.58@2x
CleanShot 2021-03-07 at 17.02.58@2x2496×1824 309 KB

18

Huh. I'm on Hype 4.1.5 and while I can drag a WebP into the resources panel, I can't get them onto the stage. Trying another way and using Insert > Image from the menu, WebP files are greyed out... :thinking:
How'd you do that?

19

Hmm, Does not work for me either.

Pretty sure Hype is using an allowed type by extension name rather than encoding as I just changed a webp extension to .jpeg and it let it in but could not parse it correctly.
Did the same with a jpeg-> webp and it was blocked.

20

I dragged the WebP image directly into the stage. Seems like it is not checking types in that case? I am also on 4.1.5 (728) Professional Edition. It even works when I drag WebP into Resources. I need to turn off image optimization as it would convert to jpg on export.

WebP.hype.zip (57,2 KB)

21

Screenshot 2021-03-07 at 18.33.23
Screenshot 2021-03-07 at 18.33.232070×1372 146 KB

I suspect then that it is an Mac OS Version thing then.

The Mac I am on is Mojave 10.14.x

I exported it and the webp did show in the exported html. ( as expected , I guess ) Ah, only in Chrome...

22

well, at least you'll be able to use an exportscript that deletes pngs and jpeg and redirects the requests to the webp-file

3 Likes
23

That might be it… I am on the new M1 ARM Chip on the latest Mac OS build.

2 Likes
24

Safari 14 on macOS 11 Big Sur supports webp.

Since Hype uses Safari's rendering engine under the hood and macOS 11 declares this as a valid image format, Hype will import and display this properly* as well. Due to this, even Hype 1.0.0 supports webp on the right OS :slight_smile:.

(* It seems it doesn't put it in a resource library @1x/@2x grouping, so we'll need to fix that bit)

3 Likes
26

I'm currently using Hype 4.1.8 and I've included a webp image that when exported, either using 'Export as HTML5…' and 'Advanced Export…' (both with and without OrganizedAssets) results in the webp image being converted to jpgs (default and 2x) which are significantly larger in size than the imported webp image.

How can I export a project that uses webp images?

27

Hype is a bit overzealous in thinking it isn't web-safe-enough since it is a newer format, and always wants to convert it regardless of a size savings.

You can turn off the conversion by selecting the image asset in the Resources Library and unchecking Automatically optimize when exporting.

3 Likes