Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
JGoldstone opened this issue Sep 27, 2023 · 7 comments

Comments

@JGoldstone
Copy link

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
Copy link

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
Copy link

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
Copy link
Member

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

@JGoldstone
Copy link
Author

@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
Copy link

@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
Copy link

bgschunck commented Oct 5, 2023 via email

@revisionfx
Copy link

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants