Re: A 35mm film camera represented in Python object

[Eli the Bearded]

In comp.lang.python, Richard Damon   wrote:
> On 4/1/21 6:41 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
>> Richard Damon  wrote:
>>> 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.

I'm having a hard time figuring where the floating point rounding issues
enter in. My reading is that instead of N discrete steps (level 12 is 
1% moved, lever 12 is 2% moved, lever 12 is 3% moved and makes contact
to cam 3, lever 12 is 4% moved and cam 3 is 5% moved; or what not) using
floating points lever 12 could move 0.0 to > 1, and cam 3 start moving
at lever 12 => 0.04.

>> 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).

I suspect very little of the motion of parts *inside* the camera see
meaningful changes from that. The motion of the camera relative to the
scene is meaningful for how motion blurred a shot will be. But the
springs and levers that move as the shutter release button is pushed
will be basically only moving relative to the camera, and not much
changed by tripod or handheld.

> 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.

All of the parts of the camera were built with some engineering
tolerance. Using a precision in code that exceeds that tolerance fails
to accurately model the camera.

> 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.

The purpose was stated in the original post: model a particular camera in
software from the point of view of someone who has done repair work. If
lever 12 is bent, and only touches cam 3 after 15% (or => 0.15) motion
that changes the way the camera works. I believe those sorts of things
are meant to be visible in this model.

Elijah
--
would use floating point, or fixed point as if floating
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Richard Damon]

On 4/1/21 6:41 PM, 2qdxy4rzwzuui...@potatochowder.com wrote:
> On 2021-04-01 at 18:10:46 -0400,
> Richard Damon  wrote:
>
>> On 4/1/21 5:47 PM, D.M. Procida wrote:
>>> D.M. Procida  wrote:
>>>
 Hi everyone, I've created  -
 a representation of a Canonet G-III QL17 in Python.

 There's also documentation: .

 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

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Chris Angelico]

On Fri, Apr 2, 2021 at 9:43 AM <2qdxy4rzwzuui...@potatochowder.com> wrote:
>
> On 2021-04-01 at 18:10:46 -0400,
> Richard Damon  wrote:
>
> > On 4/1/21 5:47 PM, D.M. Procida wrote:
> > > D.M. Procida  wrote:
> > >
> > >> Hi everyone, I've created  -
> > >> a representation of a Canonet G-III QL17 in Python.
> > >>
> > >> There's also documentation: .
> > >>
> > >> 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.

Inaccuracy introduced by FP rounding is likely to be dwarfed by
inaccuracy of measurement. 53-bit precision is pretty accurate
compared to most real-world measurement.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[2QdxY4RzWzUUiLuE]

On 2021-04-01 at 18:10:46 -0400,
Richard Damon  wrote:

> On 4/1/21 5:47 PM, D.M. Procida wrote:
> > D.M. Procida  wrote:
> >
> >> Hi everyone, I've created  -
> >> a representation of a Canonet G-III QL17 in Python.
> >>
> >> There's also documentation: .
> >>
> >> 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

Re: A 35mm film camera represented in Python object

[Mike Dewhirst]

On 2/04/2021 8:47 am, D.M. Procida wrote:

D.M. Procida  wrote:

Hi everyone, I've created  

-

a representation of a Canonet G-III QL17 in Python.

There's also documentation: .

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.


If in doubt model the real world.



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.


Usually taking shortcuts means losing information. You can only drop 
intermediate data which doesn't trigger other events.


Go with your instinct



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.


Connect things which are connected and recalculate A in passive mode.



Any thoughts or wise ideas?


May the force be with you



Daniele



--
Signed email is an absolute defence against phishing. This email has
been signed with my private key. If you import my public key you can
automatically decrypt my signature and be sure it came from me. Just
ask and I'll send it to you. Your email software can handle signing.



OpenPGP_signature
Description: OpenPGP digital signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Richard Damon]

