There’s a couple misunderstandings here.
First: OpenGL will perform conversions from any format/type to the internalformat, with only a couple of exceptions (spelled out by i.e. EXT_texture_integer, ARB_depth_texture etc.)
So there is no single mapping of client format/type to something like GL_FORMAT_R16G16B16A16_FLOAT. These are all valid mappings:
GL_FORMAT_R16G16B16A16_FLOAT, GL_RGBA16F, GL_RGBA, GL_HALF_FLOAT
GL_FORMAT_R16G16B16A16_FLOAT, GL_RGBA16F, GL_RGBA, GL_FLOAT (client’s float data will be converted to half float during transfer)
GL_FORMAT_R16G16B16A16_FLOAT, GL_RGBA16F, GL_LUMINANCE, GL_HALF_FLOAT (client’s single channel will be expanded to RGBA during transfer)
GL_FORMAT_R16G16B16A16_FLOAT, GL_RGBA16F, GL_RGB, GL_UNSIGNED_BYTE (client’s data will be expanded and converted)
(many, many more…)
So, you can create a singular mapping from GL’s internalformat to an enum of your choosing. But the transfer from client to GL’s internalformat, by definition, allows for a combinatorial explosion of conversions.
Second: UNORM is unsigned normalized data. This is data which is stored as a fixed point integer (for example, a 0.8 byte) but is treated during processing as a float value (i.e. you get [0…1] when you sample it in a shader.) This is distinctly different than an “int” type, which is stored as an integer, and is sampled as an integer (on SM4 hardware.)
So:
GL_FORMAT_R16G16B16A16_UNORM, GL_RGB16UI, GL_RGBA, GL_UNSIGNED_SHORT
isn’t a valid conversion per the EXT_texture_integer spec. Client and internal integer-ness must match (but note that expansions and conversions are still allowed, as long as integer-ness is consistent.)
The “UNORM” types are the original, unsuffixed types in GL. So If you’re trying to match R16G16B16A16_UNORM, it would be:
GL_FORMAT_R16G16B16A16_UNORM, GL_RGBA16, GL_RGBA, GL_UNSIGNED_SHORT
(and by the way, there’s no guarantee that the requested internalformat will actually be used.)