capture_preview is slow / opens up the shutter

[sontek]

I have code in piggy photo for using liveview to give a preview of what the camera is showing:

self.camera = piggyphoto.camera()
self.camera.leave_locked()
cf = self.camera.capture_preview()

and this is instant and I can basically use it as a webcam from the SLR. With gphoto2 cffi I tried the same thing and its extremely slow as it retakes the photos everytime:

self.clist = gp.list_cameras()
self.cam = self.clist[0]
preview = self.cam.get_preview()

Do you know why gphoto2-cffi requires the shutter and everything to get a preview where as piggyphoto can leave it open?

[jbaiter]

This is really curious, since I'm using the exact same function in the C API that piggyphoto does (gp_camera_capture_preview, piggyphoto, gphoto2-cffi).

The only difference I can see is that we are freeing the camera resources after every call, while piggyphoto does so only when leave_locked has not been called.

Can you edit the gphoto2.py file on your machine and remove the @exit_after in line 733 and see if this has any effect? Removing it causes the camera resources not to be freed after the capture, so this way we can see if this is related.

If so, I'll gladly add a keyword argument with similar semantics to leave_locked() to the get_preview() API!

[happy77]

I had the same issue with my Nikon D7200. After commenting out all @exit_after it works like expected. +1 for a leave_locked like behaviour.

[johker01]

@jbaiter I'm experiencing the same problem as @sontek and @happy77. Removing the @exit statement in line 743 definitely solves the problem. Is there any chance you could implement the "leave_locked" behavior you mentioned into gphoto2cffi?
Alternatively, would removing the @exit_after from the get_preview method and instead calling exit_after() explicitly after being done calling get_preview in a row result in a similar/the same behavior as the "leave_locked" behavior mentioned above? When reading the gphoto2 documentation for gp_camera_exit it seems like a good idea to call it after executing any camera function (http://www.gphoto.org/doc/api/gphoto2-camera_8c.html#a6f19c4ea385641fb972e779badf48ae1).

[jbaiter]

Thank you both for the confirmation!

Is there any chance you could implement the "leave_locked" behavior you mentioned into gphoto2cffi?

Absolutely, unfortunately I currently don't have my cameras with me, but will have an opportunity to get my hands on them again in two weeks. I'll cook up a solution until then and release it when I was able to test it.

Alternatively, would removing the @exit_after from the get_preview method and instead calling exit_after() explicitly after being done calling get_preview in a row result in a similar/the same behavior as the "leave_locked" behavior mentioned above?

It would, however I don't like the ergonomics of that :-) I'm thinking of adding a leave_locked method that would allow you to operate within a context manager and gp_camera_exit is only called once the context is closed. Something like this:

with cam.leave_locked():
    for i in range(100):
        cam.get_preview()

[johker01]

It would, however I don't like the ergonomics of that :-)

I totally agree with you. It's an ugly workaround, not a solution.

I'm thinking of adding a leave_locked method that would allow you to operate within a context manager and gp_camera_exit is only called once the context is closed.

Sounds like a sound solution to me.

[johker01]

This should be fixed now, right? See #21