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