Relative space #80562

New Issue

Monique Dewanchand · 2020-09-07T14:34:28+02:00

2020-09-07 14:34:28 +02:00

Currently when users change the render size percentage of a scene the compositor tree needs to be adjusted as a lot of composite nodes aren’t relative. This has a lot of impact on performance of the user and the system. This is part of https://developer.blender.org/T74491.

A solution can be to introduce a Pixel factor to any buffer in the compositor. The term Pixel Factor is not really correct, but I couldn’t come up with a better term. (suggestions are welcome).
The pixel factor is the scale factor between the used input buffer and the input buffer that would have been used when the render resolution percentage would have been set to 100%.

For render layers the pixel factor is the same as the render resolution percentage. For movie clips and images a pixel factor of 1 is used.

Nodes that use parameters in pixels could use this pixel factor to adjust its effect. Nodes that use multiple input buffers would select a pixel factor for the output buffer. This depends on the node, for example when mixing a render layer on a movie clip, the pixel factor closest to the pixel factor that would be used by the compositor node would be selected for the output buffer.

The compositor output node would scale the input buffers to match the scene render percentage.

There are nodes where the pixel factor won’t work:

  Glare Node: Iteration factor could be scaled, but could lead to different results.
  Filter Node: Uses a Convolution filter. When working on scaled down buffers this could lead to visual artifacts
  Despeckle: Uses arithmetic with the neighbour pixels. Might not have visual artifacts.

There is new compo implementation https://github.com/m-castilla/blender/tree/compositor-up but it seems that this branch doesn’t tackle this part of the ticket.

Questions:

  Is having a pixel factor the way to solve the problem?
  What should be done with the nodes that cannot work with a pixel factor?
  Should the Image/Movieclip pixel factor be dependent on the compositor output resolution? (Quality vs performance)

Currently when users change the render size percentage of a scene the compositor tree needs to be adjusted as a lot of composite nodes aren’t relative. This has a lot of impact on performance of the user and the system. This is part of https://developer.blender.org/T74491. A solution can be to introduce a Pixel factor to any buffer in the compositor. The term Pixel Factor is not really correct, but I couldn’t come up with a better term. (suggestions are welcome). The pixel factor is the scale factor between the used input buffer and the input buffer that would have been used when the render resolution percentage would have been set to 100%. For render layers the pixel factor is the same as the render resolution percentage. For movie clips and images a pixel factor of 1 is used. Nodes that use parameters in pixels could use this pixel factor to adjust its effect. Nodes that use multiple input buffers would select a pixel factor for the output buffer. This depends on the node, for example when mixing a render layer on a movie clip, the pixel factor closest to the pixel factor that would be used by the compositor node would be selected for the output buffer. The compositor output node would scale the input buffers to match the scene render percentage. There are nodes where the pixel factor won’t work: ``` Glare Node: Iteration factor could be scaled, but could lead to different results. Filter Node: Uses a Convolution filter. When working on scaled down buffers this could lead to visual artifacts Despeckle: Uses arithmetic with the neighbour pixels. Might not have visual artifacts. ``` There is new compo implementation https://github.com/m-castilla/blender/tree/compositor-up but it seems that this branch doesn’t tackle this part of the ticket. Questions: ``` Is having a pixel factor the way to solve the problem? What should be done with the nodes that cannot work with a pixel factor? Should the Image/Movieclip pixel factor be dependent on the compositor output resolution? (Quality vs performance)

Monique Dewanchand commented

2020-09-07 14:34:28 +02:00

Added subscribers: @monique, @semimetallic, @bent, @Mantissa, @MichaelHermann, @MrJoMo, @SeanKennedy, @JasonClarke, @BartekMoniewski, @3di, @laurelkeys, @Pipeliner, @MD.FahadHassan, @DarkKnight, @EAW, @BintangPratama, @frameshift, @LazyDodo, @brecht, @Jeroen-Bakker, @Sergey

Monique Dewanchand commented

2020-09-07 14:36:02 +02:00

response from @Sergey :

I assume the Pixel factor you’re referring to is a purely internal value. There is no reason for it to be exposed to the users: as far as artist is concerned thing should “just work”.

I do believe that for artists operating in pixel space is more natural. For example, blur of 16 pixels is more clear for them that blur of 0.0083 (which is 16 pixels normalized to FullHD resolution). Surely, sometimes it might be more clear to expose normalized transform (similar to Gimp’s scale where its possible to switch form pixel values to percentage), but to me introducing such “units” “toggles” is a separate topic.

