proposal: extension to declare SHA256 of images.

[vpenades]

I would like to propose an extension for images, where the extension would contain a single field: "sha256" with an hexadecimal value representing the hash of the image referenced by the image object:

The purpose is this:

In games, it is quite common to have a global texture store and share textures between models.

The solution usually suggested is to compare the full load paths, but that's not always possible if, for example the textures are archived internally, or in other cases it can happen the resources are actually duplicated and we want to avoid redundant loads.

An authoring application only needs to calculate the sha256 of every image and add the extension.

On the client side, like a game engine, it would check whether the image has been loaded using the sha256 as a dictionary key.

as a bonus, this can be used to verify the image bytes.

This may look like adding an "ID" to the images, but in this particular extension, there's no ambiguities since both the extension naming, and how to define the value of the property is clearly defined.

[emackey]

Hi @vpenades!

Will there be a case where an artist intentionally updates a texture that they know is shared by many assets? Using a hash here means that the image itself cannot change without discovery and updates to hashes in all assets that share the image.

I feel like this might be best prototyped as a vendor-specific extension, before we push for standardization here. It seems like it would work within a particular product ecosystem a little more smoothly than between products of different vendors, maybe.

[vpenades]

Conceptually, if the stored sha256 does not match the actual image, the asset would be considered faulty. This is something a validator could detect and report.

Anyway, the intention of this hash is not to protect or secure the asset, but as a helper feature for the graphics engine. And since it's an auto-contained feature (the sha256 can be generated from the asset content itself without human intervention) it's somethin I can see being used by an intermediate content pipeline tool.

The use case would be this:

• An artists creates and modifies the asset the usual way, no changes here
• The asset is added to the game assets to be processed by a content pipeline
• The content pipeline does its stuff: adds compression, optimizes the asset, and generates the sha256 for the images
  • notice that a content pipeline may choose to change the images, so the sha256 would be added at this point, not sooner.

From the graphics engine perspectice, it could load assets with and without the extension, but in case it finds an asset without the extension, it needs to calculate the hash at runtime. So this extension is essentially a performance feature. In other words, the intention of the extension is to have the hash precalculated, so the engine does not need to do it by itself

About being vendor specific, I think this pattern is common enough to derserve an EXT_ prefix.

And by existing, this feature may trigger unforeseen use cases.

it is true that older engines relied on MD5 hashing, which is now discouraged, but it's also true that Sha256 may be superseded in the future, so maybe a solution would be to have two fields: "hashing_algorythm" and "hash_value"

[Nolram12345]

I would like to voice my support for this extension for the use cases described about. Texture management with resources loaded through GLTF - especially GLB - is currently a fair bit more difficult than one would hope, particularly in regards to texture deduplication. This extension would simplify and improve pipeline stability in that regard, due to it's ease of automatic verification.