You don't generally put HDR colours into a gbuffer.

Why not?

edit2- because I remember reading that in a 'true' HDR pipeline even the textures are in an HDR format.

Anything to do with lighting, such as a cubemap or something else you are doing for direct/indirect lighting should, in some way, take HDR into account. But textures, or rather albedo, doesn't as it only takes into account the colorspace you're working in. Which right now is SRGB, though hypothetically one could prepare for DCI/REC 2020 if one wanted to.

Regardless, HDR is for lighting your scene into a higher range than your colorspace/spec can go, then tonemapping/etc. back down into the output range. Theoretically, if we were working in some crazy future colorspace/spec where we had output of a hundred thousand nits instead of the SRGB output of 100 nits, we wouldn't need "HDR" because the output spec would be enough in and of itself to display whatever range of brightnesses we wanted.

I'm using a GBuffer of type RGBA16F, normals and other informations are stored directly without encoding.

A single byte per component is perfectly sufficient for normals, you just need to not approach it as a 1 byte floating point conversion, use the raw byte and perform rather scale multiplication from 0,255 to -1.0,1.0, or use fixed point format if you are sure it performs well.

but 16 bit precision for depth position of pixel may be not enough, it is still less then real depth which will be at least 24 bit, and that can lead to random artifacts when moving. I have calibrated my Gbuffers to be a multiple render target, such as 4x8bit for color, 4x8bit for normals and specular sample, 1x32F for position.

Check out the gif I posted earlier -- all 8bit-component encodings have really obvious banding for mirror-like reflections, except for the Crytek BFN encoding.

Hmm, but it seems to me that the band has not much to do with light factor (is it a reflection enviroment?), it can be some special condition, shader +large mapping+ filtering etc. all together.

From my experience, byte per channel is perfectly satisfying for shade of light (not only tangent space normals), undistinguishable from more precise values, even in large zooms. I in the end have even the source normals defined like that in very normal maps.

You can use a 32F depth-stencil target directly, instead of doubling up by also storing depth in the gbuffer.

I rather attached another target, in my case it would under perform my situation, using depth/stencil as input to shaders at some stages.

So essentially a huge range of values are totally useless, thus limiting the effective precision of your normal storage.

Yes, the cube/sphere precision distribution when a linear scale is used, I sticked to linear straight scale though, quality and definition is great and the encoding is not that computationaly cheap though.