On 4/1/21 5:47 PM, D.M. Procida wrote:
> D.M. Procida  wrote:
>
>> Hi everyone, I've created  -
>> a representation of a Canonet G-III QL17 in Python.
>>
>> There's also documentation: .
>>
>> 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.

-- 
Richard Damon

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[D.M. Procida]

D.M. Procida  wrote:

> Hi everyone, I've created  -
> a representation of a Canonet G-III QL17 in Python.
> 
> There's also documentation: .
> 
> 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
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[D.M. Procida]

Lee Congdon  wrote:

> Note also 36 exposure film.

That depends on how many frames the Film object has!

Daniele
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Lee Congdon]

Note also 36 exposure film.

 -- Film -
Speed:  100 ISO
Rewound into cartridge: False
Exposed frames: 0 (of 24)
Ruined: False

On Sun, Mar 7, 2021 at 5:20 AM D.M. Procida <
real-not-anti-spam-addr...@apple-juice.co.uk> wrote:

> Hi everyone, I've created  -
> a representation of a Canonet G-III QL17 in Python.
>
> There's also documentation: .
>
> 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 spend quite a bit of my time repairing old cameras. To me they feel
> like computer programs encoded into physical objects, and figuring out
> how a mechanism works feels like working out how code works (but more
> fun).
>
> The Canonet G-III QL17 is one of my favourites. One of my reasons for
> writing this code is to appreciate the intricate mechanical logic
> embodied in the machine.
>
> You can do things like advance the film, release the shutter, meter the
> scene with the built-in light meter (if the camera has a battery of
> course) and even spoil your film if you make the mistake of opening the
> back in daylight.
>
> >>> from camera import Camera
> >>> c = Camera()
>
> >>> c.state()
> == Camera state =
>
> -- Controls -
> Selected speed:1/120
>
> -- Mechanical ---
> Back closed:   True
> Lens cap on:   False
> Film advance mechanism:False
> Frame counter: 0
> Shutter cocked:False
> Shutter timer: 1/128 seconds
> Iris aperture: ƒ/16
> Camera exposure settings:  15.0 EV
>
> -- Metering -
> Light meter reading:4096 cd/m^2
> Exposure target:15.0 EV
> Mode:   Shutter priority
> Battery:1.44 V
> Film speed: 100 ISO
>
> -- Film -
> Speed:  100 ISO
> Rewound into cartridge: False
> Exposed frames: 0 (of 24)
> Ruined: False
>
> -- Environment --
> Scene luminosity:   4096 cd/m^2
>
> >>> c.film_advance_mechanism.advance()
> Cocking shutter
> Cocked
>
> >>> c.shutter.trip()
> Shutter opens
> Shutter closes
> Shutter opened for 1/128 seconds
> Shutter uncocked
>
> You can't do impossible things:
>
> >>> c.shutter_speed = 1/33
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/Users/daniele/Repositories/camera/camera.py", line 29, in
> shutter_speed
> raise self.NonExistentShutterSpeed(f"Possible shutter speeds are
>   {possible_settings}")
> camera.NonExistentShutterSpeed: Possible shutter speeds are 1/4,
>   1/8, 1/15, 1/30, 1/60, 1/120, 1/240, 1/500
>
> But you can also do things that you shouldn't do, like opening the back
> of the camera in daylight with a partially-exposed roll of film inside -
> which will spoil the film::
>
> >>> c.back.open()
> Opening back
> Resetting frame counter to 0
> 'Film is ruined'
>
> I hope this interesting to someone.
>
> Daniele
> --
> https://mail.python.org/mailman/listinfo/python-list
>


-- 
+1-202-507-9867, Twitter @lcongdon
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[D.M. Procida]

Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.lang.python,
> D.M. Procida  wrote:
> > Eli the Bearded <*@eli.users.panix.com> wrote:
> >> I see you don't even attempt to tackle ISO outside of
> >> supported range (and I have no idea how the camera itself deals with
> >> that). Is the camera sensing the ISO from the film roll (so won't work
> >> with hand rolled film cartridges)? Is there a setting on the camera to
> >> manually specify that? (I don't think so.)
> > The camera's film speed setting (it's old enough that it's ASA rather
> > than ISO) is set manually. If you try to set an illegal value, there's a
> > setter decorator that raises a NonExistentFilmSpeed exception.
> 
> I can see what the code does, I'm asking what the camera does and do you
> plan to work that into your code? Maybe it only works for ISO 1600 in
> manual mode, but works.

The code does what the camera allows - the camera has a ring with film
speeds of 25, 50, 100, 200, 400, 800 marked on it; those are the values
you can select (in fact there are two unmarked steps in between each of
those, but I've yet to build those in).

Internally, moving the film speed ring slides contacts along a variable
resistor, which is part of the metering system circuitry. It could be
that the range of the resistor or the theoretical range of the circuit
is beyond the settable values, but I can't work that out from the
circuit diagram.

Daniele
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Eli the Bearded]

In comp.lang.python,
D.M. Procida  wrote:
> Eli the Bearded <*@eli.users.panix.com> wrote:
>> I see you don't even attempt to tackle ISO outside of
>> supported range (and I have no idea how the camera itself deals with
>> that). Is the camera sensing the ISO from the film roll (so won't work
>> with hand rolled film cartridges)? Is there a setting on the camera to
>> manually specify that? (I don't think so.)
> The camera's film speed setting (it's old enough that it's ASA rather
> than ISO) is set manually. If you try to set an illegal value, there's a
> setter decorator that raises a NonExistentFilmSpeed exception.

I can see what the code does, I'm asking what the camera does and do you
plan to work that into your code? Maybe it only works for ISO 1600 in
manual mode, but works.

> I have to add a button and winder lever to the camera object itself, I'm
> doing those things bit by bit.

Gotcha.

> Yes, it would be fun to allow it to "take a picture" of an image file,
> and process the result. Or ultimately built into a web application using
> somehting like https://anvil.works and have take a real picture with a
> user's webcam.

Yes, that sounds like good future work.

Elijah
--
bring light into the dark box
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[D.M. Procida]

Eli the Bearded <*@eli.users.panix.com> wrote:

> In comp.lang.python,
> D.M. Procida  wrote:
> > Hi everyone, I've created  -
> > a representation of a Canonet G-III QL17 in Python.
> > 
> > There's also documentation: .
> 
> This is interesting. Some feedback.
> 
> > 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.
> 
> There's a wealth of specifics for that camera above individual springs
> and levers. Notably how the light meter performs with different
> batteries and how it works with other films. This much is clear from
> just a few minutes research on the Canonet G-III QL17 (what a mouthful
> of a name).
> 
> I'm guessing you plan to deal light meter quirks because of the battery
> voltage setting. 

You're absolutely right. In fact, the camera is initialised with a
battery with a certain voltage, and eventually the voltage needs to make
a difference to the behaviour of the metering circuit. However I haven't
figured that out yet.

> I see you don't even attempt to tackle ISO outside of
> supported range (and I have no idea how the camera itself deals with
> that). Is the camera sensing the ISO from the film roll (so won't work
> with hand rolled film cartridges)? Is there a setting on the camera to
> manually specify that? (I don't think so.)

The camera's film speed setting (it's old enough that it's ASA rather
than ISO) is set manually. If you try to set an illegal value, there's a
setter decorator that raises a NonExistentFilmSpeed exception.
 
> Film spoilage isn't boolean in real life. If I rewind most, but not all
> of the way, before I open the back, I've only ruined a few frames. If I
> open it in a lightproof camera bag, I can take the roll out without
> rewinding.

I was going to settle for having the exposed frames ruined, if the
camera is opened in an environment of sufficient luminosity.
 
> On this camera, there's no manual double exposure setting, right? So
> partial rewind would be the way to do that. But I can make double
> exposures with this code:
> 
> >>> c.shutter.trip()
> >>> c.shutter.cock()
> >>> c.shutter.trip()

That's true - but only because I haven't yet finished adding the camera
controls. In normal use, you would only interact with the camera
controls, whereas c.shutter.trip() and so on are interacting with the
internal mechanisms.

I have to add a button and winder lever to the camera object itself, I'm
doing those things bit by bit.
 
> Does a camera like the one you have modelled that actively stop you from
> using a ISO/shutter speed/F-stop that will vastly over- or under- expose
> things? Or is it just a warning light in the viewfinder?

In A mode (shutter-priority autoexposure) it will simply not allow the
shutter to be tripped if the exposure is not within range. In manual
mode, there are no constraints.

> A useful thing your camera-as-code model could provide, but doesn't, is
> some measure of how exposed each frame is. This will be a function of
> film speed, iris setting, cumulative exposure time from zero or more
> shutter openings, and scene luminosity. (You could extend this to
> include opened back over exposure conditions.)

Yes, it would be fun to allow it to "take a picture" of an image file,
and process the result. Or ultimately built into a web application using
somehting like https://anvil.works and have take a real picture with a
user's webcam.

Thanks for the interest!

Daniele
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Eli the Bearded]

