there is different coordinate systems. you can google "left hand versus right hand coordinate system" and search the wiki here it has a good explanation.
the way it is packed might also be a factor. it is possible to pack normal to two channels only and use a math function to rebuild the missing channel. That way an additional grayscale map can be used without additional texture file needed.
ben cloward on youtube has a video showing how to do that in unreal (and maybe unity as well)
Yeah, the first image probably shows a two-channel (red green) normal map. There are some compression formats that provide better quality for normal maps (higher bit-depth) without making the file size too big. The blue channel is reconstructed in the shader.
not that i know of. i think that it always has to be the up axis which is derived from the two other axis but somebody more tech saavy than me could say otherwise.
if you are viewing the textures like ripped from some game the naming convention might provide a clue.
edit: didn't see earthquakes response above. thats the expert, not me!
In this case I don't think even that's needed, it's just assumed the blue channel is white (set the blue channel to white in the top image and you get much the same output as the second image) with tangent space normal maps there's never really a lot of detail in the blue channel. All the normal perturbation is in the red and green channels, the blue is really just changing it's overall length.
if you imagine each pixel is a tiny plane with a lookat constraint to a point directly above it then the red channel moves the point +- in x and green +- in y and blue +- in z. blue will only really change the plane orientation ( the lighting) when x and or y are relatively large (or very negative) otherwise it's effect is pretty subtle.
in reality the blue channel saves you from having to normalize the normal vector in the pixel shader but if you are willing to live with some over perturbed normals you can do without.... white on the left, white and normalized on the right, and with textures though normal.z = normal.x + normal.y; gives a bold effect... if the lights in the right direction
In this case I don't think even that's needed, it's just assumed the blue channel is white (set the blue channel to white in the top image and you get much the same output as the second image)
This appears to be correct after testing. As EarthQuake mentioned, it's a red/green only compression format "BC5_SNORM".
Making the blue channel white makes all of the grey/red/green images look like standard normal maps.
Replies
In this case I don't think even that's needed, it's just assumed the blue channel is white (set the blue channel to white in the top image and you get much the same output as the second image) with tangent space normal maps there's never really a lot of detail in the blue channel. All the normal perturbation is in the red and green channels, the blue is really just changing it's overall length.
if you imagine each pixel is a tiny plane with a lookat constraint to a point directly above it then the red channel moves the point +- in x and green +- in y and blue +- in z.
blue will only really change the plane orientation ( the lighting) when x and or y are relatively large (or very negative) otherwise it's effect is pretty subtle.
in reality the blue channel saves you from having to normalize the normal vector in the pixel shader but if you are willing to live with some over perturbed normals you can do without....
though normal.z = normal.x + normal.y; gives a bold effect...
if the lights in the right direction
This appears to be correct after testing. As EarthQuake mentioned, it's a red/green only compression format "BC5_SNORM".