I understand what you're saying and agree to an extent. My concern is really that a "bad" tone mapping operator could screw up texture "anti-aliasing" by introducing higher frequencies than those that were band-limited in the pre-filtering process.Texture filtering and mipmapping is only concerned with producing a correct HDR image. What happens to that image later on is irrelevant to how you produce the correct HDR image.
[...]
Then you can of course tonemap it to garbage if you like, but so can you do with any HDR photo too.
For instance consider a tone mapping operator that is a step function. Applying this to the HDR image will naturally produce aliasing due to infinite spatial frequencies. While this is certainly a "garbage" tone mapping function, this is kind of what I mean by an "aggressive" function... exponentials will approach this with high exposures for instance.
So my point is that if we consider the ideal to be super-sampling (doing everything, tone mapping the super-sampled buffer, then finally down-sampling the resulting post-tone-mapped image), tone mapping is still in the wrong place in the process... i.e. it will not give the same result and indeed can introduce new spatial frequency content into the image.
Anyways I'm not 100% sure of my thinking here (just brainstorming) and I'm pretty sure that for most "reasonable" tone mapping functions there won't be a big problem as I stated earlier.
That said, it does seem to me like a poor tone mapping function could spell aliasing hell onto the underlying image. I guess Humus you're saying that that's purely a problem with the tone mapping function and that's fine, but it doesn't change the underlying warnings about highly non-linear tone mapping functions.
Now of course you can also argue that geometry already introduces infinite frequencies into the image, although indeed MSAA is designed to mitigate that somewhat In the same way that putting tone mapping in the "wrong spot" relative to MSAA can cause problems with high contrast regions and non-linear tone mapping, so can putting it in the wrong place with respect to texture filtering (consider rendering black and white checkerboard *geometry* vs. *texture*).
Again, I'm not sure that it's a huge issue in practice as you see extremely brightly, contrasting lit textures (maybe snow?) less often then objects rendered against the sky. Similarly however I don't see any edge aliasing problems in the demo - even with normal MSAA resolve - except objects against the bright sky. In any cases where the pre MSAA resolve tone map would make a difference with one piece of geometry overlayed on another, I'm pretty sure that a pre-texture-filter tone map would make the equivalent difference.
Anyways just food for thought...