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

[Robert Hailey <cheese osndok com>]

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:

https://github.com/Osndok/docsnap

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.
> >
> > JN
>
> 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:
>
> > Hello,
> >
> > 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),
> >     NULL);
> >
> >
> > 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:
>
> libcheese/cheese-camera.c:122
>
> >  caps = gst_caps_new_simple ("video/x-raw-rgb",
> >                              "bpp", G_TYPE_INT, 24,
> >                              "depth", G_TYPE_INT, 24,
> >                              NULL);
> >  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