Preserve image mimeType when converting from GLB to GLTF

[rawnsley]

The image mimeType field is mandatory when referencing a buffer (which is typical in GLB format) but optional when referencing files with well known extensions. It is stripped from the exported GLTF file, but it would be nice to have as a way to reduce ambiguity and for human readability. This is especially useful for files with extensions that use exotic image formats, which can lead to the exporter using the default .bin extension.

[emackey]

Interesting suggestion. Core glTF doesn't support any exotic image formats, only PNG and JPEG are allowed. We have known glTF extensions for WebP, KTX/KTX2, and DDS, all supported here. I'm not aware of other image formats supported in glTF, but I suppose a vendor extension to glTF could theoretically enable any of them. Is there a particular format you're interested in here?

I'm hesitant to provide blanket support for unknown extensions, as it's a design choice of glTF to avoid such things. A product claiming to support glTF wouldn't expect to find Sun Raster files or something in there. Anything other than PNG and JPEG requires a glTF extension to be listed in extensionsRequired to warn loaders that a non-core format is coming.

[rawnsley]

I'm specifically interested in image/x-exr and image/vnd.radiance format. In my case they are used for things like lightmaps and HDR skyboxes in Mozilla Hubs through their GLTF extensions. Here's an example scene extension for environment settings:

"extensions": {
  "MOZ_hubs_components": {
    "environment-settings": {
      "toneMapping": "LUTToneMapping",
      "toneMappingExposure": 1,
      "backgroundColor": "#ADB2B9",
      "backgroundTexture": {
        "index": 1,
        "__mhc_link_type": "texture"
      },
      "envMapTexture": {
        "index": 2,
        "__mhc_link_type": "texture"
      }
  }

They reference textures that look like this:

{
  "sampler": 0,
  "extensions": {
    "KHR_texture_basisu": {
      "source": 0
    }
  }
},
{
  "sampler": 0,
  "extensions": {
    "MOZ_texture_rgbe": {
      "source": 1
    }
  }
},

Both textures provide just enough information for us to work out that the data will be some sort of KTX file and a radiance file:

"images": [
  {
    "name": "skybox",
    "uri": "category-dw0.1.0_img0.ktx2"
  },
  {
    "name": "envmap-category",
    "uri": "category-dw0.1.0_img1.bin"
  },

The first image has an extension that means we know it's a KTX2 file rather than KTX, but we are relying on the texture definition in order to interpret the image MIME type. This kind of coupling could be a hassle for the decoder, but definately gives the human reader pause for though.

I take your point about not wanting to surprise plain GLTF parsers, but if they don't support the required extensions then they don't support the file. The key thing for me is that the MIME type is already in the GLB file, so it's not like we would be introducing new information, just preserving existing information.

I will concede that it would be of very minor value.

[emackey]

I'll get a new version of gltf-vscode published in the coming days that uses the updated converter.

[emackey]

This is published now in v2.3.16. Thanks for the suggestion!

[rawnsley]

Thanks for the super quick turnaround.