Declaring scene frame rate for interoperability

[Sybren A. Stüvel]

Hello group,

TL;DR: would it be possible to define a standard Alembic archive metadata property that declares the scene frame rate?

My question comes from the desire for interoperability. Alembic uses time to denote, well, time, whereas other file formats often refer to frame numbers. Converting between the two is trivial if the frame rate is known. Currently this is a big "if", and not knowing the frame rate results in interoperability issues like described in https://github.com/PixarAnimationStudios/USD/issues/940.

Many importers seem to have a hard-coded assumption that an Alembic file is to be interpreted as 24 FPS, and subsequently perform bad interpolation. See https://developer.blender.org/T55288 where the reporter tried loading a 30 FPS file into various applications.

The root of those issues is that Alembic refers to scene time (without declaring a frame rate), and other file formats and applications refer to scene frames (also without declaring a frame rate), making it impossible to unambiguously convert between the two. Including the scene frame rate in the Alembic file would make it easier to handle the files, as then things like "30 FPS @ 4 samples per frame" and "120 FPS @ 1 sample per frame" can be distinguished. It would also make it easier for people (read: me) to convince other people that hard-coding 24 FPS is unnecessary.

Would you be open to add such a property to the standard?

-- 
Sybren A. Stüvel

https://stuvelfoto.nl/
https://stuvel.eu/

[Dorian Fevrier]

Hi,

I think you’ve properly described the problem:

1) Alembic is FPS agnostic. You have no guarantee about sample position in time and it is technically possible to have one single Alembic file having multiple time sample frequency objects in one single file.

2) Some softwares are not so they assume a random FPS (24) and give bad interpolation.

I would say it’s up to the importer to interpolate values correctly depending on what the FPS is in current scene. If your alembic is 24 and your project is 25, one second will be 25 frame. Of course you will have sampling problems but it’s because your samples doesn’t match the final scene.

If you want the importer to be more flexible, you could override what FPS will be use for interplation (to slow down or accelerate animation): With such, 24 FPS Alembic will long 24 frames, even on a 60 FPS shot (Alembic is accelerated).

IMHO, having a metadata for FPS would mostly confuse importer writers even more as they will be tempted to assume a particulare sampling rate (something Alembic can't garantee).

If archive metadata is 24 FPS and merged objects from different sources are 60, how the metadata should react ? How the importer should react if archive metadata states a particular frame rate but some objects don’t follow this rule.

I saw USD hardcode 24 FPS. Wouldn’t it be more efficient to consider Alembic archive follow the current FPS. If it doesn’t, fix your pipeline. This combined with a "retime FPS" option on the importer to states how the Alembic time must be "converted to frames".

Hope it helps.

--
You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/alembic-discussion/b71a9873-126e-22a7-9c49-78a7a404d150%40stuvel.eu.

[Spiff]

Hi Dorian,
As you saw in the referenced Issue, this came up in the context of dynamically translating abc files to usd form. Like abc, usd can also host arbitrary attribute timesamplings in a single file, but also declares a *single* mapping of the ordinates in the file (which we’re loosely referring to as “frames” here) to seconds, _timeCodesPerSecond_. This not only allows us to preserve numerical precision when operating in very small or very large time domains, but also makes it possible to disambiguate the kinds of scenarios Sybren mentioned.

In fact we can also do the kind of remapping you describe “on the fly”, since anytime you reference an abc (or other) file, you can scale and offset the time defined in the referenced file. But to do that reasonably and/or automatedly, you need to know the effective timeCodesPerSecond/FPS of the abc file.

[Sybren A. Stüvel]

Hi Dorian,

On 20-08-19 22:28, 'Dorian Fevrier' via alembic-discussion wrote:

I would say it’s up to the importer to interpolate values correctly depending on what the FPS is in current scene.

This is exactly my point. In some cases there is no "current scene". Converting an Alembic file to a USD file is such a case. This conversion is done in a plugin for the USD library, and is implicit to the application performing the actual loading of the file.

IMHO, having a metadata for FPS would mostly confuse importer writers even more as they will be tempted to assume a particulare sampling rate (something Alembic can't garantee).

This loosely translates in my head as "if we don't document this well it may be confusing", and of course you're absolutely right in that respect. Of course the metadata field needs to be defined well. Defining it as "the frame rate of this file" would be problematic, as you describe. Something like  "scene frame rate at time of writing the Alembic file" sounds pretty clear to me. It doesn't make any promises about the samples themselves, but it would present a nice default value when there is no scene to fall back to.

If archive metadata is 24 FPS and merged objects from different sources are 60, how the metadata should react ? How the importer should react if archive metadata states a particular frame rate but some objects don’t follow this rule.

I would expect it to behave no different than it would now. Alembic has a clear mapping from time to samples.

I saw USD hardcode 24 FPS. Wouldn’t it be more efficient to consider Alembic archive follow the current FPS.

This entire proposal is for cases where there is no "current FPS" and where the Alembic file is the only source of information. Furthermore, it would allow DCC applications like Blender (I'm a Blender developer), to update the scene frame rate to match the imported Alembic file.

[Lucas Miller]

> This entire proposal is for cases where there is no "current FPS" and where the Alembic file is the only source of information. Furthermore, it would allow DCC applications like Blender (I'm a Blender developer), to update the scene frame rate to match the imported Alembic file.

Optionally storing the DCC frame rate at time of writing in the
archive meta data doesn't sound as scary as having a mandatory forced
FPS.

What should Blender do if a user imports multiple Alembic files with
these optional different frame rates?

Lucas

[Sybren A. Stüvel]

On 22-08-19 22:15, Lucas Miller wrote:

Optionally storing the DCC frame rate at time of writing in the
archive meta data doesn't sound as scary as having a mandatory forced
FPS.

Glad to hear that :)

What should Blender do if a user imports multiple Alembic files with
these optional different frame rates?

The way I look at it now, there would be an option added to set the scene frame rate to whatever is declared in the Alembic file. It's then up to the user to enable or disable that option during import. Since Blender only loads one Alembic file at a time, this results in well-defined behaviour.

Our importer already has an option to set the scene frame range to the time sample range of Alembic, given the current scene FPS. The new option to also set the scene FPS would work in a similar way.

[Lucas Miller]

Issue was created here:

https://github.com/alembic/alembic/issues/229

> --
> You received this message because you are subscribed to the Google Groups "alembic-discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to alembic-discuss...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/alembic-discussion/5e3aaefd-5d5d-2253-742a-a8c191d3f1a6%40stuvel.eu.

[Lucas Miller]

And was released in 1.7.12

Lucas