A fix to this bug will be included in the next release (2.9).

I can confirm that this really is the case. In fact, adding that declaration seems to cause a crash. This is undoubtedly a bug we need to investigate more. Thanks for reporting.

For the time being, you need to find a work-around for example by using a matrix as input. It is definitely not convenient, but at the bottom, strings are just sequences of numbers.

To declare an input parameter as a string, you can say e.g. FIXED_INPUT(kuvio_string, fileName, ""). Your function will receive the string as a UTF-8-encoded const char*.
The only way to create dynamically typed arrays from C is currently kuvio_array_from_json. Dynamically typed arrays aren't really intended to be used in processing. Few tools can actually make use of them, Script being perhaps the only useful one.
If you want to output an array of numbers or Boolean values, the correct data type to use is a matrix. For example, the ConvexHull tool in the OpenCv example plugin declares a matrix output: OUTPUT(kuvio_fmatrix, hull). The convention is to use a 1×N matrix if you need to output a vector of numbers.

Great
We may consider making zero the default frame rate in a future release. It could be the least surprising value after all.

Hi,
The easiest way to read images from files is to set up a virtual camera in the Virtual Camera ribbon of the Builder. You can select the images there. Then, pick your virtual camera from the drop-down list of the Camera Id input parameter of an Image Source tool.

All images passed between tools must be allocated by the platform. Therefore, you cannot directly return an image that is allocated by an OpenCV function. Otherwise the platform wouldn't be able to correctly deallocate it when it is no longer needed.

What you can do is to allocate a new output image using for example kuvio_image_alloc_copy and then copying the data from the image allocated by an OpenCV function call. If you place that image to the out struct of your custom tool implementation, you get the picture out.

Thanks for the clarification. When handling bug reports, it is important that we understand exactly what happened. In our parlance, a "crash" means that the software goes down in flames. If makes a difference if the processing graph stops because of an internal error. Furthermore, it is important to know the exact steps you took so that we can reproduce the bug. Since you were posting this on the Application Builder forum, I thought this applied to it only.

We agree that the stepping feature in the Builder needs to be improved, and we are working on that. When it comes to watching folder contents while running the app in the Engine, we need more details about the configuration of the virtual camera. Can you post a screenshot of camera settings in the camera configurator? This feature is automatically tested and we believe it works in general.

The triggerTimeout parameter has no effect on this. If you are triggering the image source with another tool, the camera will be put to software trigger mode and folder watching won't work. Maybe you haven't changed the default frame rate of the virtual camera? If the frame rate is non-zero, the virtual camera will loop though images that exist in the folder at start-up.

Edit: Actually, new images will be added to the loop, but if the folder is empty at start-up, no images can be found and the first timed trigger fails, causing a run-time error.

To change the default frame rate, open the virtual camera in the camera configurator and change the frame rate to zero. Then save the settings and assign the saved parameter set to the camera.

First, I'd like to make sure what you mean by "crash". The software should definitely not crash, and if it does, this is a serious bug. We were however unable to reproduce the problem without additional information.

If you mean that the analysis engine stops, this is planned behavior. In the AB, you are single-stepping the program, which makes all image sources essentially software-triggered. If you click "next" or activate the continuous play mode, the AB is forcing all data sources to fetch the next item. If there are no images in your virtual camera folder, all the tool can do is to fail. In this case, the designed behavior is to stop en engine and show an error message.

The way single-stepping is handled by the AB will change in VisionAppster 3.0. Meanwhile, you need to live with the fact that the AB doesn't allow data sources to produce data asynchronously.

Thanks for the info. We'll address this and other OpenGL related issues in 2.8.2. Meanwhile, you can try if the software rendering solution above helps you to get going.

Thanks for the report.

It looks like our software is unable to find a hardware-accelerated implementation of OpenGL in your machine. There are two possible causes for this:

1. Your system has no hw-accelerated OpenGL 2.0 implementation available.
2. There is an implementation, but our software doesn't find it.

To rule out 1), you may want to run either of these programs to see if OpenGL is supported by your graphics card driver:

• http://www.ozone3d.net/gpu_caps_viewer/
• http://realtech-vr.com/admin/glview

If the graphics card driver supports OpenGL 2.0, we'd like to know the exact model and driver version to inspect this further.

As a band-aid, you may try enabling software rendering. But please be aware that this makes UI rendering slow. Unzip this file to the bin directory under your installation (e.g. C:\Program Files (x86)\VisionAppster\bin) :

https://download.visionappster.com/windows/x86/angle-opengl-libs-x86.zip