How to separate texture-alpha without premultiplying the color?

Question

I want preview some game assets via Cycles for the game Space Engineers. The game uses packed .dds textures where the color and alpha channels store unrelated information: diffuse color + metallness, normal map + glossiness (roughness, inverted).

I think my problem is this documented behavior of image-texture nodes:

Color output: RGB color from image. If the image has alpha, the color is premultiplied with alpha if the Alpha output is used, and unpremultiplied or straight if the Alpha output is not used.

The result is that my shader nodes produce some strange artifacts when I use both image-texture outputs:

If I extract the alpha-channel of the textures into separate files and plug those in, the problem goes away. But I don't like doing that because it introduces an otherwise unnecessary conversion step to my workflow.

Here is what I already tried:

• Making sure Alpha is set to Straight for each image. I think that only affects how Blender treats the data it reads from file, though.
• Load the .dds into two separate image-datablocks. The first image has Use Alpha disabled and provides the RGB channels. The second one has Use Alpha enabled and provides the Alpha channel. This resulted in largely the same problem because it seems Blender optimizes internally and loads the same file only really once. I think that because toggling Use Alpha seems to affect the image-data of both images (without reflecting that in the UI).
• Use a MixRGB node: Add the color (0,0,0,1) to the color output and clamp the result. This shouldn't change the color (because adding black does nothing) and remove any transparency (because 1 + anything is 1 when clamped). Sadly, that didn't do anything.

Am I out of luck and using the alpha output simply cannot be done without affecting the color output?

Answer 1

The workaround WorldSEnder mentioned above is the only solution:

Duplicate each Texture Input node and get the RBG value from one, and the Alpha value from the other input.

The stance here seems to be that texture-files are simply not expected to contain unrelated information. The optimization to pack several unrelated channels into one texture-file to improve memory-locality on the GPU is just not that relevant to Blender to warrant a change to the behavior of Texture Input nodes.