I just discovered that rendering (Eevee) with F12 and with the menu command View>Viewport render Image gives two different results: the F12 render is 32bit unclamped image, while the latter is clamped, with all the ugly artefacts that this implies.
Now this is quite disappointing, since for quick test animations of heavy scenes Viewport Render is really really fast, and while the Viewport lets you see the nice unclamped Eevee result the “Viewport Render” looks totally different.
Is this a limitation? Or was it left clamped and forgotten?
Is there a purpose? Maybe it is fast because of this low color range result?
Would it be hard to let Blender output the fulll 32bit viewport image?
1 Like
I was niticing this right now, viewport render also brightends the image too much if you change the exposure up a little in the color management, so it gets totally unusable.
Maybe it’s legacy from old “OpenGL render”…
What I can’t understand is that in the viewport there’s no clamping at all, everything looks gorg-eevee-ous. Also you can playback it. In complex scene you get awful framerate ok, not real-time, but it’s still many times quicker than rendering by F12. So, the engine can calculate fast preview for the viewport, but Blender doesn’t take advantage of this speed when it comes to output to files.
Please fix this if it’s possible, it would be a huge help for time-constraints works.
I actually made a preview of a 30sec video in something more than an hour with full Eevee.
Viewport Render Image did the job in less than 10 minutes!
With viewport animations, EEVEE is only calculating and displaying one sample before moving on to the next frame. If you stop the animation, on any given frame, Blender will only then update the scene to whatever viewport sample setting you have entered for that file.
With F12 Blender is calculating every frame at the full sample settings.
Are you sure this applies to the clamping issue I’m describing?
This is a F12 Eevee render set at just 1 sample.
Notice upper left red dot sampling: every channel goes well beyond 12/13 luminosity value
This is its poor Viewport render brother:
see what I mean?
Not sure about the clamping or quality differences. I was just commenting on why the viewport can render animations quicker than F12.
Ah ok, but I think that also there’s something going on loading/reloading stuff, as cycles does for each frame, because even setting samples to 1 for regular F12 rendering leads to huge time difference anyway
I tested it and changing the samples number changes the time, it’s also obvious since you can render soft shadows with it so it defenitely takes samples into account.
@EAW
I found something interesting about rendering video vs rendering still images, turns images work better and might be video output what’s broken.
Thank you for pointing me there. At least now I know that the topic is on triaging. Hope it won’t get discarded with a “by design” label.
And at least you provided me a workaround: never delete 2.82 until the bug is over! 
I would alao look at (or double check that you’re) making sure you’re using filmic and that the Viewport has also optix enabled, if available on hardware and it’s now new in 2.83 as well. This issue is maybe related to the other differences in things like clipping planes which are different settings for viewport then the camera. Anyway exporting EXRs if Full with filmic logarithmic encoding allows one to properly process HDR’s potency properly to your output format so you should expect the viewport to be different then your final result in someways.
Pay attention to the values in the 2nd screenshot i posted above: it is not something related to color management. Sampling the raw pixels (red dot top-left) clearly shows the clamping occurring. All RGB values are at 1.000 (left side of status bar), then the filmic color transformation does its job setting them at 0.8072
Also: on 2.82 same file, no issue
1 Like
Disregard this below, I’m on a work computer that I don’t use quite as often and I forgot that I hadn’t updated to 2.83 on it yet. I’ll download and check… 
I’m not seeing this behavior. Not sure if I’m doing something differnetly, but the colors of my viewport render (going to view-> render viewport) are exactly the same for an F12 Eevee render. Changing the color management changes the color of both renders, as expected.
I just took the default scene, added some extra lamps so that highlights are blowing out and rendered in both and got identical results.
Is this after you save the file? What’s your OS and hardware?
I’m on PC, Windows 10, RTX 2070.
Something I mentioned in the bug report page, but using false color helps debugging if it’s working or not properly, 2.82 had problems with video output already.
windows10 rtx 2080ti blender 2.90 and 2.83
I read somewhere on developers.blender.org (where bug reports for this are growing) that this change has some motivation.
It is also said that the clipping should depend on the output format, so choosing a 16 or 32 bit format should solve the issue, but it doesn’t. Oh well maybe I just misunderstood
I have the same problem, and I tested the version 2.80 and this works fine, Tthe problem is with the last version of blender 2.83.2 for me.
This problem is still present even on 2.91 daily builds and even outside of the viewport render when saving exr files, this is a important issue.
1 Like
hi i discover this issue too both in 2.81a and 2.9, blender would be 10 time faster with viewport render, hope it will soon be fixed, here are the difference between, F12 and viewport render (filmic for colormanagement)!
It’s still not solved. I can’t understand why. It used to work some versions ago