Thanks for all the hints! Going to dig it deep. I will eventually disturb you annoyingly in forums :) @Troy Sobotka (sobotka)

ACES is really tangential; it’s just a simple series of transfer functions and a reference working space that is more or less BT.2020 for use with CGI / rendering / compositing.

@Troy Sobotka (sobotka) Thanks for the hints! Yes, I noticed a huge f-stop difference with some shots lately.
I think I am getting this scene referred conundrum now. Should we explore ACES as well? If you could kindly provide us some papers to read that would be great! Thanks.

@Fahad Hasan (cgvirus) The Nuke Merge nodes by default assume scene referred. OpenImageIO has the same swapped out formulas that Nuke uses. You will notice that things like Screen etc. will work with scene referred emissions, but is completely different from the A+B - (A*B) for example.

Hi, @Troy Sobotka (sobotka) thanks for the reply. Which app/s could be taken as a reference point for scene referred pipeline? I am interested to experiment it in deep. Thanks.

In T68926#788688, @Fahad Hasan (cgvirus) wrote:

In case someone interested in Natron/Nuke merge node math.
These are the implementation papers. I was able to create some mix nodes preserving luminance for production following these math. Hope it helps.

In case someone interested in Natron/Nuke merge node math.
These are the implementation papers. I was able to create some mix nodes preserving luminance for production following these math. Hope it helps.
https://natron.readthedocs.io/en/master/plugins/net.sf.openfx.MergePlugin.html

I can do full rendering again. I do not know why but if I render with a Tile Size equal to the final resolution all works normally.
The problem is that I can not enjoy my PCs with multiple GPUs.

The Render Result is shown by default in the 2.80 and 2.81. I don't think we should try to modify existing files. The settings means exactly to keep the user interface how it is, regardless if it was configured to show a render result somewhere or not.

This is a compiler bug in the ROCm drivers, which we don't support yet for Cycles. Many changes to the Cycles kernel were made since 2.79b.

Just want to mention T69562 here as well

It seems odd that it will still crash if using a custom border on the full resolution, though. Like Sorin asked, is Blender still trying to allocate that massive 18000 dimension even with the custom border in place? If it is, I feel like that would be a bug. Is it not?

1. Why it doesn't use the 30% you have set in render properties might be the primary bug here. Manually shrinking your initial dimensions to 2100x5400 works
2. It's odd why blender eats up resources and typically needs to be manually killed in this instance... still needs investigated I suppose
3. It may never be able to render at that 18000 dimension (100%) in any case. OpenGL GL_MAX_TEXTURE_SIZE limits on my AMD FirePro W2100 card is 16384 and I'm not aware of any implementation that allows higher than that.

ok i pressed f12, blender devoured the memory, blender didn't crash, but it was freeze and then i had to kill it myself.

@Sorin Vinatoru (sorinv) do you think it's related to the volumetrics in that file?

You may also want to hit F12. Using viewport rendering does not reproduce the error on my machine. Hitting F12 will crash Blender instantly.

I can fully reproduce this both on my windows computer (Nvidia GTX 980) and on our Linux servers (Nvidia K80). It may be a Nvidia only issue.

@Zachary Russ (KlariceV) are you sure this file is related to the problem shown?
I opened the blender file, it tells me that it is only 34 mb and windows 214 mb, eevee is slow for some reason, but I don't see memory leaks ...
my gpu is a radeon 7600 HD , uses blender workarounds, on windows 10

without a reference file, a video or other, how do you expect them to solve your problem ??

Forgot to mention, this is affecting Blender 2.80 official release.

This problem of random appearing/disappearing lines is due to freestyle's occlusion algorithm. Upcoming LANPR patch will include a smooth contour modifier that deals with freestyle's line problems on subdivided models. We may not be fixing freestyle at the moment and will be focused on LANPR.

I'm not a developer, but I have been wrestling with this problem a lot as I'm trying to use Freestyle lines for a client animation project using Eevee (I know, risky).

See:
https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

I am afraid this is rather considered as user feedback and not a bug. Try to reach out through https://devtalk.blender.org/
Also the time it spends on those is rather minimal.

Managed to do it, but it is a hacky solution, so hacky that I'm just gonna post it here instead of actually going through with a commit.

Sorry, it wasn't as smooth as I would hope it would be, so early 2.82 it should be in.
D5524: VSE: Disk cache is diff implementing mostly same functionality.

I would love to see this implemented in 2.8.1! The inability to render a scene makes it impossible to composite and edit all in the same blender workflow because you're not able to cache to disk your composite work through proxies. Otherwise you'll have to depend on a cache to ram which gets very expensive very fast.

2.81 release is scheduled for november as far as I remember, I'd bet they won't release a corrective 2.80a version but rather count on 2.81.

The fixes will be available in the net round of nightly builds and in 2.81.

Thank you Sergey. Is the 2.8 build updated after the final release last month with these fixes? Should I reinstall the 2.8 version? Or is this fix only in the 2.81 version?

In the Transform Preferences, Rendering Space should be labeled as Working Space as involving also the Compositor and Sequencer.

Correct.

The Image Editor needs a Viewing Transform option clearly visible since going back and forth to the Color Management panel is counterproductive.

Also correct. Just like the Save as Render flag, View as Render should make way for a more granular UI (Color Space is already there, but View Transform is not).
Note that the settings inside the Color Management panel don't even influence the view inside the Image Editor, as they only pertain to rendering and output.
View as Render is not only useless and badly named, it's also incorrect to use it. An image used as input should not have a transform used for viewing output slapped onto it. The checkbox should be replaced by a View Transform enum, also stored per image datablock.

LiftGammaGain should stay since many videos are composited, edited and graded in Rec.709, and many workflows involve this space but Lift should be fixed, it behaves as Lift+Power.

Just because your input material is Rec. 709, doesn't mean that it is display referred. On the contrary - the Blender compositor operates linearly, which is where Lift/Gamma/Gain breaks. The algorithm works on shadows, midtones and highlights, which are impossible to separate when using scene referred data.

Also LOG based controls should be included like a Contrast with a Pivot option (add Pivot to the contrast node?)
Shadow/Midtone/Highlight control wheels should be included for LOG based secondaries.

Again, compositing is a linear affair. The log controls you mention (including a shadows/midtones/highlights separation) are geared towards a grading workflow. Which should not happen on linear data, unless the tools use a log shaper if both input and output are stored linearly, like in an ACES workflow. But I digress.
It's beyond the scope of this task, but @Troy Sobotka (sobotka) did suggest a dedicated Grading Editor with correct controls for a log-based workflow. This editor would for example allow the colourist to work on NodeTrees linked to VSE strips, which is similar to e.g. DaVinci Resolve.
That Pivot option, however, is something that could very well be added to colour manipulation nodes already present in Blender, like Brightness/Contrast, but also Slope/Offset/Power.

A LUT node to apply different luts not only for artistic but also technical transforms, tonemappers, etc.

LUT nodes, enums for every node, .. all ways to prep data more adequately for the nodes they're about to go through.

Does it mean it may still crashes under certain circumstances?