Ability to get dimensions of image file

[alterae]

What problem does this solve or what need does it fill?

When loading an image asset from a file, there doesn’t seem to be any way to easily get the dimensions of the image. This makes it really annoying to do things dependent on image size (like dwarf-fortress style tile sets where you have a fixed layout and number of tiles but the actual size of those tiles is dependent on the actual texture size).

What solution would you like?

A way to easily get the dimensions of an image file in the assets directory, preferably while loading the asset so this can be done in startup systems.

What alternative(s) have you considered?

I could use a separate mechanism to access the image file outside of bevy’s asset-handling machinery, but that would probably add extra dependencies and really complicate things.

Additional context

In many game engines, such as macroquad or dragonruby, this is a natively supported feature. It is quite essential for doing any kind of one-time calculations that depend on the size of a texture, and its omission in bevy seems like an oversight.

[MrGVSV]

Just to clarify, Image::size doesn't fit your needs?

Is this specifically for use inside an AssetLoader?

[alterae]

Just to clarify, Image::size doesn't fit your needs?

Is this specifically for use inside an AssetLoader?

Image::size does not work with a handle created using AssetServer::load, and I want to get the image dimensions in the same startup system where I initially load the image, to minimize shenanigans and because other resources I want initialized early need to know that information.

And while I expect there is a path for turning a Handle<Image> into an Image I can actually call size on, that path was/is not clear to me, and in general it feels like a pretty high friction API, especially when doing this in something like Macroquad is so straightforward:

It could well be that I'm missing something, but as things are it feels less than ideal.

[MrGVSV]

Image::size does not work with a handle created using AssetServer::load, and I want to get the image dimensions in the same startup system where I initially load the image, to minimize shenanigans and because other resources I want initialized early need to know that information.

Yeah the problem is that assets are loaded asynchronously. And as far as I know, there is no way to await their loading in the same system. What you probably want to do is use states instead of a startup system. This way you can remain in the MyState::LoadingAssets state as long as you need to before transitioning to the next state.

You can check the load state with Res<AssetServer> or via an EventReader<AssetEvent>. Once loaded, you can use your Handle<Image> on a Res<Assets<Image>> to access the image asset and get its size.

All that to say, there is a way of getting the image size, but it requires a bit of change to the way your systems are organized. I think for Bevy to make this easier, we either need to add a method to AssetServer to load the asset async or we need to have better documentation/examples for loading and accessing assets in a startup-like way.

[alterae]

Yeah the problem is that assets are loaded asynchronously. And as far as I know, there is no way to await their loading in the same system. What you probably want to do is use states instead of a startup system. This way you can remain in the MyState::LoadingAssets state as long as you need to before transitioning to the next state.

You can check the load state with Res<AssetServer> or via an EventReader<AssetEvent>. Once loaded, you can use your Handle<Image> on a Res<Assets<Image>> to access the image asset and get its size.

Yeah see that's a bit frustrating considering just how much architectural overhead it would introduce just to load my game's one (1) image file. It would be nice to have some way to 1) block on loading assets, for small one-time loads like this and 2) get the actual asset directly from the asset server or something.

[MrGVSV]

Yeah especially for small assets, a synchronous approach could be nice. See also #1701.