A 35mm film camera represented in Python object

D.M. Procida real-not-anti-spam-address at apple-juice.co.uk
Thu Apr 1 17:47:06 EDT 2021


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


More information about the Python-list mailing list