Cut data model and schema

Shotgun 7.0 establishes an official data model for tracking editorial information, which captures a historical snapshot for cut data.

Having this information in Shotgun opens up many feature possibilities—including tracking Cut history, support for overlapping Cuts like 30/60/90 second Cuts in Commercials, and watching any piece of media in the context of the Cut including non-VFX Shots.

In addition to supporting Shotgun’s browser and RV review tools, the Cut data model provides studios with the ability to integrate their internal editorial tools to Shotgun.

The core of the Cut data model are the Cut and Cut Item entities. At the Cut-level, we track global information about the Cut, like Revision Number, FPS, EDL file, and an optional Base Layer Movie Version.

A Cut can be associated to Sequences and Scenes by default, but can be customized to just about any entity in Shotgun as a way to support various editorial workflows—such as Episodes, Commercials, Trailers, and more.

Cut Items are connected to Cuts and make up the actual items of an EDL. Think of it as the Shotgun-based view of your EDL. At this level, we are tracking things like Cut Order, individual clip In/Out points in Frame and Timecode formats, and optional links to Shots and Versions.

Cut Field Details

Cut Item Field Details

Below is a description of the standard fields Shotgun uses to track cut information based on actual use cases and client feedback. These standards are published to help ensure tools and integrations with third-party applications work consistently for all Shotgun clients.

Note: Only still images or movie files are officially supported.

Shot fields

Field name (field type) internal_field_name Description and usage Example
Cut In (number) sg_cut_in The first frame used in the Cut. This input comes from editorial and is used for playback of movie and frames. 15
Cut Out (number) sg_cut_out The last frame used in the Cut. This input comes from editorial and is used for playback of movie and frames. 125
Cut Duration (number) sg_cut_duration The duration of this Shot in the Cut. 111
Cut Order (number) sg_cut_order The order that the Shot plays in the overall Cut for the entire Project. Used for sorting Shots and Versions of Shots when playing in cut order, and pulling in neighboring Shots of Versions to the current one being viewed. 210000007
Head In (number) sg_head_in The first frame number that footage is available for this Shot. 11
Tail Out (number) sg_tail_out The last frame number that footage is available for this Shot. 130
Working Duration (number) sg_working_duration The full duration of available frames in this Shot from Head In to Tail Out. 120

Version fields

Field name (field type) internal_field _name Description and usage Example
Uploaded Movie (file/link) sg_uploaded_movie The file field to contain the uploaded movie file. Used for playback of lower resolution movie media stored in Shotgun. Upload file
Path to Movie (text) sg_path_to_movie The location of the movie on your local filesystem (not uploaded). Used for playback of lower resolution movie media stored locally. /path/to/movie.mov
Movie Aspect Ratio (float) sg_movie_aspect_ratio The aspect ratio of the movie. Used to format the image correctly for viewing. 1
Movie Has Slate (checkbox) sg_movie_has_slate Indicates whether the movie file has a slate or not. This is used to include or omit the slate from playback. [✔]
Path to Frames (text) sg_path_to_frames The location of the high resolution frames on your local filesystem. Used for playback of high resolution frames. /rvshotgundemo/BBB_Short/08_a-team/012/ANIM/001/BBB_08_a-team_012_ANIM_001.#.jpg
First Frame (number) sg_first_frame The first frame number contained in the Version. Used in playback of the movie or frames to calculate the first frame available in the Version. 11
Last Frame (number) sg_last_frame The last frame number contained in the Version. Used in playback of the movie or frames to calculate the last frame available in the Version. 130
Frames Aspect Ratio (float) sg_frames_aspect_ratio The aspect ratio of the high resolution frames. Used to format the image correctly for viewing. 1
Frames Have Slate (checkbox) sg_frames_have_slate Indicates whether the frames have a slate or not. This is used to include or omit the slate from playback. [ ]
Department (text or list) sg_department The department that submitted the Version. This is used to find the latest Version from the same department. ANM

What about Shot fields?

Shot-level cut fields—like Head In, Tail Out—are kept independent from Cut and Cut Item values.

This is due to two primary reasons. First, the iterative nature of editorial data tracking. For example, you may have work-in-progress, temporary Cut you’d like to enter into Shotgun, but you don’t want to update Shot-level values until the Cut is made official. Second, depending on your pipeline and the demands of the departments, the number of handle frames can vary. This type of information generally doesn’t fluctuate with the Cut and should be tracked independently.

For ease of use, the RV Import Cut App can automatically handle updating Shot-level fields upon import by selecting the Update Cut Fields on Shots option. If you’re doing your own integration, you’ll want to keep the Shot-level fields in mind.

We have been tracking cut data in Shotgun—can I use that with the new review toolset?

Yes, but it won’t happen automatically.

We’ve built the Cut Data Model to avoid any issues upon the release rollout, but there are changes to the Cut, Cut Item, and CutVersionConnection Entities. In order to reduce risk during the release rollout, we separated Schema Migration from Data Migration. Data Migration is handled via a post-release process by our Support Team.

