Nevertheless, taking the average of 2x2 neighbouring pixels by 1 bilinear lookup is a cheap but incorrect approximation.
If you just want the average it's perfectly fine.
It's common praxis to create a full mip-map pyramide to average the luminance for tonemapping. The required memory consumption converges to 1+1/3 times the original amount (determined by the original texture).
Also, bloom is a cheap approximation to light scattering in the lenses of the camera or alternatively the human eye. If you want to do it somewhat physically plausible you have to add the blur before tonemapping to the _full_ HDR scene, without any bright pass - the amount of scattering is not influenced by the amount of photons, of course.
Regarding gamma correction you have to differentiate between perceptual and photometrical linearity. If you output a gamma-corrected mathematical linear gradient it will not appear linear to you which is due to the gradient being kinda photometrical linear and the human perception of brightness is in it's nature logarithmic. The original gradient without gamma correction appears much more perceptual linear.
The conversion from and to CIE Lab is rather costly (I would sooner suggest YCrCb), but if you are working with LDR RTs you can also convert back to gamma space befor writing to the target and back to linear when you are reading from the target in a later pass. Doesn't work with alpha blending, though. Also you can't use the bilinear fetch anymore.
[...]to divide the coords by 2. I don't know if this is a bug or intended, but you have to do this.
Year, this is horribly annoying.
