A 35mm film camera represented in Python object
2QdxY4RzWzUUiLuE at potatochowder.com
2QdxY4RzWzUUiLuE at potatochowder.com
Thu Apr 1 18:41:56 EDT 2021
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).
More information about the Python-list
mailing list