Sensor Dimension units

[revisionfx]

When developing the ASC-FDL initially I was a proponent of using microns as a unit but then in practice (user testing) people had a lot of problems mentally manipulating such large values (e.g. 35000 instead of 35.0 for sensor dimension), so we reverted to have all physical dimensions in mm. Although of zero short-term importance, I know of two smartphones who have pixel pitches under 1 nm now, Samsung being one.

Question is why not just take directly the Canvas structure from ASC-FDL instead, this way the work done for Framelines for example would populate this correctly (directly).

Comment: It's a bit weird in 2023 to use just integers and rational numbers (int/int). I understand some cameras don't even have floating point CPU and do everything in FPGA... but still they should internally do the multiplication not impose on rest of the world that shortcoming.

[JGoldstone]

@revisionfx I think different communities have different tolerances (pardon the pun) regarding comparisons of floats for equality.

In RDD 55 I went with floats for metadata that CG artists, who are not particularly used to encountering rationals, might see, typically dimensional or angular information, with some outliers; and with rationals for metadata where rationals are found in the wider SMPTE world, typically in temporal sample rates. Specifically:

rationals: ExposureTime, SensorSampleRate, DataStreamSampleRate, plus any items in ST 377-1-specified descriptors with a data type of Rational, e.g. Edit Rate, Event Edit Rate, Sample Rate, Aspect Ratio, Audio Sampling Rate

floats: SensorWidth (mm), SensorHeight (mm), SensorPixelPitch (microns), LUT3DNormalizationGain, LUT3DNormalizationOffset, CDL Slope, Offset, Power and Saturation, XCoordinate, YCoordinate, ZCoordinate, Pan (degrees), Tilt (degrees), Roll (degrees), Tint (Kodak CC035 filter units), NDFilterDensity, TextureImageSharpness, TextureImageDetail, TextureNoiseReductionStrength.

[revisionfx]

Makes sense, rational int/int to turn into double (64bit float) As you say applies to all inherited from analog days (like 29.97002997... if a float you are off once in a while - forget if it's 2,4 or 6 frames per hour - as in convert to frame number will create a few duplicate and missing frames otherwise). Same with aspect ratio.

[palemieux]

In RDD 55 I went with floats for metadata that CG artists, who are not particularly used to encountering rationals

Artists should never see the raw JSON data.

[revisionfx]

In RDD 55 I went with floats for metadata that CG artists, who are not particularly used to encountering rationals

Artists should never see the raw JSON data.

This is a bit binary statement, a lot of CG artists can do python, javascript... (TD technical directors write scripts and expresions all the time) so are not afraid of textual representations.

[palemieux]

This is a bit binary statement, a lot of CG artists can do python, javascript... (TD technical directors write scripts and expresions all the time) so are not afraid of textual representations.

Ok, then they should not be afraid of rational numbers :)

[JGoldstone]

My thought was that (a) pretty much any tool a VFX artist might use that understands metadata is already handling floating-point metadata and (b) not all the tools might already have rational support. (I had to add it to OpenImageIO's toolset, for example.) Thus going with rationals might leave an artist in a situation where one app was hip to the idea of Rationals and another app might not be.

Admitting I might be wrong about this, I think in the places where rational numbers are used, they tend to either be immutable, mutable by wholesale replacement with another rational, or only lightly arithmetically processed. My apprehension is that if you have a virtual camera in a heavily nested set of coordinate frames (gimbal rig at the end of a Technocrane) that maintaining accuracy in calculation might cause one to have to go to numerators or denominators that would exceed what a 64-bit number could hold.

Pierre, where can we find the latest ASC FDL spec?

[revisionfx]

Correct, rational is not a natural generic data type anywhere (in any apps) except perhaps in Frame Import/Export libraries (e.g. AVRational in ffmpeg -- double (av_q2d). The counter argument would be people won't put enough digits after the point... e.g. aspect ratio 1.85. 1.78 and application / user take this verbatim - so rates and aspect ratios might be safer described as a 2D int. That's until phones and screen capture type processes come in with variable frame rates :) - ratio is usually easy for people (e.g. 16:9 - rates is harder for people to understand e.g. 60000/1001

GoPro has a keyword/type for Frame Rate (that could be a rational) versus other sampling rate (Hz, GHz). https://github.com/gopro/gpmf-parser

The ASC-FDL specs are here: https://theasc.com/society/ascmitc/asc-framing-decision-list

Uses two terms to define project intent aspect ratio.