The way I see it the mental model of nodes pretty much stays the same. The difference would be that the pixel values are in 100% render resolution space. So if one sets render resolution to 200% then the effective blur size becomes 32 pixels, and at 50% render resolution it becomes 8 pixels.

So in this terms the proposed Pixel factor seems to be aligned with the initial idea when #74491 was written down. Not sure why it should be per-buffer. To me it seems it should only be taken into account when the compositor tree is converted from bNode's to OperationNode's.

The Glare node has different issues: is single threaded. There should be another algorithm which will be multi-threaded. For the time being, having some half-decent approximate scaled result will be sufficient. Other nodes you mention here I think are expected to have possibly different pixel-to-pixel results (and you can’t scale down without artifacts in the current compositor anyway ;).

Are there any other “problematic” nodes?

The images/clips are to be perceived scaled according to the pixel factor, so that they work nicely for VFX shots.

response from @Sergey : I assume the Pixel factor you’re referring to is a purely internal value. There is no reason for it to be exposed to the users: as far as artist is concerned thing should “just work”. I do believe that for artists operating in pixel space is more natural. For example, blur of 16 pixels is more clear for them that blur of 0.0083 (which is 16 pixels normalized to FullHD resolution). Surely, sometimes it might be more clear to expose normalized transform (similar to Gimp’s scale where its possible to switch form pixel values to percentage), but to me introducing such “units” “toggles” is a separate topic. The way I see it the mental model of nodes pretty much stays the same. The difference would be that the pixel values are in 100% render resolution space. So if one sets render resolution to 200% then the effective blur size becomes 32 pixels, and at 50% render resolution it becomes 8 pixels. So in this terms the proposed Pixel factor seems to be aligned with the initial idea when #74491 was written down. Not sure why it should be per-buffer. To me it seems it should only be taken into account when the compositor tree is converted from bNode's to OperationNode's. The Glare node has different issues: is single threaded. There should be another algorithm which will be multi-threaded. For the time being, having some half-decent approximate scaled result will be sufficient. Other nodes you mention here I think are expected to have possibly different pixel-to-pixel results (and you can’t scale down without artifacts in the current compositor anyway ;). Are there any other “problematic” nodes? The images/clips are to be perceived scaled according to the pixel factor, so that they work nicely for VFX shots.

Monique Dewanchand commented

2020-09-07 14:43:41 +02:00

In repsonse to Sergey's comment:

Yes "pixel factor" is an internal value. Imho the user should only use the render resolution percentage.
Indeed, Pixel factor is not per buffer, but is set when nodes are converted to operations
For the time being I'll leave the glare node, filter and despeckle node as is. Re-implementing glare node should be done in a separate task. (Same for bilateral blur node which also doesn't seem correct).
Problematic nodes? There are some nodes that might need discussion. But let's tackle that one node at a time.

In repsonse to Sergey's comment: - Yes "pixel factor" is an internal value. Imho the user should only use the render resolution percentage. - Indeed, Pixel factor is not per buffer, but is set when nodes are converted to operations - For the time being I'll leave the glare node, filter and despeckle node as is. Re-implementing glare node should be done in a separate task. (Same for bilateral blur node which also doesn't seem correct). - Problematic nodes? There are some nodes that might need discussion. But let's tackle that one node at a time.

Sergey Sharybin commented

2020-09-07 14:56:51 +02:00

To me it seems we are in an agreement with how the system should work in this regard. Are there any open/loose ends of the design/discussion which needs to be covered prior to the implementation can start?

From the implementation side, to me it seems the natural step would be to implement the relative space for one node (and all related areas). Such approach will allow to verify we are on the same page, easily do any alternation to implementation if needed. What do you think?

To me it seems we are in an agreement with how the system should work in this regard. Are there any open/loose ends of the design/discussion which needs to be covered prior to the implementation can start? From the implementation side, to me it seems the natural step would be to implement the relative space for one node (and all related areas). Such approach will allow to verify we are on the same page, easily do any alternation to implementation if needed. What do you think?

Monique Dewanchand commented

2020-09-07 15:10:56 +02:00

Open/loose ends? not atm.
Agreed, I was planning to start with one node and deliver that as a patch. We can then discuss if the approach is okay or whether we need something else.

Open/loose ends? not atm. Agreed, I was planning to start with one node and deliver that as a patch. We can then discuss if the approach is okay or whether we need something else.

Aditia A. Pratama commented

2020-10-02 17:09:01 +02:00

Added subscriber: @AditiaA.Pratama

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Relative space #80562