Consider re-exporting image crate

[stinkytoe]

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

I would like to use functions from the image crate to perform manipulations on images such as crop, overlay, etc.

What solution would you like?

Please consider moving the image dependency from an internal dependency in bevy_render to a re-exported library in bevy_utils, similar to how hashbrown and others are exported.

What alternative(s) have you considered?

Currently I can add image as a dependency to my crate, but this means I have to ensure that I keep my version in parity with what Bevy is using internally.

Additional context

Bevy is awesome and I look forward to many years of developing games and tools against it.

I think that having the ability to manipulate image data in RAM could be a useful tool for certain use cases. I am writing an importer for the LDtk editor, and made the decision to build up internal Image assets myself for the layers, as opposed to the strategy from other crates of creating a sprite for each tile.

Here's an example of my (unpublished!) work, showing my use case: bevy_ldtk_asset

Exporting the image crate would be a small quality of life improvement for me, and possibly others, who wish to utilize the full extent of the image crate within Bevy.

[james7132]

We're trying to shrink and remove bevy_utils, and bevy_utils is very low on the dependency tree, with crates like bevy_tasks depending on it, so moving it to bevy_utils is probably not a great idea.

Reexporting it from bevy_render may make more sense.

[stinkytoe]

We're trying to shrink and remove bevy_utils, and bevy_utils is very low on the dependency tree, with crates like bevy_tasks depending on it, so moving it to bevy_utils is probably not a great idea.

Reexporting it from bevy_render may make more sense.

I would have no objection to this. I could even write the PR if that would be OK.

If so, I presume you don't want it in prelude. Would it be preferable to expose it as bevy::render::image or something more like bevy::render::util::image?

[james7132]

By all means, go ahead. Seems simple enough to do. The only concern when re-exporting a crate like this is how frequently can either crate afford to do breaking changes, and as far as I can tell, image tends to be much more conservative with their breaking change cadence than Bevy is, at least for the foreseeable future.

If so, I presume you don't want it in prelude. Would it be preferable to expose it as bevy::render::image or something more like bevy::render::util::image?

Sounds good to me!