Getting "Loaded resource as image file" warning, but the code is legit because it runs in editor

[Zylann]

Godot 3.1 alpha2

In my terrain plugin, I deal with images often and also save and load them with Image.load() and Image.save_png() using the project resource paths. The reason I'm doing this is because I want them to be editable in the editor, and textures are ImageTextures, while they will be StreamTextures in the exported game (in which case I use load normally, unless the game itself also wants to edit them).
On a side note, it forces me to swap between StreamTexture and ImageTexture quite often, honestly I don't really get the difference between them as an API.

But the point is, it makes the editor throw these warnings often:

WARNING: load: Loaded resource as image file, this will not work on export: 'res://tests/terrain7/terrain7.hterrain_data/color.png'. Instead, import the image file as an Image resource and load it normally as a resource.
     At: core/image.cpp:1742

I don't know how I am supposed to avoid it. My plugin has to load images, forcing them to have an import option to load them as images is not fit to the task here.

[aaronfranke]

I'm also having this problem, and I have no idea what kind of code I'm supposed to use to fix it. How do I import as an Image resource and then load it as a resource? I save & load images via code.

[Zylann]

@aaronfranke you can change the import setting like this:

In my case this warning is useless because I can't ask the user to change import settings on images just because my plugin loads them for editor purposes.

[nightblade9]

I, too, ran into this problem. When writing C# code, I can't figure out how to invoke preload like I normally would, so I end up loading sprite textures like this, which generates the same warning + shows no image on export:

var sprite = new Sprite();
var texture = new ImageTexture();
texture.Load("res://assets/images/foo/bar.png");
sprite.Texture = texture;

I would really appreciate a work-around or solution.

[Bal-Gu]

@nightblade9 a work around would be:

var sprite = new Sprite();
sprite.texture = load("res://assets/images/foo/bar.png")

Make sure that in the import settings (By default on the left next to the scene tab) you select import as Texture.
This worked for me in Godot 3.2

[Tarudahat]

I should prob not ask this here but, I have re-imported my icon.png to a texture resource but it still trows this error at me when trying to export/debug HTML5 any ideas on what I could be doing wrong?

[Bal-Gu]

@Tarudahat have you tryed ro script it instead of going through the editor.
If yes share the code please ^^.

[Tarudahat]

@balgu No I havn't how would I do that?

[merriam]

This is probably the icon.png problem:

The most common cause is the project including icon.png as a default setting. For running on the web, you should convert this to icon.icns. You can use this free converter page to do that.

Once you have the converted icon, go to Project/Project Settings/Application/Config/icons and select your new icon.icns. This doc page may help.

---

Given that the error message is basically cryptic, I suggest the error message change slightly if the offending icon a res://... in the project's Application/Config settings.

[Calinou]

@merriam Where did you see that .icns requirement for HTML5? .icns is the macOS-specific icon format.

[Xrayez]

I don't know how I am supposed to avoid it. My plugin has to load images, forcing them to have an import option to load them as images is not fit to the task here.

I've found a workaround to this in #39396 (comment). 🙂

static func image_load_no_warning(filepath):
    var image = Image.new()
    image.load(ProjectSettings.globalize_path(filepath))
    return image

[merriam]

TL;DR: Error also comes from Export when the application icon is PNG on macOS.

Let me a bit more clear about behavior on macOS:

This should work:
Create a new project
Add a root Label node, setting text to "Hello, Godot"
Save and do the 'run scene', it seems to work.
Project/Export.../Add/HTML5
Export Project
Get Loaded resource as image file warning. This is related to Project/Project Settings/Application/Config/Icon default value icon.png

So, then this should work:
Create an icon.icns file.
Set Project/Project Settings/Application/Config/macOS Native Icon to icon.icns
Export Project
Get " "Loaded resource as image file" warning. Again.

This should not work, but it does:
Set Project/Project Settings/Application/Config/Icon to icons.icns. If using the "folder icon" file selector, you need to select All Files (*) as this is not a recognized extension.
Export Project. no warning.

This should work, and it does:
Set Project/Project Settings/Application/Config/Icon to blank, using the 'reset' icon.
Export Project. no warning.

In my humble opinion,

• the defaults should always work, so having Export fail by default is wrong. The easiest fix is for the default project icon (Project Settings/Application/Config/Icon) to be blank.
• error messages should be precise in location and meaning. Instead of listing core/image.cpp:1890 as the source of the problem, it should mention the offending setting (icon.png in Project Settings/Application/Icon).
• prescriptive fixes, as mentioned in Print warning once when loading an image from res:// path #39396 should not be printed unless they absolutely apply to the problem.

[Calinou]

error messages should be precise in location and meaning. Instead of listing core/image.cpp:1890 as the source of the problem, it should mention the offending setting (icon.png in Project Settings/Application/Icon).

We can't specify how stack traces are presented for specific error messages.

[merriam]

error messages should be precise in location and meaning. Instead of listing core/image.cpp:1890 as the source of the problem, it should mention the offending setting (icon.png in Project Settings/Application/Icon).

We can't specify how stack traces are presented for specific error messages.

True.

Still, the "Instead, import the image file as an Image resource..." is incorrect here. Might be better to point to web page explaining in depth the reasoning and work around? There isn't a one size fits all advice, and it does seem odd restriction.

[Xrayez]

Might be better to point to web page explaining in depth the reasoning and work around?

