Per-Camera Format (aspect ratio and resolution) & File Settings [Proposal]

[dfelinto]

Per-Camera Format

At the moment there is no convenient way to render multiple cameras for a single scene with different resolution or aspect ratio.

The existing workflow is to link the scene multiple times and have a different camera defined on each of them. Or change the scene resolution prior to each of the camera renders.

Simple Approach

The simples way to get this working is by implementing for each camera an option to “Follow Scene” or “Override” its settings.

The settings Render Region, Crop to Render Region and Frame Rate stay only configurable on the scene level.

In the viewport it would be nice to have a display option to show the camera aspect ratio/resolution in relation to the scene one (like a viewfinder).

Letterboxing

When rendering a scene with multiple cameras (using markers bind to the cameras) different things will need to happen based on the output:

• If rendering individual frames (e.g., JPG or OpenEXR files) each frame will use the respective camera resolution.
• If rendering to a movie file (e.g., mp4) the scene resolution will be used by the container, and the individual cameras will be cropped or letterboxed.

For full control of the movie file use-case users are adviced to use the Video Sequence Editor. There you can add individual scene strips for each of the cameras, and control the strip scaling individually (or arrange them in mosaics, picture-in-picture, …).

Future: File Settings

For the Story Tools project, the plan is to shift some of the existing Output (and scene) settings around to avoid duplication between the Scene and the Sequencer.

The current proposal is to move some of those changes to the File level:

• Format, output, stereo, units and color management go to File Settings.
• Frame range should be present in Sequencer and Scene.

This means that the file settings becomes the source of truth for sequences (timelines) and scenes. If a scene needs a custom aspect ratio it can overridden in the Camera format level.

---

There will be a new tab “File” for the file specific settings:

The existing (scene) Output tab gets merged into the Scene tab. Note that Units got removed from it (it moved to the File tab):

The Sequence tab will only be visible when a Sequence data-block is present. It expose the Sequence Frame Range (also visible on the animation playback footer):

In this case the camera option is to “Follow File” instead of “Follow Scene”:

Caveats

This proposal tries to keep things simple. Which means some setups currently possible are more tricky to accomplish. The more obvious one is to set different “Outputs” for different scenes.

The proposed solution for this is to:

• Render each scene individually, adjust the File output in between renders; or
• Use the Blender Variable for the scene name in the output path; or
• Combine all the scenes in a single Sequence, and render them as individual images; or
• Use File Output nodes in the scenes compositor.

---

Feedback

Pablo and I worked together on this design, and I have discussed it already with some people. I even posted it already as a design document.

That said, this would break backward compatibility in some cases, and I would still like to hear from people that may have their workflow affected. And if the workarounds proposed on the caveats would suffice.

In particular people that rely at the moment on the per-scene/sequence output paths.

[Jean-Silas]

Long-term, do you see Blender going in the Cameras-as-Assets direction, or leaning more on camera presets?

Part of me would love to see this broken down into a bunch of granular datablocks that could be linked individually and treated as assets, but that’s more a reflection of what I’m used to than what might be best for Blender.

[brecht]

What is the use case for per camera format? I guess it would be e.g. production visualization or character sheets, where you want to render the product or character from different angles.

In that case each camera angle would be saved to a different file. Is that something we should try to handle, or just leave it to the user?

In some way involving stereoscopy/multiview would be interesting here, since you can have a different suffix in the file name then. And if the resolution was specified there it would be consistent across an animation. But that may be stretching the intended use too much.

---

Is sharing settings across multiple shots a goal of the per camera format? Probably not?

The camera settings will not be enough, and then we’d need a scene or render settings datablock. There is also the idea of project variables to address this. And then there is the mechanism in the compositor to inherit resolution from the parent scene. Not sure if that also exists in the sequencer or will be part of the sequence datablock.

It gets pretty confusing to figure out which actual resolution will be used. It might be good to consider how we can communicate that more clearly, taking into account all these different mechanisms.

---

@dfelinto

In the viewport it would be nice to have a display option to show the camera aspect ratio/resolution in relation to the scene one (like a viewfinder).

What would this be used for? This makes me think I might be missing a use case.

---

From the Sequence datablock design task I got the impression the resolution would be stored in that datablock, not at the file level? We store very little at the file level currently, and anything there can not be linked. I’m also not sure how this would be compatible with the idea of having multiple sequence datablocks in a blend file.

[Bobo_The_Imp]

@brecht

The camera settings will not be enough, and then we’d need a scene or render settings datablock.

Double agreeing with this. I want to change my light path sample count and even color management per render layer etc. Might be a pipe dream but I really hope in the future Blender can have a procedural scene management system like Solaris or Katana.

[nickberckley]

One other usecase I have (I use Photographer add-on) is rendering same thing with different resolutions for different social media platforms - square for Instagram post, portrait for story, etc.

Photographer works same way as proposed here, and I’m very happy with it.

[dfelinto]

@brecht:

Use cases

@brecht

What is the use case for this? I guess it would be e.g. production visualization or character sheets, where you want to render the product or character from different angles.

Some of the use cases:

