Re: Image capture triggers a focus event at the worst possible time [solved]

For the googlers and/or posterity (as well as one who asked for an
update off-thread), I would like to dig up this slightly-old
thread to have "on record" what I finally arrived to as a solution.
Unfortunately, it required a move away from cheese.

Since I found that "camorama" did not have this same issue (which I
further discovered was due to its "save from the viewfinder's data
buffer" pattern which is simpler but arguably less correct than
the "switch to high-res only for the image capture" pattern that
cheese's underlying library [gstreamer] uses), I decided to hack out a
new micro project from camorama.

The modifications and it's basic operational theory are simple:
* it uses the full/native resolution video mode for the view finder (to
  avoid the aforementioned mess, but results in much higher cpu usage),
* its UI window serves as a view finder for my other/cli app,
* it captures on a USR1 signal, and
* it prints out the file name it saved to

Right now it's really hackish & kludgy. I'm sure that someone else
could do better (hint, hint), but for those interested this is the url:

Like I said, just an FYI... so let it be known, and have a nice day!

Robert Hailey

On Fri, 18 Mar 2016 12:15:05 -0500
Robert Hailey <cheese osndok com> wrote:

On Mon, 14 Mar 2016 17:20:28 +0000
John Nash wrote:

If you find anything more, keep in touch. I'll try to find the
communication re: UVC codes.


So... I found out that when this particular camera "changes
modes" (in such a way that is barely within Cheese's reach; see below)
it triggers an auto-focus.

On Fri, 18 Mar 2016 09:10:43 +0100
Dimitrios Katsaros <patcherwork gmail com> wrote:


The camerabin in its self does not have support for autofocus, at
least none that I am aware of. Are you using v4l2src with
wrappercamerabinsrc? If that is the case I would suspect that the
problem is renegotiation on capture. When a new capture is
performed, the pipeline is dynamically changed to feed the image
output path. That procs a renegotiaion. If the caps on the
video/image output are different than the viewfinder, a new set_fmt
is performed in v4l2, which resets the v4l2 controls and in turn
resets the focus. to verify/fix that you can do something like:

  g_object_set (camerabin_object,
    "viewfinder-caps", gst_caps_from_string(caps),
    "image-capture-caps", gst_caps_from_string(caps),
    "video-capture-caps", gst_caps_from_string(caps),

Make sure the caps string is the same for all 3.

I am sort of able to work around the issue by using a "pristine"
version of libcheese from fedora rawhide, but if I change either of
the capture resolutions (even if I change it back!) the focus bug
pops up again.

This is a bit to precarious to be in my workflow, so I'm going to try
and find a solution derived from camorama (which has it's own
problems but does not exhibit this behavior).

Apart from a "keeping the caps string perfectly the same" feature,
this might be closer to the fault:


 caps = gst_caps_new_simple ("video/x-raw-rgb",
                             "bpp", G_TYPE_INT, 24,
                             "depth", G_TYPE_INT, 24,
 g_object_set (G_OBJECT (priv->camerabin), "preview-caps", caps,
NULL); gst_caps_unref (caps);

I'm not sure exactly why this would be needed here (in the take-photo
function), but this mode change might actually be what is causing the
refocus (it's hard for me to tell, because I have yet to successfully
compile cheese and there is no option/flag/environment-variable that
bypasses this signal).

Robert Hailey

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]