仰るとおりの問題です。HDR形式というより、
High Dynamic Rangeな「計算」をしている場合でも
（出力はLDRでも）生じる問題ですね。

確かに現時点ではcompositeの段階で処理するのが多いでしょうね。
特に、現実にはこのような高輝度のものにはglareが生じるので、
aliasingが単なるblurによって消されていたとしても
それほど違和感は無いのではないかと思います。
もしかしたら現実でも（写真や裸眼）glareを取り除くと
aliasingが見えるのかもしれません。

私はレンダリング画像をHDR形式で出力した事がないのですが(floating point形式ならあります)，
恐らく仰っているのは，非常に高輝度なサンプルポイントと，
その隣のそれほど明るくないサンプルポイントでのaliasingの事ではないかと思います．

この話はいつか記事として書きたいと思っていますが，現在のところ，
レンダラ側ではカバーできない問題(少なくとも実務では)で，専らcompositorの腕に頼っている状態です．

自然界の凄さを思い知りますね．:-)

前回のお話もそうですが、aliasingは本当に問題が残っていますね。
恥ずかしながら、僕も映像関係の会社にバイトに来るまでは
このような問題が残っている事を知りませんでした。

特に研究レベルでは色々と解決策が出ている事でも、
たぶん安定性やら既存のシステムへの組み込みの難しさなどから
商用レベルでは実装が全くされていない事が多いのに気がつきました。
そういう意味では、ray differentialsもその一例だと思います。

今回のお話は、mip-mappingのようなsurface上の
local filteringの指標があまりに適当に決められているせいで
発生している問題だと認識しています。個人的には、現在のレンダラーには
設定べきパラメータが多すぎるように思うので、今回の物も含めて
妙なパラメータがユーザーに一任されている現状は何とかしたいところです。
（まあこの問題と下のadaptive anti-aliasingについては単純に
　沢山rayを飛ばせるようになればいいわけですが…）

aliasingであと気になるのは、adaptive anti-aliasingの問題と、
最近普及してきたHDRでの出力とのanti-aliasingの共存です。

adaptive anti-aliasingはどうも分割の指標があいまいなので、
これがレンダラの個性としてモロに出てしまっている場合が多々見受けられます。
もちろん、必要無いと思う個性ですので、何か決定的な手法が出て欲しいと思っています。

あと、HDRでの出力とのanti-aliasingの共存については、例えば高輝度の面光源の
エッジが通常の方法ではanti-aliasingされないといった問題です。
「表示の時は」すべてピクセルの最高輝度にクリッピングされるので、
この状態ではanti-aliasingをした意味が全く無くなります。
何度か色々な人と話したのですけど、特にコレといったconsistentな解決策は
まだ無いような気がします。何かあったら教えていただけると幸いです。