Hotfix 3.2.1
Unfortunately not, this only works in the viewport.
I tried adding a Bake feature but this is also not possible because the Auto Exposure won’t work correctly with animation playback. You can only set Keys at certain frames of your animation.
Why wouldn’t the baking feature work though? Couldn’t it just take its time and figure out the exposure for each frame and key them in the color management on its own? Then turn off auto exposure update afterwards (because the exposure value should have already been keyframed), and the playback should work since it’s in the Blender color management settings.
The only problem I can think of would just how to make the keyframes to be per camera, my idea would just to use Photographer as a collector for different cameras’ associated sets of exposure keyframes, and switch out the keyframes in the color management when switching cameras. Well… I don’t know coding and how blender python works, nor how Photographer works, but here are some ideas that I think might be helpful. Auto Exposure would be a little less useful if it is not animatable, and I expected more of this feature than just that.
Sorry, I chose my words poorly. When I said “it was not possible”, I meant I wasn’t able to get it to work with the current implementation.
This is exactly what I tried. The problem is that the playback was getting stuck on some frames and didn’t play all of them.
I’ll keep testing other options, but I am not a programmer and don’t have the knowledge required to fix the quirks of the viewport draw handler and other depsgraph update issues.
This isn’t a problem, Photographer already takes care of that.
Thanks for the clarification, understand now.
Short demo of the new 3.2 features:
I have a question, is CPU or GPU the auto exposure depended on? The auto exposure in my computer is very slow in Cycles, but it looks just as fast as Eevee in your video, therefore I want to ask.
Both. Sampling is done on the GPU, averaging and the rest on CPU.
Current implementation is pretty taxing on the hardware and might struggle on old computers, I’ll keep looking at ways to optimize it but I’m not sure if anything can be done faster with the OpenGL wrapper.
Small update for LuxCore users, no need to update if you don’t use it.
3.2.2:
I’m using 3.2.1 and i found, that using Clamping, both Direct and Indirect Light make render look not enough contrast and looking dull. Only setting Clamping to ZERO make everything works fine.
Are You fimiliar with this issue?
PS. And if there any one could add histogram or live view histogram… that would be WOOW
Clamping at 0 means it’s turned off, so you will get the most accurate luminance, at the cost of some fireflies. If your renders get dull with clamping, you are values that are too low. I would recommend to not clamp the direct lighting as it is rarely the cause of fireflies, or use very high values. Indirect clamping can be much lower, like 2 or 3. It all depends on the scene.
In case you didn’t know, they exist in the Image view under the Scopes panel, but not in the live view unfortunately.
THANK YOU !!!
for both answers, it helps a lot.
I always used clamping in interiors renders, but i will have to try them without clamping to see difference. Direct Clamping can be really turn off. But indirect … i’ll try and i’ll give feedback
Live view would be awesome feTURE 
Actually, I don’t want a overwhelmed photographer. There are already problems with the dreamteam Luxcore, photographer and Lumiere. Where a back and forth workflow destroys the light setting. More stability than features make more sense to me.
Version 3.3.0 is out:
In a perfect world, we would all gather forces to make the best rendering add-on possible 
I know it’s the annoying part of the Blender add-on ecosystem, I never know which UV add-on to use, they all have useful features but all lack a feature that the other has.
I don’t use Lumiere unfortunately so I haven’t encountered the issues you are talking about. For what its worth, Photographer will enter a more stable development phase from now on.
But then blender would be colorless and boring. The countless different addons are in the end what makes blender what it is.
I’m using six right now but I think I need another one. 
I do not know exactly what it is due to (which addon).
If I set the light in cycles and switch to Luxcore, everything is fine, but when I return to the cycles, the light outshines (apply Photographer settings dosen’t help). So straight ahead everything is fine.
I like that. There are enough features. I see presets and comfort in the near future of 3d.
Keep up the good work. 
Could it be related to this one?
Known limitation: Do not use the Power or Irradiance units if you want to be able to switch your scene between Cycles/EEVEE and LuxCore . Use any other unit (including Advanced Power) to make sure the conversion is possible using the Apply Photographer settings button or new Warning buttons.
That automatic tilt is awesome!
No, that’s not it. But it looks like Lumiere isn’t really going for it. If I just stay in the light panel of blender, it goes as expected. But like I said before: If you set everything in cycles, you only need the light groups in Luxcore for fine tuning during rendering.
An update on the Optix Denoiser’s exposure problem, here is the reply I got:
That’s just the nature of AI denoising. The HDR denoiser that comes with OptiX was trained for a specific usecase (AI is only ever as good as the data that was used to train it), which is HDR images with color data between 0-10’000 that on average is not close to zero (see also https://raytracing-docs.nvidia.com/optix7/guide/index.html#ai_denoiser#nvidia-ai-denoiser).
In this particular case this contract cannot be abhold, since the scene is very very dark and therefore values are very close to zero (it’s only later after tonemapping that the final image gets scaled up using the exposure value). The AI is therefore unable to produce a good output.This could only be solved by running the denoiser on the LDR image after tonemapping and exposure has been applied already. But that is handled by Blender and not Cycles (which is where the denoiser lives) and so is not possible with the current architecture. I’d put this in the Known Issue category.
I guess in low light high exposure condition, we could only use the new openimage viewport denoise in 2.90 instead of the optix one then.
