Compiled Web Export Template Doesn't support jpgs (but pngs work)

Help
, ,
1

Godot Version

v4.4.1.stable.official [49a5bc7b6]

Question

Hello, I’m trying to build for web and iOS users are reporting crashes. So I decided to make a build with fewer modules enabled. Followed instructions in the documentation and have gcc version 14.2.1 20240912 Python 3.12.8 SCons: v4.6.0 emsdk 4.0.8 and checked out the GODOT branch 4.4.1.

I ran the most basic build imaginable to test things: scons platform=web target=template_release

I then edited my “Web” export settings by selecting the newly built godot.web.template_release.wasm32.zip for Custom Template > Release (advanced settings on).

The app I’m making has local files in user: that include mp3, jpg and png files. The png and mp3 files work just fine. And in normal builds with the default export templates, the jpgs work just fine too. But when using this export_template .zip I see in the web console: "ERROR: Failed to load image. Error 15. at: load_from_file (core/io/image.cpp:2551) and none of the jpgs load. ERROR 15 appears to be ERR_FILE_UNRECOGNIZED according to core/error/error_list.h. This error is printed when calling Image.load_from_file() with the jpg filename. The file exists, and displays fine with the default export template.

So why is my export template not supporting jpgs when it seems to me that I’m building the most vanilla version possible? I haven’t even started culling out modules. Just scons platform=web target=template_release

This is how my build ends:

[ 95%] Linking Program bin/godot.web.template_release.wasm32.js …
[ 95%] em++: warning: -pthread + ALLOW_MEMORY_GROWTH may run non-wasm code slowly, see Threads + memory growth + JS · Issue #1271 · WebAssembly/design · GitHub [-Wpthreads-mem-growth]
[ 95%] Install file: “bin/godot.web.template_release.wasm32.wasm” as “bin/.web_zip/godot.wasm”
[ 95%] Archiving bin/godot.web.template_release.wasm32.zip …
[ 96%] scons: done building targets.
INFO: Time elapsed: 00:00:38.51

2

I should also mention that the build output mentions libjpeg_turbo, and seems to have no issues with compiling these files:

53%] Compiling thirdparty/libjpeg-turbo/src/jfdctfst.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jfdctint.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jidctflt.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jidctfst.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jidctint.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jidctred.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jutils.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jquant1.c …
Compiling thirdparty/libjpeg-turbo/src/jquant2.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jaricom.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcapimin.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcarith.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jchuff.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcicc.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcinit.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcmarker.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcmaster.c …
[ 53%] Compiling thirdparty/libjpeg-turbo/src/jcomapi.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jcparam.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jcphuff.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jctrans.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdapimin.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdarith.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdatadst.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdatadst-tj.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdatasrc.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdatasrc-tj.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdhuff.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdicc.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdinput.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdmarker.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdmaster.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdphuff.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jdtrans.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jerror.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jfdctflt.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jmemmgr.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jmemnobs.c …
[ 54%] Compiling thirdparty/libjpeg-turbo/src/jpeg_nbits.c …

3

If the jpg file can be loaded in a native build but the same file fails in a webassembly build then it’s better to report the issue in the issue tracker as libjpeg-turbo was added recently Use libjpeg-turbo for improved jpg compatibility and speed by DanielKinsman · Pull Request #104347 · godotengine/godot · GitHub

4

Thanks for suggesting the issue tracker. Perhaps I can find more info by searching that. However, I wouldn’t say it fails in any webassembly build. It only fails in the web build that I export using the export_template that I compiled. If I use the downloaded 4.4.1 export template, it works fine. I imagine that libjpeg-turbo is used in both cases?

5

I see that those libturbo pushes were made just days ago. But I wouldn’t expect that to affect my custom build, since I’m on 4.4.1-stable.

git status
On branch 4.4.1-stable

6

I think I may have checked out master after all. I followed instructions to use --depth 1

You can add the --depth 1 argument to omit the commit history (shallow clone).
A shallow clone is faster, but not all Git operations (like blame) will work.

But it does look like that got me master, and when I did ‘git checkout 4.4.1-stable’, git had no concept of such a branch so it created a new one.

7

Yep, sounds like it.

Either way you may have found a problem in the master branch and it would be great if you could open an issue about it so it can be fixed.