A 35mm film camera represented in Python object

[Richard Damon]

On 4/1/21 6:41 PM, 2QdxY4RzWzUUiLuE at potatochowder.com wrote:
> 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).

Actually, I would contend that due to all the factors that you can't
take into account accurately makes the use of floating point more
applicable. Yes, you need to realize that just because the value has
many digits, you KNOW that is only an approximation, and you process
accordingly, knowing you just has an approximation.

The real question comes, what is the purpose of the simulation? You can
NEVER simulate everything, and some parts of 'simulating' requires
actual hardware to interact with. Sometimes the real thing is the best
simulation available.

-- 
Richard Damon