A 35mm film camera represented in Python object

[2QdxY4RzWzUUiLuE at potatochowder.com]

On 2021-04-01 at 18:10:46 -0400,
Richard Damon <Richard at Damon-Family.org> wrote:

> On 4/1/21 5:47 PM, D.M. Procida wrote:
> > D.M. Procida <real-not-anti-spam-address at apple-juice.co.uk> wrote:
> >
> >> Hi everyone, I've created <https://github.com/evildmp/C-is-for-Camera> -
> >> a representation of a Canonet G-III QL17 in Python.
> >>
> >> There's also documentation: <https://c-is-for-camera.readthedocs.io>.
> >>
> >> It's a pure Python model of the physical sub-systems of a camera and
> >> their interactions. So far it's at a fairly high level - I haven't yet
> >> got down to the level of individual springs and levers yet.
> > I'm now working on the exposure system, which in the published version
> > so far just models inputs and outputs of the system as a whole. I want
> > to start to model its functionality by modelling the interactions of its
> > components - the levers, cams and so on.
> >
> > It seems to me I have fundamentally two approaches that I could take:
> >
> > The first is to model the movement of each lever as a series of discrete
> > steps (hundreds of tiny steps, to maintain accuracy). Pro: it models
> > movement through physical positions; con: it's ugly that it breaks
> > continuous movement into arbitrary steps.
> >
> > The second is not to move each lever in such detail, but to consider its
> > interactions: given the state of each of the other parts of the system,
> > what *would* be the outcome if something were to try to move the lever
> > from such-and-such a position to another? Pro: it feels more elegant
> > than the brute-force stepping of the alternative; con: it also feels
> > like a bit of a cheat.
> >
> > But neither approach really captures for me the interaction of moving
> > analog components, which in the case of this camera also have some
> > circular logic to them - the movement of A determines that of B which
> > determines that of C which determines that of D which finally also
> > affects the movement of A.
> >
> > Any thoughts or wise ideas? 
> >
> > Daniele
> 
> If you keep track of the positions as a floating point number, the
> precision will be more than you could actually measure it.

I won't disagree with Richard, although I will give you a general
warning about floating point rounding issues:  if you do, in fact, end
up with your first solution and lots and lots (millions?  billions?
more?) of discrete calculations, be aware that what looks like a lot of
precision in the beginning may not be all that precise (or accurate) in
the end.

Also, doesn't the overall motion of the camera as a whole also depend on
external factors, such as whether/how it's mounted or handheld, the
nature of the "ground" (e.g., soft wet sand vs. hard concrete
vs. someone standing on a boat in the water), an experienced
photographer "squeezing" the shutter release vs. a newbie "pressing the
button"?  I can think of plenty of variables; I guess it depends on what
you're trying to model and how accurate you intend to be (or not to be).