Open JGoldstone opened 1 year ago
Use of the term lens anywhere is unnecessary and can be misleading if simple perspective projection is sufficient. Rather than "lens", prefer the term center of projection. See for example: https://www.cse.unr.edu/~bebis/CS791E/Notes/PerspectiveProjection.pdf
Perspective projection is well defined and documented and seems to apply here.
I don't recall if we discussed this elsewhere for this property/characteristic (I know we did for others), but why is this a rational (synthetically determined/constrained) instead of a float (empirically determined)? Are there instances in which e.g. 32b floating point precision is insufficient in whatever units (mm?) we're using for this value? This seems especially relevant in the case of zooms - are we expecting a lens to output some rational with an fixed denominator derived from encoder resolution as it steps through the zoom range?
@repentsinner Floats are not interoperable when serialized to text, e.g. in JSON.
@bgschunck would you be OK with this? It substitutes 'center of projection' in the definition to handle the general case and adds a note so that users of the definition can relate it to their situation:
Offset along the optical axis of the center of projection from the nominal image plane, with a positive offset indicating a position on the same side of the nominal image plane as is the object.
Note: in the classic CG pinhole camera model, the center of projection corresponds to the pinhole. In a physical camera and lens assembly such as is typically found in television or motion picture production, the center of projection corresponds to the lens entrance pupil.
I am open to improvements in the phrase 'such as is typically found in television or motion picture production', but would like whatever we decide to adopt to be concrete and something to which a SMPTE member could instinctively relate.
@repentsinner Floats are not interoperable when serialized to text, e.g. in JSON.
Is this something we should be baking into our definition, or just make a note regarding representation in a particular format (e.g., json)?
Also is ISO 6093 insufficient to deal with that case?
The proposed working is much better. I am happy enough with it. And it is probably sufficient for you use case.
Usually the phrase would be “offset from the center of projection to the image plane …” since the center of projection is the origin of the xyz coordinate system for the pinhole camera in the XYZ world coordinate system (absolute coordinates is the term in photogrammetry). In the xyz coordinate system of the pinhole camera, the z axis is along the optical axis and pointing into the scene, the x and y axes define the 2D coordinates of the image plane (a left-hand coordinate system).
But this is likely TMI. 😊
-- Brian Schunck Email: @.**@.>
From: Joseph Goldstone @.> Sent: Thursday, October 5, 2023 5:46 AM To: SMPTE/ris-osvp-metadata @.> Cc: Brian Schunck @.>; Mention @.> Subject: Re: [SMPTE/ris-osvp-metadata] Entrance pupil should be located by an offset from the Nominal Image Plane (Issue #13)
@bgschunckhttps://github.com/bgschunck would you be OK with this? It substitutes 'center of projection' in the definition to handle the general case and adds a note so that users of the definition can relate it to their situation:
Offset along the optical axis of the center of projection from the nominal image plane, with a positive offset indicating a position on the same side of the nominal image plane as is the object.
Note: in the classic CG pinhole camera model, the center of projection corresponds to the pinhole. In a physical camera and lens assembly such as is typically found in television or motion picture production, the center of projection corresponds to the lens entrance pupil.
I am open to improvements in the phrase 'such as is typically found in television or motion picture production', but would like whatever we decide to adopt to be concrete and something to which a SMPTE member could instinctively relate.
— Reply to this email directly, view it on GitHubhttps://github.com/SMPTE/ris-osvp-metadata/issues/13#issuecomment-1748827874, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AB2VU4WE5XKYXWZKV66WX4TX52TZDAVCNFSM6AAAAAA5J44UPSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONBYHAZDOOBXGQ. You are receiving this because you were mentioned.Message ID: @.***>
It's not a good idea to represent dynamic parameters as rational numbers. Try to view that in a graph... Maybe consider abstracting definitions from implementation to a JSON based file format There are many JSON file formats that store values and key-frames in double or float in JSON, see gltf for example.
The entrance pupil is centered around the optical axis, conceptually exists in a plane perpendicular to the optical axis, and can be anywhere on that axis, even on the opposite side of the nominal image plane from the object on which the lens is focused.
Defining the location of the entrance pupil this way completely dodges the issue of 3D coordinate system handedness, axis naming, etc. The constraints on the entrance pupil allow us to locate it with a simple scalar and indeed that is the data type we have today ...
... for something we currently call Entrance Pupil Position.
I suggest we do the following:
First, rename the parameter to Entrance Pupil Offset
Second, change the definition of the Parameter from
to
Lastly, change the constraints from
to