• Archiviz (simulating different real cameras in the same file).
• Picture-in-picture (to be composed in comp or sequence, or externally).
• Asset file (square camera for thumbnail, landscape for promo shot).
• Character sheet.
• Product visualization

All in all the idea is to provide a better solution than creating multiple scenes only to have a unique camera with a different aspect ration/resolution.

Multi-camera rendering

@brecht

In that case each camera angle would be saved to a different file. (…) In some way involving stereoscopy/multiview would be interesting here, since you can have a different suffix in the file name then.

Multi-view would definitively work. If we promote as the main way then may be good to make stereo a sub-case of multi-view, instead of the other way around (as it is now).

I was trying to think if a {camera_name} Blender variable could work too. But in this case we don’t have a way to automatically render all the individual cameras. It would require an additional command-line argument like --all-cameras.

@brecht

@dfelinto

In the viewport it would be nice to have a display option to show the camera aspect ratio/resolution in relation to the scene one (like a viewfinder).

What would this be used for? This makes me think I might be missing a use case.

For this in particular is the idea of having different formats in the same scene (e.g., square for social media, and landscape for print).

Project variables/settings

@brecht

There is also the idea of project variables to address this. And then there is the mechanism in the compositor to inherit resolution from the parent scene. Not sure if that also exists in the sequencer or will be part of the sequence datablock.

It gets pretty confusing to figure out which actual resolution will be used. It might be good to consider how we can communicate that more clearly, taking into account all these different mechanisms.

I want to comment on Project adding yet more complexity to this.

