SMPTE / ris-osvp-metadata

Creative Commons Attribution 4.0 International
26 stars 1 forks source link

Entrance pupil should be located by an offset from the Nominal Image Plane #13

Open JGoldstone opened 1 year ago

JGoldstone commented 1 year ago

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

Entrance pupil position of the lens

to

Offset along the optical axis of the lens entrance pupil 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.

Lastly, change the constraints from

rational number whose numerator and denominator are in the range (0..2,147,483,647].

to

rational number the numerator of which in the range [-2,147,483,648..2,147,483,647] and the denominator of which is in the range [0..4,294,967,295]

bgschunck commented 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.

repentsinner commented 1 year ago

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?

palemieux commented 1 year ago

@repentsinner Floats are not interoperable when serialized to text, e.g. in JSON.

JGoldstone commented 1 year ago

@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 commented 1 year ago

@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?

bgschunck commented 1 year ago

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: @.***>

revisionfx commented 1 year ago

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.