Hi,

3.0-beta4 is out with an official ARM Docker image: https://hub.docker.com/r/visionappster/va-engine-linux-arm_32

Sorry, I forgot the port in my answer. I'm however a bit puzzled by the log. The camera ID remote:http://192.168.2.59:2015/ webcam:video0 seems correct to me, but the log indicates an connection attempt was made to an URL without the slash after ":2015".
To make sure that the hardware gave the name "video0" to your camera, enter the URL http://192.168.2.59:2015/cameras/webcam%3Avideo0/ to a browser. If that works (you should get a directory listing), try re-entering the value shown in the picture. It should work.

Thanks for the report! We were able to reproduce the issue. It is a regression related to a fix in encoding camera IDs for the web page. We'll include a fix in the next release.

Meanwhile, to work around it in the Builder, you may manually enter a non-encoded camera ID to Image Source. For example, remote:http://192.168.0.1 webcam:video0. That is, decode %3A to :. If the camera URL contains other encoded characters, undo percent decoding for them as well.

We currently have an official Docker image for x86_64 only. For ARM, there is a Raspberry Pi image.

We however internally build Arch Linux packages for 32-bit and 64-bit ARM. The plan is to publish these and other binary packages in AUR. We'll also provide official Docker images for ARM. They will be built out of the Arch packages and an Arch base image such as this.

The schedule is still a bit open. If everything goes well, the new binary packages will be included in the next release in May.

Hi! I have to say this was totally unexpected. The history came haunt me. But thanks for your kind words.

Unfortunately, Defect Guard died with the company that created it. There are still a couple of installations running, but we couldn't make it work financially. I bet the simulator can still be found in the net somewhere, but VisionAppster is not in the business of web inspection.

That said, if there is enough demand, somebody may some day put a similar product on sale at visionappster.com or publish the original source code. Stay tuned.

BR,
Topi

We are welcoming all feedback related to the upcoming Python API. What kind of an API would you want to see? Which libraries should be included? NumPy and OpenCV will be included, but which other libraries would you like to have?

Here's a sneak peek of what is coming out:

import visionappster as va

class Binarize:
    """Binarizes an image using a static gray-level threshold.
    """

    def level_min(self):
        return 0

    def process(self,
                inputs: {'image': va.int32,
                         'level': {'type': va.int32,
                                   'min': lambda: self.level_min(),
                                   'max': 255,
                                   'default': 127}},
                outputs: {'image': {'type': va.Image,
                                    'imageType': 'raw'}}) -> va.int32:
        # Implementation here: read inputs and write to outputs
        return va.SUCCESS

tools = [Binarize]

This is intentional. The JavaScript API hasn't stabilized, and we didn't want to publish the details yet. If you are OK with a breaking your app when upgrading, here's how you get a list of functions and definitions available to JS code in the JavaScript tool:

for (var i in VisionAppster)
  print(i);

If you put this code to a JavaScript tool and run it, you'll see all API entries in the console.

For example, this creates a new color image:

var img = VisionAppster.image(640, 480, VisionAppster.Rgb32);

When it comes to using external libraries, the answer is yes in principle, but the feature isn't publicly available. Integrating something like Node.js modules may or may not be supported in the future.

Nothing to be sorry about. This is really valuable feedback to us. I cannot directly tell what's going on, but we are trying to reproduce the problem in a controlled setting. The two issues could indeed be related. Thanks for reporting.

I see. While I'm still unsure which part of the whole pipeline is failing, this is a good description that will help us dig it deeper. Thanks for reporting.

It's hard to say exactly what happens. But I wonder if this is what you actually wanted to do. When you call the MyInput function, JavaScriptMyInput gets executed. The results will be passed back to your client code using a callback function. This is how tool function APIs work, please see here for details.

The outputs of the tool that is exposed as an API function are available to the processing graph. In your case, they will trigger the rest of the graph, producing a signal at the end. If clients connect to this signal, they will be delivered whatever comes out of the pipe independent of who triggered the graph. Thus, there is no 1:1 correspondence between what you sent to what you receive.

Another thing that may cause a discrepancy is your script code at the end. If it does not set the output parameter, it will not be sent. In this case, the parameter must be flagged asynchronous.

What you probably want to do is to bundle your graph into a single compound tool and make that a function API.