Alembic Camera Properties: Gold Candidate

[Francois Chardavoine]

Hi all -

Thanks for the feedback and comments on the property set that should define an Alembic camera. This is obviously something everyone feels passionate about, and every facility and 3rd party software tends to express cameras in slightly different ways. After a first round of discussion, here's what we feel the camera model will be.

The spirit is to stay 'simple', but not so simple that useful (and commonly understood) information is lost in the process.

First, some general comments to specifically address some of the feedback you've provided:
- aperture dimensions, offsets and focalLength are used as the core (instead of fov and screenWindow) since it is a common language for both CG and physical cameras, as well as most 3rd party applications
- the camera will provide the low-level getFov()/getScreenWindow() calls regardless of what information is actually stored
- all properties will use a single common unit (mm), so no need to have the unit be part of the property (the docs will clearly establish what unit is expected)
- we assume a horizontal 'filmFit' (and no longer consider it a first-class property)
- ortho cameras would exist as their own separate kind of camera (with an 'orthoWidth' defined)

Now for the meat of it (without units, default values or descriptions, to keep it easy to read):

Core Properties:

- focalLength
- horizontalAperture/verticalAperture dimensions
- horizontalFilmOffset/verticalFilmOffset
- lenseSqueezeRatio: to properly handle anamorphic, among other things.

- a 2D transform stack (translate/scale only) for expressing additional 2D translate/scale filmback operations (see below)

- overscan: stored as 4 percentage values for independent left/right/top/bottom values (to support non-symmetrical overscan, which we've come across)

- fStop
- focusDistance

- shutterOpen/shutterClose: these would be frame-relative values, expressed in seconds (to be consistent with the rest of the Alembic format)

- near/far clipping planes

2D filmBack Transform stack

A stack of named 2D transforms (translate/scale only) will be provided for expressing additional arbitrary 2D repos/scale operations on the filmBack. This should provide full flexibility, without compromising the camera definition by explicitly adding too many properties that may be very application-specific.

Additionally, since each transform in the stack could be named, certain stack configurations could automatically be recognized and restored when the application supports it. This means something like maya's postScale, vertical-filmFit settings, etc. can end up in the stack and be restored when possible upon reloading an Alembic file.

This also guarantees the original aperture values stay unchanged and true to their source (as opposed to having to modify aperture values "on the way out" of applications to bake down application-specific 2d operations).

Note that the overscan values are not a part of this transform stack, and remain separate, since they are important values to pass through to a back-end rendering framework in order to preserve the distinction between data-window (with overscan) and display-window (without). From a screen-window calculation point of view, the transform stack would be fully applied first, and overscan is applied last.

What now?

Let us know if any of this raises a red flag for you, since we'd like to get started on the implementation as soon as possible.

Thanks again for all the contributions, and everyone's patience in dealing with the process -
Francois.

[Steven Caron]

is this like pixel aspect ratio? i can achieve non square pixel values
with this?

s

On Mar 18, 6:47 pm, Francois Chardavoine <chard...@imageworks.com>
wrote:

[Francois Chardavoine]

Partially - this amounts to a horizontal scale factor applied to the
filmBack. The camera itself has no notion of resolution (which is
something that would be specified in a rendering application).
F.

Steven Caron wrote, On 03/25/11 16:49:

[LaszloSebo]

This looks pretty good. Would stereo cameras be supported natively, or
is the assumption that 2 independent cameras should be used instead?


sl

On Mar 18, 6:47 pm, Francois Chardavoine <chard...@imageworks.com>
wrote:

> Hi all -
> Thanks for the feedback and comments on the property set that should define an Alembic camera. This is obviously something everyone feels passionate about, and every facility and 3rd party software tends to express cameras in slightly different ways. After a first round of discussion, here's what we feel the camera model will be.
> The spirit is to stay 'simple', but not so simple that useful (and commonly understood) information is lost in the process.
> First, some general comments to specifically address some of the feedback you've provided:
> - aperture dimensions, offsets and focalLength are used as the core (instead of fov and screenWindow) since it is a common language for both CG and physical cameras, as well as most 3rd party applications
> - the camera will provide the low-level getFov()/getScreenWindow() calls regardless of what information is actually stored
> - all properties will use a single common unit (mm), so no need to have the unit be part of the property (the docs will clearly establish what unit is expected)
> - we assume a horizontal 'filmFit' (and no longer consider it a first-class property)
> - ortho cameras would exist as their own separate kind of camera (with an 'orthoWidth' defined)
> Now for the meat of it (without units, default values or descriptions, to keep it easy to read):Core Properties:
> - focalLength
> - horizontalAperture/verticalAperture dimensions
> - horizontalFilmOffset/verticalFilmOffset
> - lenseSqueezeRatio: to properly handle anamorphic, among other things.
> - a 2D transform stack (translate/scale only) for expressing additional 2D translate/scale filmback operations (see below)
> - overscan: stored as 4 percentage values for independent left/right/top/bottom values (to support non-symmetrical overscan, which we've come across)
> - fStop
> - focusDistance
> - shutterOpen/shutterClose: these would be frame-relative values, expressed in seconds (to be consistent with the rest of the Alembic format)

> - near/far clipping planes2D filmBack Transform stack

> A stack of named 2D transforms (translate/scale only) will be provided for expressing additional arbitrary 2D repos/scale operations on the filmBack. This should provide full flexibility, without compromising the camera definition by explicitly adding too many properties that may be very application-specific.
> Additionally, since each transform in the stack could be named, certain stack configurations could automatically be recognized and restored when the application supports it. This means something like maya's postScale, vertical-filmFit settings, etc. can end up in the stack and be restored when possible upon reloading an Alembic file.
> This also guarantees the original aperture values stay unchanged and true to their source (as opposed to having to modify aperture values "on the way out" of applications to bake down application-specific 2d operations).

> Note that the overscan values are not a part of this transform stack, and remain separate, since they are important values to pass through to a back-end rendering framework in order to preserve the distinction between data-window (with overscan) and display-window (without). From a screen-window calculation point of view, the transform stack would be fully applied first, and overscan is applied last.What now?

[Rob Bredow]

After a lot of discussion, it seems like there is not a clear enough
consensus for how a single native stereo camera rig should be
represented. Once you get into multiple stereo rigs per shot, separate
cameras for different objects in the scene (etc), it gets pretty hard
to nail down cleanly (at least today). I think that's appropriate
given the amount of innovation happening in the space.

So, for version 1.0, the proposal is that stereo cameras would be
handled with 2 independent cameras.

Rob

[LaszloSebo]

Thanks Rob. I think that was a good decision to be honest.