On 2021-04-01 at 18:10:46 -0400, Richard Damon <rich...@damon-family.org> wrote:
> On 4/1/21 5:47 PM, D.M. Procida wrote: > > D.M. Procida <real-not-anti-spam-addr...@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). -- https://mail.python.org/mailman/listinfo/python-list