#42412 adds a link to the Importing images page in the documentation, as well as the current warning and a possible solution, depending on your use case. 🙂

[Zylann]

As I said, importing as an image is not an option in my use case. My case fits your doc requirement: This method should only be used in the editor, yet the warning occurs anyways.

In fact, despite this issue is about the editor use case, I realized it may not even be the only one: at least one of my images needs to be loaded BOTH as an image and a texture, the heightmap, because of physics. Users sometimes also need to access terrain maps from scripts. Importing only allows one type, and as far as I understand get_data(), it may impact loading time due to needlessly download the texture from the graphics card while we could have it right away. (an edge case would also be servers, where terrains don't need to even load textures).

[Zylann]

Github doesnt allow me to edit today so I'll amend with an extra message:
The heightmap use case is lucky though, because it's the only image I don't run through the importer so what I just said is less important. That's a thing only because I wasnt able to use EXR though. So if I switch, that will become relevant again.

[Xrayez]

Yes, there are #39396 and #42653 by now which can either mitigate the warning or remove it completely, because I don't see a way to make the warning condition specific to those described use cases. And images/textures are not the only type of resource which can have the same import/load problem in exported projects, it just happens to be most frequently used type of resource, I believe that's just a kind of "limitation" (feature!) which one has to be aware of, so that's why I'm suggesting documentation changes as well.

[merriam]

Meh. I'm bowing out of the discussion. At this point, I truly do not understand why the limitation exists, why it is not automatically mitigated, nor why there there is not clear documentation explaining why it must exist. I guess it's a Godot Thing like GIMP refusing to have a circle tool.

[Xrayez]

@merriam there's no limitation with this specifically, it's just currently an annoyance. 😄

The limitation I mentioned is with the import/load dilemma which is inherent to Godot's design at large, as described in godotengine/godot-proposals#1632.

The problem this warning is trying to prevent is exactly usages like #24222 (comment) (loading images like this would make it fail to load textures once the project is exported, because original images are not part of .pck, and Image.load() bypasses the resource load() mechanism by looking at system paths instead when using the res:// path). But then again, as numerous people pointed out here, it does not apply to all use cases.

The discussion is almost the opposite to what Akien said to me in #31832 (comment):

I'm not sure adding "(missing filename?)" is a good idea, that would be just one possible reason for the failure [emphasis mine], and it's not very clear to me either. I guess what you mean is that you tried to use it by giving only the path to a folder, and then it failed? In that case I think it's more a documentation issue [emphasis mine], maybe the argument should be named "file_path".

Yeah overall I'm not against giving hints, but I prefer that it's done when the hint has a very high percentage of being the correct explanation (> 50%).

I totally understand now that if a error/warning message doesn't apply to most use cases, then the possible rationale should not be printed. Documentation is here: #42412.

Alternatively, perhaps adding Image.load_from_file() would be a solution to avoid the warning in cases where it does not apply, and modify the warning message to use the suggested method instead (as well as importing the resource as an image), because currently it requires weird workarounds like #24222 (comment).

Another alternative is to move the ProjectSettings.globalize_path() as a String method, so the workaround would be less hacky:

image.load("res://icon.png".globalize_path())

But then again, the issue as described in #24222 (comment) cannot be even worked around via script.

[akien-mga]

I haven't followed all recent discussions and proposals around this, but to clarify: the warning raised by load() is a hack to work around a design issue in Godot's import pipeline which many users face when trying to load images (among other things, but mostly those) at runtime.

IMO adding this warning was not particularly a good solution and a more thorough rethinking of the UX around importing assets and loading them at runtime needs to be done.

[Zylann]

Just a note to say it still happens in Godot 3.4.4 (and likely in 4.0 though I havent tested). It is even printed while doing nothing upon project opening, due to the preview thumbnail generator loading images for the first time.

[gravit22]

I don't know how I am supposed to avoid it. My plugin has to load images, forcing them to have an import option to load them as images is not fit to the task here.

I've found a workaround to this in #39396 (comment). slightly_smiling_face

static func image_load_no_warning(filepath):
    var image = Image.new()
    image.load(ProjectSettings.globalize_path(filepath))
    return image

I can't workaround this issue in Godot 4.0 with this suggestion.
png images do not show in resulting apk, also when I do the things above, Images do not show up even in pc version.

[donn-xx]

Also developing a plugin. v4.2.beta4.official [93cdacb].

This emits that warning:
image = Image.load_from_file(iconpaf)

I can't know iconpaf before hand, it's an editor plugin.

BTW icon_paf is stuff like: "res://addons/dabber/assets/icons/dabList.small.svg"

Warning text:

WARNING: Loaded resource as image file, this will not work on export: 
'res://addons/dabber/assets/icons/dabDab.small.svg'. Instead, import 
the image file as an Image resource and load it normally as a resource.
     at: load_from_file (core/io/image.cpp:2504)

[Calinou]

You may be able to work this around using: Image.load_from_file(ProjectSettings.globalize_path(iconpaf))

The warning is only printed if the parameter passed to load_from_file() begins with res://. It won't be printed if you give it an absolute or relative filesystem path.

[donn-xx]

I hacked a bit and tried:
var icon = load("res://addons/dabber/assets/icons/dabDab.small.svg")

And, Lo, silence with a nice icon!

The docs do mention it, but I find the whole Image / Texture thing very confusing and always read their docs with a kind of panic.