If you have legacy cut data that you’d like to work with the 7.0 Cut Data Model, our Support Team can assist. Just drop them a request.

Schema and Data Migration Details

If you’re interested in the nitty gritty details, read on!

For sites that have never used the Cut, Cut Item, or CutVersionConnection Entities, the schema migration that happened when your site was upgraded to Shotgun v7.0 simply removed these unused fields from your site schema and you are now able to use the new fields. No special data migration is required.

If our system found use of the above three entities in your database during the 7.0 schema migration upgrade, the migration did not remove any fields or data from the current schema for the corresponding Entity. Instead, these fields have been changed to user fields and are now considered fields that you would have added yourself.  

For example, if the system detected you use Cut Entities, but not Cut Item or CutVersionConnection Entities in your site database, the “Sequence (sg_sequence)” field of the Cut entity will not be deleted, but is now classified as a user field that can be deleted at your leisure. Since CutItem and CutVersionConnection were not detected, they would automatically be removed.

This approach ensures there is no data loss during the upgrade to Shotgun 7.0.

After the migration to Shotgun 7.0, validate if there is the existence of Cut, CutItem and/or CutVersionConnection entities in your current site database. (This is something the Shotgun team will also have done before your upgrade to version 7.0 and will probably have contacted you if we have detected the use of these entities on your site.) 

If your current site schema has extra dynamic fields, please make sure they do not overlap with the recently added fields in the new schema.

If you find that any or all of these three fields are currently in use, pick one of the following data migration options:

Option #1: Leave existing data where it is

This is a good short term option if you absolutely cannot pick any of the other options for internal reasons.

Pros:

If you have scripts or Shotgun pages that use the old fields, these will continue working with no changes required.

Cons:

Your site schema will be left with old entity fields that contain data which are no longer used by Shotgun. For example, when creating a Cut, users will have the option to populate the Sequence and Link fields not knowing the Sequence field is not used anymore. Also, the new Cut Import Tool will automatically populate the Link field on a Cut, but will not populate the Sequence field on a Cut. As a result, if you have scripts that currently depend on the Sequence field being set, these will not find data when using the Cut Import Tool.

How to proceed:

For this option, since existing data can live in old fields alongside new data in new fields, there is nothing to do. We suggest using this option as a short term solution and encourage clients to implement option 2 or 3 below over time if possible.

Option #2: Delete existing data

If you find that the use of one of the removed entities was for test purposes or was associated with an old project you no longer need, you can choose to delete the existing data from your site entirely.

Pros:

Simple procedure.

Cons:

Results in data loss.

How to proceed:

Contact our Support Team with a list of the entity fields that can be safely deleted from your Site. We will then schedule a time to remove the legacy entity fields from your site’s schema. Once this is done, the data associated with these specific fields will be removed from your site, but the values of other entity fields will remain in your database.

Option #3: Migrate existing data to the new entities and fields

This option is the best way to ensure your site schema is not left in a transient state with new and old entity fields.

Pros:

This is the best way to ensure your site schema is not left in a transient state with old and new entity fields which can lead to client confusions and future bugs.

Cons:

Depending on your use of existing fields, the migration might require changes to scripts and internal tools.

How to proceed:

Let our Support Team know that you want to migrate your existing data to the new fields. We will then schedule an automated task that will migrate the data and remove the old fields from your site schema. We will let you know when the migration has completed.

Alternately, you can do the migration yourself. At any point, our Support Team will be glad to assist if you have any questions. Don’t forget to update your internal scripts and tools to remove support for the old fields.

If you choose to do the data migration yourself, the following migration details will be helpful:

Cut Entity:

From Cut

To Cut

Note

Sequence [sg_sequence]

Entity [link]

The new field is an extension of the existing field (which allows to link to entity types other than Sequence).

Cut Item Entity:

From CutItem

To Cut Item

Note

Type [sg_cutitem_type]

N/A

Since the new data model does not have any corresponding field for this, the field will remain a “user” field that you can delete if you want.

Cut [sg_cut]

Cut [cut]

The name of the field is not changed in the UI but internally, and for scripts, it is changed.

CutVersionConnection Entity:

A Cut Item will be created for each CutVersionConnection entity.

From CutVersionConnection

To Cut Item

Cached Display Name [cached_display_name]

- Cached Display Name
 [cached_display_name]

- Cut Item Name [code]

Cut Comments [sg_cut_comments]

Description [description]

Cut Duration [sg_cut_duration]

Cut Item Duration [cut_item_duration]

Cut In [sg_cut_in]

Cut Item In [cut_item_in]

Cut Out [sg_cut_out]

Cut Item Out [cut_item_out]

Cut Order [sg_cut_order]

Cut Order[cut_order]

Follow

0 Comments

Please sign in to leave a comment.