Post Processing (e.g. Denoising)

This is where I've settled these:

on Frame or on Renderer?

On the renderer, as it's not really about interacting with the frame itself (specifying buffer mapped types for channels, size, high-level rendering ops) but rather how the pixels are rendered. I see the distinction of something running in world space (i.e. rays, raster pipeline, etc.) vs. screen space (tone mapping, denoising, etc.) as only relevant to the implementation. Unless there's an argument to be made about the frame having some uniquely needed information from the application, I think it's really under the responsibility of the renderer itself -- this is especially true for renderers that may have image-space operations that do not make sense, such as denoisers not being relevant for non-stochastic rendering algorithms.

when are PPs run? after renderFrame, or rather at mapFrame? implementation free to choose?

I think it needs to be "implementations are free to choose", as this isn't something the application needs to prescribe. If the application does need to have a say in image-space operations, they should just do it themselves. The value of putting it behind the API is because there are unique advantages that implementors can do based on their implementation choices -- prescribing too much in the spec artificially limits this.

change PPs without re-rendering (e.g. denoiser on/off, tonemapper exposure, ...)

This is again an implementation choice, as accumulation reset is entirely an implementation detail.

finer control on syncing (e.g. via WaitMask or extended frameCompletionCallback)?

I could see there being other wait mask values that could be injected here, but until someone actually creates demand for it in a real application, I wouldn't want to specify it just yet. It's not hard to add, but it's not a feature that I think makes-or-breaks using ANARI or not, so I wouldn't want to throw it in "just because".

KhronosGroup / ANARI-Docs

Post Processing (e.g. Denoising) #136