We could decide to promote some of those settings (probably all of the “File Settings”) as project settings. However, it may be simpler to have users use Project Variables and handle the complexity on their pipeline (by manually using {RESOLUTION_X} when initializing their production files.

Otherwise we are approaching USD levels of complexity where we have to stack:

• Project / Sequence / Scene / Camera to get the aspect ration.

With the current design I was wondering if we could have this as simple as possible. Having those settings defined in a single place, eventually overridden only by the end point (camera).

---

Just to illustrate how things get quickly overwhelming, this is what we get if we allow override on the scene and sequence levels:

[brecht]

Yes, all these levels of overrides get pretty tricky. If most things can be at the file level, with path templates, camera level resolution and file output node for finer control it might provide enough control.

Where it’s more fuzzy to me is when working with multiple blend files. Currently the behavior is that compositor render layer nodes get the resolution from the parent scene, while sequence scene strips keep the child scene resolution.

If you link a scene from another file in the sequencer, would the file resolution come along? I guess it can be made to work technically, storing it in the Library datablock. There’s not really a precedent for this type of behavior in linking, but may be ok.

---

For the distribution of settings between files and scenes, I think the proposal needs some tweaks.

Metadata I think belongs together with the Output panel at file level? Maybe there is a use case for text that changes per scene, but mostly it would be consistent I think. And metadata for movie files can not change per frame anyway.

Post Processing panel needs to be split probably. Dither belongs together with Output. Sequencer toggle could disappear or move to the sequence datablock. Compositor toggle could stays at scene level, perhaps merged with “Use Nodes”.

Color Management is a bit fuzzy to me. It would make sense to have Display and HDR at the file level, along with future OpenColorIO configuration choice. However there are also use cases where you want to change the look, curves, white balance per shot, and it would not be right to use the same for the entire sequence.

There are two somewhat different use cases, putting together scenes that were already graded individually, and grading the sequence as a whole. In some way it would make sense to have those artistic color management settings both at the sequence datablock and scene level, and have them applied on top of each other. Not sure what the right way to handle the view transform is though, doesn’t make so much sense at two levels.

[Anthony_Gibbs]

@dfelinto

The existing (scene) Output tab gets merged into the Scene tab. Note that Units got removed from it (it moved to the File tab):

I maybe missing something but to me that doesn’t make a lot of sense moving Units to a File output tab.

The size/distance/measurement units that one uses for the overall scene setup have nothing really to do with File output. The only units that video and images use are pixels and that’s it. Which is already defined by the Resolution.

So is there a specific reason why Units is being moved out of the Scene tab?

[filedescriptor]

It’s not the “File Output” tab but just a “File” tab because the idea is to put file level properties there like output and e.g. units.

[Anthony_Gibbs]

OK, so that’s really all about the Blender file ‘output’ then, in which case what is format resolution, etc doing there, since that’s about render output.

The Units settings (things like Mass/Rotation/Temperature, etc) are very much in my mind a scene thing that just gets saved as part of the Blender file.

In fact it’s not even a whole of Blender file setting, since if you create a new scene in the same single Blender file, each scene can have different Unit settings. Not totally sure why one would do that, outside of just a whole new file, but still.

It’s not a file property, it’s a scene property. Mind you so is the Stereoscopy and Colour Management, etc. So I’m really not sure what the File tab is really for, since they aren’t file specific, they seem to all be scene specific.

[brecht]

Units make some sense at the Blend File level because location and distance values are stored in Object datablocks, which are shared across scenes.

Similarly the OpenColorIO configuration determines the colorspace of colors in Material datablocks shared across scenes. But I agree Color Management entirely at the Blend File may not be ideal, as explained in my previous comment.

Stereoscopy and Output are a quite opinionated choice though. Probably right for most cases but also some where it will not fit and you’d have to use multiple blend files where you didn’t before.

[Baardaap]

I just want to mention a usecase for per-camera resolution settings: Photogrammetry reconstructions.

I play around a lot with Meshroom, doing SFM and distortion correction and then using the resulting camera positions and undistorted images to hand model based on the photos. Currently when you have a 3d reconstruction with multiple cameras with different resolutions it’s impossible to import the reconstruction into blender with matching background images.

[ManuelGrad]

Another big use case is VFX: it’s not uncommon to have shot cameras with different resolutions.
When designing a CG environment you usually want all available shot cameras in your scene to check if your environment looks good in all cameras. Without per-cam resolution the aspect ratio might differ per cam so you would need to change the scene resolution every time you switch cameras in order to see correct framing – which frankly is ridiculous.

Another use case is that if resolution is a property of a cam, camera-projections and things like camera frustum culling setups get more straightforward, logical, and less time-consuming to build/change.

[avclubvids]

There have been many times when I wanted to render from multiple cameras from one Blend file. As @ManuelGrad says, this is common enough in VFX to not raise an eyebrow when it happens. My suggestion to maybe make things easier is to add render tokens to the file output settings so we can do things like this with outputs:

C:\renders$BLENDFILENAME$VIEWLAYER$CAMERA\myAwesomeRender_$CAMERA_$VERSION.exr

That’s a stupid example, but wildcarding paths like this would allow us to render multiple outputs from a single file path input. This might alleviate some of the concerns above about how the output of each camera could be managed.

[LudvikKoutny]

There are these types of override already present at places, such as color management:

I think that Follow Scene mode should simply hide all the details below, not gray them out. Right now, even users who do not user the overrides still pay for them by having to parse visual complexity of all the setting sections they don’t intend to use or deal with. The settings to be overriden should only be shown when the combo button is actually set to override.

This should allow to have override at more places without cluttering the UI for users that don’t need them. Those users will get only one additional UI element, which is acceptable tradeoff for the flexibility the per-camera image format adds.

Regarding this example:

I am curious about whether this was just for an illustration or as an actual suggestion. While I am aware that blender technically supports multiple scenes per file. I don’t think I’ve ever seen anyone actually utilize that, ever.

Multiple static cameras in scene of varying resolutions is very common requirement, especially for archviz. Having multiple scenes with unique output paths in single blend file is something I haven’t seen yet.

The reason I am pointing this out is that I think the overrides should only be added to places where many people really seem to need them, as opposed to randomly adding override sections in all the possible places where someone could possibly need them one day…

[dfelinto]

@LudvikKoutny

I think that Follow Scene mode should simply hide all the details below, not gray them out.

I talked about this with Pablo, yesterday I think. Technically you are correct, since in Blender UI paradigm enums are used to hide UI elements (and checkboxes to gray them out).

That said, while I wasn’t involved in the Color Management PR but I (we) I can see how for overrides things are different. You do want to see what is the setting that is being used (the scene one in your example), before you decide to override it or not.

[dfelinto]

@LudvikKoutny

I am curious about whether this was just for an illustration or as an actual suggestion. While I am aware that blender technically supports multiple scenes per file. I don’t think I’ve ever seen anyone actually utilize that, ever.

This was an early idea that was rulled out because it added too much complexity. So I pasted here to illustrate the counterpoint of the current proposal.

[dfelinto]

C:\renders$BLENDFILENAME$VIEWLAYER$CAMERA\myAwesomeRender_$CAMERA_$VERSION.exr

Besides the “version” part, everything seems possible (in the future) with Blender variables. An alternative to version is to have a variable for “NOW”.

What I wonder is, how do you imagine handling the rendering of all your cameras in this case? So far the only built-in feature we have that would make this easy is multi-view indeed (as mentioned by Brecht).

(for the records, the syntax for using Blender variables are a bit different than in your example)

[dfelinto]

@brecht

If you link a scene from another file in the sequencer, would the file resolution come along?

Definitively.

@brecht

For the distribution of settings between files and scenes, I think the proposal needs some tweaks.

I confess I didn’t spend that much time on each of those. So your suggestion is probably more sound.

All in all, this is definitively something we should look closer once we greenlight this design. I don’t think this makes or breaks the overall proposal.

[LudvikKoutny]

I do agree there is some utility to being able to see the values that you can override. The question is whether benefit of being able to see the values outweighs the permanent UI clutter. The rule is also not applied consistently, for example in file output node, the Follow Scene indeed hides the overriden settings:

Ideal scenario could be some system where the Override combo button would have some functionality to jump to the source of the the data to be overriden in the UI, but that’s too complex and blender isn’t built for that.

Maybe simpler solution could be some unified design rule, where override settings group is always its own panel which has the Override as bool toggle always right in the header, and is always collapsed by default, as blender supports panel toggles in headers:

So instead of Follow Scene/Override combo button, the override group would be a panel (or sub-panel) called “Override Color Management” with the checkbox in the panel header.

An example mockup:

And how clean it’d look if these panels are closed by default: