So the foolproof way to store information about emission would be to dedicate a full RGB data set to do the job, but this is seemingly wasteful, and squeezing everything into a single buffer channel is desirable and indeed a common practice. The thing is that there doesn't seem to be one de facto standard technique to achieve this. A commonly suggested solution is to perform a simple glow * albedo multiplication, but it's not difficult to imagine instances where this strict interdependence would become an impenetrable barrier. What are some other ideas?
Handling emission in a G-buffer
I use the "metalness" parameterisation already, where you store a single color which is used to calculate the albedo and the specular reflectance colors, based on the metalness value. So yeah, I did what you mentioned and stored a single emission value (as log luminance) and multiplied that with color to get the emissivity color.
Most of the time this is completely fine for me - if something is emitting light, it's probably diffusing/reflecting light with the same color. e.g. A glowing red sign is often just red plastic over a light - it should emit red light and also have a red albedo.
The situations where I've found trouble are things like TV screens that are in direct sunlight. The emissive color should show the content of the TV show that's playing, but the albedo should be very dark grey. Normally this isn't at all noticeable though, and I don't actually have any TV's in my game, so I put up with it.
. 22 Racing Series .
I think, if you'd use premultiplied alpha you could use 1 color to indicate both diffuse and emissive.
https://blogs.msdn.microsoft.com/shawnhar/2009/11/06/premultiplied-alpha/