Results 1 to 4 of 4

Thread: Official OpenVX 1.0.1 specification feedback thread

  1. #1
    Administrator khronos's Avatar
    Join Date
    Jun 2002

    Official OpenVX 1.0.1 specification feedback thread

    The Khronos Group today announced the ratification and public release of the OpenVX™ 1.0.1 specification, a maintenance update to the open, royalty-free standard for cross platform acceleration of computer vision applications. OpenVX 1.0.1 integrates bug fixes and clarifications resulting from feedback from working group members and the wider industry implementing and using the specification. OpenVX enables performance and power-optimized computer vision processing, especially important in embedded and real-time uses cases such as face, body and gesture tracking, smart video surveillance, advanced driver assistance systems (ADAS), object and scene reconstruction, augmented reality, visual inspection, robotics and more. In addition to the OpenVX conformance tests and Adopters Program launched in late 2014, Khronos is now shipping an open source, fully-conformant CPU-based implementation of OpenVX 1.0 that runs on Linux, Android or Windows. The full OpenVX 1.0.1 specification and details about the sample implementation are available at

    Full Press Release

    We'd like to hear what you think about this new API.

  2. #2
    Join Date
    Jul 2015
    Austin, TX
    Is there a "Release Notes" section with a concise list of what changed between 1.0 and 1.0.1? If not, it would be very useful in future releases. Thanks.

  3. #3
    Junior Member
    Join Date
    Oct 2014
    here comes a bit of nitpicking on the formulations in the standard:

    1. The datatype of the data returned by vxAccessDistribution is a bit unclear.
    The docs of vxCommitDistribution suggest that it is vx_uint32, but sample
    implementation uses vx_int32? If vx_uint32 is the only alternative, why void
    pointers instead of vx_uint32 pointers?

    2. In the description of vxAccessLUT it is first claimed that ptr=NULL is a
    valid input. Then further down it is claimed that is is not. Which is the

    3. The description of vxCommitLUT does not make much sense. The two cases seem
    more like general comments than two distinct cases.

    4. The only valid threshold data_type is vx_uint8 but the datatype of
    VX_THRESHOLD_ATTRIBUTE_THRESHOLD_VALUE and friends is vx_int32. Wouldn't it
    make more sense to let VX_THRESHOLD_ATTRIBUTE_DATA_TYPE
    define the datatype of those attributes?

    5. In vxAccessArrayRange, the ptr argument is declared as out only it should
    probably be in, out.

    6. In vxAddArrayItems it is calimed that "By default, the function does not
    reallocate memory". That suggests that there is some way of getting it to
    reallocate memory and increase the array capacity, i.e. by setting some
    parameter to a non-default value. Is that the case?

    7. In vx_kernel_output_validate_f there is a parameter called meta in the
    declaration at the top, but in the list of parameters below it is referred to
    as ptr.

    8. The output of a MagnitudeNode has to be a S16 Image, but in the initial
    example on page 12, an U8 Image is used.

  4. #4
    Join Date
    Sep 2015

    Test case no 8 fails in sample implementation

    If I run vx_test then 20 out of 21 test pass. The test number 8 [Framework:Kernels] fail. It is because the kernel name. It should be org.khronos.openvx.box_3x3 in place of org.khronos.openvx.box3x3 at line 725

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Proudly hosted by Digital Ocean