In comp.lang.python,
D.M. Procida  wrote:
> Hi everyone, I've created  -
> a representation of a Canonet G-III QL17 in Python.
> 
> There's also documentation: .

This is interesting. Some feedback.

> 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.

There's a wealth of specifics for that camera above individual springs
and levers. Notably how the light meter performs with different
batteries and how it works with other films. This much is clear from
just a few minutes research on the Canonet G-III QL17 (what a mouthful
of a name).

I'm guessing you plan to deal light meter quirks because of the battery
voltage setting. I see you don't even attempt to tackle ISO outside of
supported range (and I have no idea how the camera itself deals with
that). Is the camera sensing the ISO from the film roll (so won't work
with hand rolled film cartridges)? Is there a setting on the camera to
manually specify that? (I don't think so.)

> You can do things like advance the film, release the shutter, meter the
> scene with the built-in light meter (if the camera has a battery of
> course) and even spoil your film if you make the mistake of opening the
> back in daylight.

Film spoilage isn't boolean in real life. If I rewind most, but not all
of the way, before I open the back, I've only ruined a few frames. If I
open it in a lightproof camera bag, I can take the roll out without
rewinding.

(I've done such things with pin hole cameras.)

> But you can also do things that you shouldn't do, like opening the back
> of the camera in daylight with a partially-exposed roll of film inside -
> which will spoil the film::
> 
> >>> c.back.open()
> Opening back
> Resetting frame counter to 0
> 'Film is ruined'

If luminosity is set to zero, that could emulate the lightproof bag.
Frame by frame "film is ruined" might be a better choice for boolean.

On this camera, there's no manual double exposure setting, right? So
partial rewind would be the way to do that. But I can make double
exposures with this code:

>>> c.shutter.trip()
Shutter openening for 1/128 seconds
Shutter closes
Shutter uncocked
'Tripped'
>>> c.shutter.cock()
Cocking shutter
Cocked
'Cocked'
>>> c.shutter_speed = 1/512
>>> c.shutter.trip()
Shutter openening for 1/512 seconds
Shutter closes
Shutter uncocked
'Tripped'
>>>

In general, I never used simple cameras with light meters. Advanced SLR
or dumb cameras. My personal favorite film camera is a Universal Mercury
II, a half frame 35mm from mid 1940s with hot and cold shoes (intended
for flash and film meter attachments), bulb to 1/1000 shutter range,
mechanical exposure calculator on the back, and a dial for reminding you
what film you have in it.

Does a camera like the one you have modelled that actively stop you from
using a ISO/shutter speed/F-stop that will vastly over- or under- expose
things? Or is it just a warning light in the viewfinder?

Certainly my c.shutter.trip() calls give me no advice from the meter.

A useful thing your camera-as-code model could provide, but doesn't, is
some measure of how exposed each frame is. This will be a function of
film speed, iris setting, cumulative exposure time from zero or more
shutter openings, and scene luminosity. (You could extend this to
include opened back over exposure conditions.)

Elijah
--
can see how this might get integrated with an image generation tool
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[D.M. Procida]

Robert Latest  wrote:

> D.M. Procida wrote:
> > Hi everyone, I've created  -
> > a representation of a Canonet G-III QL17 in Python.
> 
> [...]
> 
> > The Canonet G-III QL17 is one of my favourites. One of my reasons for
> > writing this code is to appreciate the intricate mechanical logic
> > embodied in the machine.
> 
> I love both photography with mechanical camears (The Nikon FE2 being my
> favorite) and programming. 

Yes, it's more fun to compute.

> So I absolutely love your project. Also I think its
> totally nuts. 

Thanks, I will take that as a compliment.

Daniele
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: A 35mm film camera represented in Python object

[Robert Latest via Python-list]

D.M. Procida wrote:
> Hi everyone, I've created  -
> a representation of a Canonet G-III QL17 in Python.

[...]

> The Canonet G-III QL17 is one of my favourites. One of my reasons for
> writing this code is to appreciate the intricate mechanical logic
> embodied in the machine.

I love both photography with mechanical camears (The Nikon FE2 being my
favorite) and programming. So I absolutely love your project. Also I think its
totally nuts. I won't spend a second looking at your code or get otherwise
involved, but I wish you best of luck!

robert
-- 
https://mail.python.org/mailman/listinfo/python-list

A 35mm film camera represented in Python object

[D.M. Procida]

Hi everyone, I've created  -
a representation of a Canonet G-III QL17 in Python.

There's also documentation: .

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 spend quite a bit of my time repairing old cameras. To me they feel
like computer programs encoded into physical objects, and figuring out
how a mechanism works feels like working out how code works (but more
fun).

The Canonet G-III QL17 is one of my favourites. One of my reasons for
writing this code is to appreciate the intricate mechanical logic
embodied in the machine.

You can do things like advance the film, release the shutter, meter the
scene with the built-in light meter (if the camera has a battery of
course) and even spoil your film if you make the mistake of opening the
back in daylight.

>>> from camera import Camera
>>> c = Camera()

>>> c.state()
== Camera state =

-- Controls -
Selected speed:1/120

-- Mechanical ---
Back closed:   True
Lens cap on:   False
Film advance mechanism:False
Frame counter: 0
Shutter cocked:False
Shutter timer: 1/128 seconds
Iris aperture: ƒ/16
Camera exposure settings:  15.0 EV

-- Metering -
Light meter reading:4096 cd/m^2
Exposure target:15.0 EV
Mode:   Shutter priority
Battery:1.44 V
Film speed: 100 ISO

-- Film -
Speed:  100 ISO
Rewound into cartridge: False
Exposed frames: 0 (of 24)
Ruined: False

-- Environment --
Scene luminosity:   4096 cd/m^2

>>> c.film_advance_mechanism.advance()
Cocking shutter
Cocked

>>> c.shutter.trip()
Shutter opens
Shutter closes
Shutter opened for 1/128 seconds
Shutter uncocked

You can't do impossible things:

>>> c.shutter_speed = 1/33
Traceback (most recent call last):
  File "", line 1, in 
  File "/Users/daniele/Repositories/camera/camera.py", line 29, in 
shutter_speed
raise self.NonExistentShutterSpeed(f"Possible shutter speeds are
  {possible_settings}")
camera.NonExistentShutterSpeed: Possible shutter speeds are 1/4, 
  1/8, 1/15, 1/30, 1/60, 1/120, 1/240, 1/500

But you can also do things that you shouldn't do, like opening the back
of the camera in daylight with a partially-exposed roll of film inside -
which will spoil the film::

>>> c.back.open()
Opening back
Resetting frame counter to 0
'Film is ruined'

I hope this interesting to someone.

Daniele
-- 
https://mail.python.org/mailman/listinfo/python-list