OGraf Data binding connects controller-supplied JSON values to a broadcast graphic. A field can change a presenter name, but it can also drive a color, image, position, opacity, font, crop or another visual property.
That distinction matters. A truly reusable graphic is not a fixed picture with one editable text box; it is a visual system whose approved values can be controlled safely by a rundown, automation system or graphics operator.
What OGraf Data binding does
The controller sends structured values. The graphic maps those field keys to selected properties. The renderer applies the values and can run an update animation around the moment when old data is replaced by new data.
The OGraf specification uses a Graphics Data Definition, or GDD, built with JSON Schema. The schema tells compatible control software which fields exist, what each field is called, which value type it accepts and which default value should be used.
For the broader format and action model, read What Is OGraf? The Open Standard for Broadcast Graphics.
A practical lower-third data model
A simple lower third might receive this controller data:
{
"name": "Sofie Hansen",
"title": "Graphics Designer",
"accentColor": "#ef233c",
"showPortrait": true
}The same field keys are defined in the schema. The schema can describe name and title as strings, accentColor as a color control and showPortrait as a boolean. A controller can then build suitable inputs instead of presenting every value as an unvalidated text field.
Value type and control type are different
A field needs both a valid JSON Schema value type and a useful operator control. The value type defines the data contract; the control type describes how a compatible interface should present it.
- String: single-line text, multi-line text, file paths, dropdowns, colors, dates or times.
- Number: scores, percentages, durations, dimensions or other numeric values.
- Boolean: visible/hidden choices and other on/off states.
- Choice: a constrained list of allowed options.
- Other structured values: used when a graphic needs a more specialized schema.
Bind data to every visual value
Falcon Graphics exposes binding selectors throughout a layer. Depending on the layer type, controller data can drive:
- X and Y position, width, height, uniform size and rotation.
- Opacity, visibility, blur, motion blur strength, skew and crop on every side.
- Text content, font family, font size, weight, alignment and colors.
- Text-background activation, color, radius and individual padding values.
- Minimum and maximum text width and shrink-to-fit behavior.
- Image and video sources, iframe addresses, code values and layer-specific settings.
This allows one template to adapt to several brands or use cases without duplicating the animation. A controller might change the content only, or switch an entire visual treatment with a validated set of fields.
The update marker protects the transition
Changing data instantly can look untidy. A name may jump to a different width while it is visible, or a score may change halfway through an animation. The update range solves that problem.
- Animate the old value out or reduce its opacity.
- Place the data-swap marker where the old value is safely hidden.
- Falcon Graphics applies the incoming data at that marker.
- Animate the new value back into view.
A layer can be configured to run that update animation only when its relevant value has changed. The default avoids replaying an update transition when a controller sends data identical to the current value.
OGraf Data is not the same as Live Data
OGraf Data is pushed into the graphic by CasparCG, Falcon Play or another controller. The operator owns the update.
Live Data is fetched by the graphic from a configured URL or API. It can read a plain string, follow a JSON path or select a value from allowed HTML, then refresh once, on update or at an interval.
Separating the two avoids ambiguity: controller data is part of the graphics control contract, while Live Data is an external request performed by the exported HTML itself.
A reliable data-field workflow
- Choose a stable field key that will not change after controller integration.
- Write a clear operator-facing label and description.
- Select the correct value type and control type.
- Set a realistic default value that makes the template preview useful.
- Bind the field only to the properties the operator should control.
- Test short, long, empty and unexpected values in the editor.
- Preview the update action and confirm the swap marker timing.
- Export and test from the real controller before going on air.
Empty text and responsive fitting
Dynamic names and headlines vary in length. Configure a maximum width and automatic shrinking when a single line must stay inside the design. Use minimum width when backgrounds or labels should remain visually consistent.
When a bound text value is empty, an activated text background should also disappear. This prevents an empty padded box from remaining on screen after the controller clears the field.
Exporting the data contract
The OGraf export embeds the valid GDD JSON with the manifest and graphic runtime. The self-contained CasparCG HTML export includes the data definitions and the callbacks used by the playout controller.
To build a complete CasparCG workflow, continue with How to Create CasparCG HTML Templates Without Coding.
Frequently asked questions
What is OGraf Data?
OGraf Data is the structured input supplied by a controller or playout system to a graphic. Its fields are described with JSON Schema so compatible software can understand their values and controls.
Is OGraf Data binding only for text?
No. Falcon Graphics can bind OGraf Data to every supported visual value, including transform, visibility, typography, color, image sources, crop, blur and layer-specific properties.
What is the difference between OGraf Data and Live Data?
OGraf Data is pushed into the graphic by a controller. Live Data is fetched by the graphic itself from a URL or API. Falcon Graphics keeps them separate and previews both.
When should an update animation run?
By default, a bound layer can run its update animation only when its relevant incoming value has changed. This avoids unnecessary movement when a controller sends the same data again.