A reference for cinematographers, DPs, and location scouts — the math, models, and data sources behind every value Skopos reports.
Skopos is a working tool for film professionals: a digital director's viewfinder, a sun and light planner, a depth-of-field calculator, an exposure meter, and a location scouting system. Pros trust their tools when they understand what is happening underneath. This document describes the math, models, and data sources Skopos uses, with the actual formulas as implemented and every simplifying assumption stated.
Nothing in this document is proprietary. The formulas are drawn from standard cinematography and astronomy references. The sensor data is sourced from manufacturer technical documentation. The intent is that any user can verify Skopos's outputs against their own measurements, hand calculations, or other tools.
If you find a discrepancy, please contact us at hello@skopos.studio with the inputs, your expected output, and Skopos's reported value. Pros earn the right to be skeptical of new tools; that skepticism is a feature.
Skopos's camera database lists the active recording dimensions for each body and recording mode. These are the dimensions that determine field of view, focal-length equivalence, and depth of field for that specific mode.
Active recording dimensions are the portion of the sensor that is read out and recorded for a given mode — not always the full silicon, and not always the full photosite array. Where a manufacturer publishes both "sensor size" and "recording area" or "photo site area," Skopos uses the recording area, since that is what is exposed to light and committed to the file.
Values are sourced from manufacturer technical documentation. Manufacturers in the current database include ARRI, RED Digital Cinema, Sony, Canon, Blackmagic Design, Panasonic, Fujifilm, Nikon, Z CAM, Panavision, Kinefinity, Phantom, Leica, Sigma, DJI, Freefly, AJA, IMAX, and Ikonoskop, plus standard film formats. The full list of bodies and modes is available on the Camera Database page.
Anamorphic recording modes are stored with their photographic capture dimensions (the area exposed). Squeeze ratio is applied separately, on top of the gate width, when computing the desqueezed image's aspect ratio and field of view (see § 02).
Skopos computes horizontal field of view from sensor gate width and lens focal length using the standard rectilinear-projection formula:
Where gate_width is the active recording width of the selected mode multiplied by the squeeze factor (1.0 for spherical, 1.33×, 1.5×, 1.8×, or 2× for anamorphic). Vertical and diagonal fields of view are computed by substituting the corresponding dimension.
For anamorphic, Skopos treats the effective horizontal capture width as the photographic gate width multiplied by the squeeze ratio. A 2× squeeze on a 4-perf Super 35 capture area, for example, produces a horizontally-stretched image with twice the captured horizontal angle of view, which is then desqueezed in post or on a monitor.
When a delivery aspect ratio is specified that is narrower than the gate (e.g., 2.39:1 delivery from a 1.78:1 gate), Skopos crops vertically (top-and-bottom) and continues to use the full gate width for FOV. When the delivery aspect ratio is taller than the gate, Skopos crops horizontally to fit, and the delivery field of view becomes correspondingly narrower than the full gate.
DPs working across formats need to translate a focal length on one camera into the equivalent focal length that produces the same horizontal angle of view on another. Skopos uses full-frame 35mm still photography (36 mm wide) as the reference, following the cinematographic convention that focal-length equivalence is based on horizontal coverage, since framing is the operational concern:
This is sometimes called the "horizontal crop factor" (36 ÷ gate_width). It differs from the diagonal-based crop factor used in still-photography contexts. The horizontal convention is what matters for matching framing across formats — a 50 mm on full-frame and a 33 mm on Super 35 produce the same horizontal field of view, and Skopos reports them as equivalent.
When the iPhone running Skopos is itself the recording device, the formula above is not used because Skopos does not have the iPhone's exact sensor dimensions per model. Instead, Skopos reads the field of view that iOS reports for the active camera and inverts it directly:
This means the focal-length-equivalent values shown in the viewfinder are per-device — they reflect what the user's specific iPhone reports, not a hardcoded constant. See the iPhone section of the Camera Database for more detail on iPhone host behavior.
Skopos uses the simplified hyperfocal-based depth-of-field model. Three values are reported: hyperfocal distance, near focus limit, and far focus limit.
Where:
f — focal length, in millimetersT — T-stop. Skopos uses T-stop directly; for DOF math, T-stop and f-number are interchangeable since depth of field depends on geometric aperture, not transmission.d — focus distance from the sensor plane, in metersc — circle of confusion, in millimeters (see § 4.2)These are the Zeiss-style simplified forms widely used in cinematographic DOF tables. They converge to the textbook "classical" formulas (the D = s·(H−f)/(H ± s ∓ f) family) within fractions of a percent for any practical shooting scenario, since H is typically much larger than f.
Skopos computes the circle of confusion automatically from the active recording mode's sensor diagonal, using the well-established d/1500 convention (sometimes called the Zeiss formula):
Where W and H are the active recording mode's width and height in millimeters. The 0.001 mm floor protects against degenerate values for very small sensor crops. This is one of two common conventions in industry: the d/1500 formula scales naturally with sensor size and produces depth-of-field results consistent with traditional cine focus tables.
Sample values for representative formats, as Skopos computes them:
| Format | Active area | Diagonal | CoC |
|---|---|---|---|
| Full Frame 35mm | 36.0 × 24.0 mm | 43.27 mm | 0.0288 mm |
| VistaVision / LF (ALEXA Mini LF) | 36.7 × 25.5 mm | 44.69 mm | 0.0298 mm |
| ALEXA 35 Open Gate | 28.0 × 19.2 mm | 33.95 mm | 0.0226 mm |
| Super 35 (4K 16:9) | 24.9 × 14.0 mm | 28.57 mm | 0.0190 mm |
| Super 16 (2K) | 12.4 × 7.0 mm | 14.24 mm | 0.0095 mm |
| APS-C (X-T5) | 23.5 × 15.6 mm | 28.20 mm | 0.0188 mm |
| Micro Four Thirds | 17.3 × 13.0 mm | 21.64 mm | 0.0144 mm |
| iPhone main (1×, typical) | ~7.0 × 5.3 mm | 8.78 mm | 0.0059 mm |
Skopos's exposure meter relates aperture, shutter time, and ISO using the standard photographic equation:
Where T is the T-stop, t is the shutter time in seconds, and k is the meter constant for the current scene. Solving for any one variable given the other two is a direct rearrangement of this equation.
Skopos accepts shutter time entered either as a fraction (1/48 s) or as a shutter angle (172.8° at 24 fps), using the standard cine relationship:
So 180° at 24 fps is exactly 1/48 s. Skopos's available shutter angles are the standard cinematographic set: 11.25°, 22.5°, 45°, 72°, 90°, 180°, 270°, 360°.
ND filter strength is specified by optical density. Skopos converts density to stops of light loss using:
Which is equivalent to log2(transmission ratio), since 100.3 ≈ 2 (one stop). Skopos's ND options span CLEAR through ND 2.4 (eight stops), in 0.3-density increments:
| ND value | Stops | Transmission |
|---|---|---|
| CLEAR | 0 | 100% |
| ND 0.3 | 1 | 50% |
| ND 0.6 | 2 | 25% |
| ND 0.9 | 3 | 12.5% |
| ND 1.2 | 4 | 6.25% |
| ND 1.5 | 5 | 3.125% |
| ND 1.8 | 6 | 1.5625% |
| ND 2.1 | 7 | 0.78% |
| ND 2.4 | 8 | 0.39% |
Skopos's sun tracker, golden-hour planner, and sun-arc visualizations are driven by a NOAA-style solar position calculation based on the algorithms in Jean Meeus's Astronomical Algorithms (2nd ed., Willmann-Bell, 1998). This is the same algorithm family used by NOAA's public Solar Position Calculator. Accuracy is better than 0.01° for any date between 1800 and 2200, more than sufficient for cinematographic planning.
Skopos does not require an elevation input. For the cinematographic use case (planning sunlight at a location), the elevation correction is a fraction of an arcminute and is not material.
Light from the sun bends as it passes through the atmosphere, making the sun appear higher than its geometric position — most noticeably near the horizon. Skopos applies the standard piecewise refraction model used by NOAA's calculator (the Bennett 1982 polynomial for low altitudes and the standard high-altitude tangent series above ~5°), so that reported sunrise and sunset times reflect what the eye and camera actually see, not the geometric horizon crossing.
Sunrise and sunset are reported when the sun's apparent center is at altitude −0.833° — accounting for both the standard refraction at the horizon and the sun's apparent semi-diameter of ~16′. This is the convention used by every major astronomical and timekeeping authority.
Skopos's phase boundaries are pegged to the sun's altitude and use the conventions standard in cinematography and astronomy:
| Phase | Sun altitude | Notes |
|---|---|---|
| Daytime | above +6° | Standard daylight; sun high enough for hard top light. |
| Golden hour | +6° to sunrise/sunset | Industry-standard cinematographic window; warm directional light. |
| Sunrise / sunset | −0.833° (apparent) | The standard refracted disk-edge crossing. |
| Blue hour | sunrise/sunset to −4° | Blue cast dominant; sky still luminous. |
| Civil twilight | 0° to −6° | Brightest objects visible; usable ambient. |
| Night | below −6° | Past civil dusk / before civil dawn for Skopos's purposes. |
For the moon, Skopos uses a simplified low-precision lunar calculator (~1° accuracy in altitude and azimuth). This is sufficient for the moon-arc overlay and the per-frame moon indicator on recorded clips, but is not intended for precision astronomical work.
Skopos's sky-map overlay draws the sun's full daily arc onto a live camera view. Three coordinate systems meet here: the celestial sky (where the sun is), the world (the user's geographic location and orientation to true north), and the device camera frame (where the arc must be drawn on screen).
xTrueNorthZVertical reference frame when available, falling back to xMagneticNorthZVertical only if true-north is unavailable on the device.[CAL +X°] indicator so the operator knows it is active.On LiDAR-equipped devices (iPhone Pro and iPad Pro models), Skopos's tap-to-measure tool uses ARKit raycasting, with the LiDAR scene-depth buffer made available to ARKit through the .sceneDepth frame semantic. The system fuses the LiDAR depth signal with visual-inertial odometry to produce metric distance to the tapped point in the scene.
This is a planning tool, not a survey instrument. For dimensions that must be exact (set construction, lens calibration, focus calibration), measure with a tape or laser rangefinder.
Skopos's weather information has two sources, selected automatically depending on the shoot date:
For shoot dates within the WeatherKit forecast horizon (10 days from the current date), Skopos queries Apple WeatherKit for the daily forecast at the location's coordinates. Apple aggregates and processes meteorological data from multiple sources, with the specific source chosen for each location. Skopos passes through what WeatherKit returns and shows the required "Weather data: Apple Weather" attribution on every report.
For shoot dates beyond 10 days — which is most of the use case for location scouting — Skopos queries WeatherKit's Statistics API for month-of-year climate normals at the location's coordinates. The Statistics API has global coverage and returns the month's average high temperature, average low temperature, and a precipitation-probability figure, sourced from Apple's models with station observations where available.
Climate normals are effectively static — 30-year averages that don't change by the hour, day, or month — so Skopos caches results aggressively per coordinate-and-month, with lat/lon quantized to a ~11 km grid (climate is regional, not hyperlocal: a request 5 km away returns the same normals). The cache has two layers: an in-memory dictionary for instant hits within a session, and an on-disk JSON file in the app's local storage that survives restarts and enables offline lookup for any previously-scouted location. No expiration is applied.
This same historical path is also used when a within-window WeatherKit forecast call fails (no network, no entitlement, transient error). In that case the report shows the failure cause alongside the historical figure, so users know why they got climate data instead of a forecast.
If the Statistics API itself fails and the cache has no entry for the requested location-month, Skopos falls back to a bundled US-only climate database covering 20 cities — New York, Los Angeles, Chicago, Austin, Dallas, Houston, San Antonio, Atlanta, Miami, Denver, San Francisco, Seattle, Phoenix, Nashville, New Orleans, Albuquerque, Portland, Santa Fe, Wilmington (NC), and Savannah (GA) — gated to within 150 miles of one of them. Outside that radius, and with no Statistics result available, no historical data is shown rather than fabricating values.
A current limitation worth flagging: WeatherKit's Statistics API returns its averagePrecipitationProbability field as zero in most regions (a known Apple data-quality issue). Skopos reports the value WeatherKit returns; in practice, expect precipitation-days from this path to read as zero or absent until Apple addresses the underlying data.
CMDeviceMotion attitude reference frames), ARKit (raycast and scene depth), WeatherKit (forecast service).The full list of 138 bodies and 315 recording modes currently in Skopos, drawn from the manufacturer documentation cited above.