Support to load .webp files?

Development
1

I converted a 3MB .jpg image to 500KB .webp with:
cwebp -q 80 image.jpg -o image.webp

I was wondering on doing this to all textures here!

I could find a way to convert .webp to some supported format in memory (what would work as a loader), but I also wonder if a direct loading would be faster than doing that?

2

would this fit better on the plugins forum session?

3

Question is, what is your target platform?
At least for desktop using DDS is the only format that actually gives you compression benefits at runtime.

For mobile the size is of course way more important.

4

Creating an AssetLoader for .webp is doable (eg by integrating https://bitbucket.org/luciad/webp-imageio ). I check it few weeks ago, but I didn’t have time to do it. And DDS provide compression in memory (.png, .jpg, .tga, .webp are stored uncompressed in memory). But DDS is desktop only, for android and ios, there other equivalent.

1 Like
5
@david.bernard.31 said: Creating an AssetLoader for .webp is doable (eg by integrating https://bitbucket.org/luciad/webp-imageio ). I check it few weeks ago, but I didn't have time to do it. And DDS provide compression in memory (.png, .jpg, .tga, .webp are stored uncompressed in memory). But DDS is desktop only, for android and ios, there other equivalent.

that information is cool thx!

Do you mean the .jpg in memory is bigger than the actual .jpg file size? or that it is that size? also, do you mean the RAM or the gfx card memory?

I just thought if we could have a intermediary converter that reads the .jpg file and converts it in memory to a dds format? if another thread would be cool, just say so :). The main point it so have a smallest application, and less resource intensive possible while having quality, but if in memory it will be too resource intensive, it will fail as a concept.

6
@teique said: that information is cool thx!

Do you mean the .jpg in memory is bigger than the actual .jpg file size? or that it is that size? also, do you mean the RAM or the gfx card memory?

I just thought if we could have a intermediary converter that reads the .jpg file and converts it in memory to a dds format? if another thread would be cool, just say so :). The main point it so have a smallest application, and less resource intensive possible while having quality, but if in memory it will be too resource intensive, it will fail as a concept.


There are some formats that are compressed in VRAM, such as DXT and ETC. Everything else needs to be decompressed before being passed onto the GPU. So JPG, PNG, GIF, WEBP, etc need to be decompressed first, whereas DXT and ETC can just be copied directly from file into a texture without any decompression.

The advantage of using, say JPG or WEBP instead of DXT and ETC, is mainly filesize. If you really need your app data to be small, you have to use formats with the highest compression ratio and you don’t really care about the size of the data when decompressed.

So the rule of thumb is, use DXT and ETC if:

  • You know the platform supports it: All desktop GPUs support DXT, and all mobile GPUs support ETC.
  • You really care about VRAM usage, e.g. your scene uses many high-resolution textures, such as normal / height / gloss maps and you're targeting low-end GPUs which might not have a lot of VRAM.
On the other hand, use the other formats if:
  • The app needs to be downloaded over the internet over a potentially slow connection, such as dialup, and you want to reduce filesize as much as possible.
  • You're targeting a wide variety of hardware so you cannot take advantage of platform-specific GPU compression
7
@Momoko_Fan said: ...
  • The app needs to be downloaded over the internet over a potentially slow connection, such as dialup, and you want to reduce filesize as much as possible.
  • You're targeting a wide variety of hardware so you cannot take advantage of platform-specific GPU compression

    • That is exactly where a conversion layer from .jpg to .DXT/.ETC (in memory) would fit in perfectly too! to easy the download, and to provide more compatibility with less trouble to the project developer!

    8
    @teique said: That is exactly where a conversion layer from .jpg to .DXT/.ETC (in memory) would fit in perfectly too! to easy the download, and to provide more compatibility with less trouble to the project developer!
    It takes a long time to compress into DXT / ETC, and you don't want your users waiting at the loading screen. Also you will lose double the quality because both JPG and the GPU compressed formats use lossy compression.
    9

    An other point against converting at runtime, it’s that DXT compress directly a normal map than diffuse,…
    All this conversion should be part of the asset pipeline : where you transform editable data (source) into target data (it’s like compiling the code, cross platform, native,…). It can also be part of the packaging stage.

    10
    @Momoko_Fan said: It takes a long time to compress into DXT / ETC, and you don't want your users waiting at the loading screen. Also you will lose double the quality because both JPG and the GPU compressed formats use lossy compression.

    ahh… so, even instead of having a direct load from .webp or .jpg etc, if I use some OS specific converter from a .webp to .DXT or .ETC as an application texture cache initializer, it would be the best option right?

    and also, if the user do prefer to not create that cache, the .webp textures could be directly loaded into the application when such plugin comes by :), or may be I could opt to convert just some of the textures to .DXT or .ETC, and both would fit well together!