Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#60 vfw enable video dialogs

open
spadix
None
5
2014-08-16
2011-06-27
Jarek Czekalski
No

On my box capDlgVideo dialogs work fine and let me choose the resolution and other parameters of zbar video capture. It would be good to be able to open this dialogs with zbarcam switches. I suggest:
--vfw-display-dialog (although I don't know this one as my driver has no such capability)
--vfw-source-dialog
--vfw-format-dialog
--vfw-dialogs (start all the 3 dialogs if possible)

Discussion

  • The attached patch introduces the following zbarcam switches:

    --vfw-dlg-all
    --vfw-dlg-source
    --vfw-dlg-format
    --vfw-dlg-display

    --vfw-dlg-all and --vfw-dlg-format imply --no-probe. Thus calling

    zbarcam --vfw-dlg-format

    is a quick way to choose the format manually and start zbarcam.
    After setting the format calling

    zbarcam --no-probe

    is suggested.

     
  • requires no_probe patch

     
    Attachments
  • spadix
    spadix
    2011-07-12

    • assigned_to: nobody --> spadix
     
  • spadix
    spadix
    2011-07-12

    Adding platform (and esp driver) specific entry points is not a good precedent to set.

    If the API must be enhanced to support this, we need to backup and at least attempt the design work: first investigate across platforms and interfaces to see how the same concept is implemented elsewhere, then, thinking from an application's perspective, design a generic interface that will cleanly scale to support more than just the immediate need. For instance, v4l2 and DShow both handle device specifics with a "controls" concept that the application can use to build similar dialogs... Obviously we don't need to implement everything now, but we should know where we expect them to fit in when we get there.

    Next, the processor should avoid simply exposing every detail from the lower layers. The point of the processor layer is to give a simple non-UI application/script writer an easy way to add the reader to their application. At this level it probably makes sense to have a generic concept of built-in, user-driven camera selection and control. Again, we should ignore implementation details (VfW) and consider what makes sense to this type of application, then see how VfW fits into that picture.

    Also keep in mind that barcode applications don't need to be graphical. Consider a fixed camera installation where barcodes are presented to the cameras in known locations, either manually (eg, a library) or automatically (a processing line) (fwiw we have users doing both of these). In these cases there are no preview windows and initialization should be completely automatic (implying that VfW is out already...)

    Obviously I have my own ideas about where this is going, but I'll let you think about it and come up with your own proposal before I poison your fresh perspective with my implementation opinion :P

     
  • We agree that VfW should be considered only a transitional solution. Inability to query device capabilities disconnects it from the vision you have. So I don't follow the vision thread you started. Any processor methods introduced only to support VfW should be commented with "may be removed in future versions of zbar". But at the moment, while it is the only way of seeing camera configuration capabilities, I still vote to introduce it.

    All my VfW patches, including this about dialogs, do not conflict with the current processor usage. No one is forced to use the dialogs nor other vfw switches. But if one wants to tune his application to be a bit more usable under windows, he can still do it through processor commands. If you do not introduce these dialogs, I imagine developers should add a comment in their manuals: to configure your camera in a detailed way, you have to find a third party application capable of showing vfw dialogs.

    (Hey, there's a new idea then: if you can't accept vfw dialogs options, you may consider including a separate app in zbar distribution.)

    With the examples you gave, a library and a processing line, it's a good level to keep the discussion at. So I imagine it this way:

    First zbar processor is run with default settings. It should be enough. But if something goes not the way it should, a technician can look inside the device capabilities through the VfW dialogs. There he can experiment with different settings. Finally he wires configuration settings which refer to --prescale and --infmt zbarcam switches (I don't remember their processor equivalents) in his application configuration. Daily usage does not pop up any gui windows.

    I don't really think VfW or windows should be applied in environments requiring robust solutions. Linux wins there at least by the price argument. But VfW may be widely used in home applications, like the one I am working on. And in home environments (and in office environments as well) such dialogs would be appreciated.

     
  • spadix
    spadix
    2011-07-20

    > I don't follow the vision thread you started.

    Sorry, I will try to be clearer.

    > processor methods introduced only to support VfW

    No, we're definitely not hacking the API. Here is alternative way to access VfW dialogs from the processor that would work for me:

    The VfW dialogs are opaque camera controls provided by the driver. This actually fits right in with the v4l2 and DirectShow "camera controls" concept. That these happen to be driver-controlled GUI elements doesn't matter; from a control perspective all you can do is allow the user to "activate" them, just like "autofocus now" or another one-shot control.

    So I propose that we add a way to expose generic user-driven camera controls at the video layer. A "control" at this level is an object that has a string name shown to the user, the value type (one-shot/activated, range, enumerated, etc) and maybe a grouping hint of some sort. Basically look through the other cases and figure out the minimum an application would need to create a nice interface. At this time we need only define the one-shot controls, but the mechanism should be designed to scale appropriately.

    The video API would need a way to enumerate the controls and interact with the values. For VfW, each of the available dialogs would be exposed as a control. The other drivers can just be stubbed out (no controls available) for future enhancement.

    Moving up to the processor, we need only one entry point to "present(/dismiss) the camera control interface to the user". Eventually, this could build a platform-specific dialog (or overlay) based on the available video controls. For now (until the other video interfaces support controls) you could just hack it to automatically activate all of the available one-shot controls.

    You can also bind this method to a new processor hot-key, so the user can access without resorting to command switches.

    If you prefer, I can even make some time to block out what these new APIs should look like.

    > consider including a separate app in zbar distribution.

    Using an external VfW helper is also a good idea.

    > I don't really think VfW or windows should be applied in environments requiring robust solutions.

    I'm totally with you there. And yet; Exchange... IIS...

     
  • requires no_probe_patch

     
    Attachments
  • I just submitted a small fix, but that was before reading your new post. I'll have to think it over, but from the first glance it looks reasonable.