Group Details Private

administrators

  • RE: Initializing after restart

    @ms I came back to this when running release tests with our new release.

    The simplest thing you can do is to explicitly disconnect the ctrl object on error:

    async function test() {
        let ctrl; // move declaration here
        try {
            const va = typeof window === "object" ?
            VisionAppster :           // Browser
            require("visionappster"); // Node.js
            const inputs = [
            await va.Image.fromUrl('image.jpg')
            ];
            ctrl = new va.RemoteObject("http://localhost:2015/apis/com.myapps.testapp/1");
            const api = await ctrl.connect();
            await api.sendImage.async(...inputs);
            console.log('Success.');
        }
        catch {
            console.error("Failed.");
            ctrl.disconnect(); // add this
        }
    }
    

    It is hard to do this automatically because JS is a garbage-collected language with no destructors. When the app on the server side is brought down, its control channel remains because no one called disconnect() on the client side. The JS runtime can keep the old instance alive arbitrarily long. Since there is a reference to the WebSocket instance, the connection will remain active as well.

    Now, when you create a new RemoteObject instance, it shares an existing connection by default (you are using the default mechanism). This time however the existing connection is defunct. The old server-side object does not exist any more although there is a new one in the same URL.

    The channel sharing mechanism could be improved to take the remote object ID into account, but that would be a rather invasive change now. The work-around is quite simple and I hope it will work for you for the time being. We'll come back to this during the next release cycle.

    -Topi-

    posted in Engine
  • RE: Properly display image source in the browser with JavaScript API

    There is a very good reason for not enabling CORS by default. If you run the Engine on your local machine with CORS enabled, it will let JavaScript code on any web page to make requests to your server. If you are aware of and accept the risk, see here: https://doc.visionappster.com/latest/engine/configuration.html#cors

    Bottom line: if you serve your HTML page from another HTTP server (not from the Engine itself), you need to take care of cross-domain security issues.

    Please note that using a custom server-side script will not be a solution to this problem.

    Media types and image formats are independent. You can handle both compressed and raw images in your application. In both cases, the data type will be Image. The media type only plays a role once you pass an Image through the network. By default, our protocols use a custom binary encoding, which can en/decode any type of an image. It requires a client library (which you are using).

    If mediaType (or the Content-Type request header) is set to image/jpeg the image is encoded as JPEG. This makes it easier to handle the image in many applications, but the encoding may lose data.

    posted in Engine
  • RE: Properly display image source in the browser with JavaScript API

    Sorry, but I don't quite get what you are trying to achieve. You only need server-side (e.g. Node.js) code if your application requires image processing in the back-end.

    Drawing pixels on the canvas in the browser requires careful handling of different RGB types and endianness. Please see the Image.toImageData() function. I'd however recommend using <img> instead. The cookbook recipe you are referring to uses <canvas> and toImageData(). Please let me know if that solves your problem.

    posted in Engine
  • RE: Properly display image source in the browser with JavaScript API

    It seems you have received the Image object and it was decoded successfully. There is something on the canvas as well, but it is hard to say what it is. Maybe you tried to draw a color image as RGB or vice versa? It looks like that there is at least a row alignment issue there.

    The easiest way to display an image on an HTML page is to use an <img> element:

    <img id="img-id">
    ...
    obj.$image.connect(image => image.toHtmlImage(document.getElementById('img-id')));
    
    posted in Engine
  • RE: MIPI Cameras

    In principle, yes. But unfortunately nothing that would just work out of the box. To be able to use all features of the camera you need a proper camera driver. On Linux this means either V4L2 or GenTL. The former requires a kernel module, the latter takes no stance. It can in principle be implemented in user space e.g. through command-line tools. You can create a custom GenTL driver as outlined here: https://doc.visionappster.com/latest/cameras/drivers/ The process is however quite tedious unless you are familiar with the intricacies of GenICam.

    Another option is to create a custom tool for the purpose of getting images from the camera. Currently, this is only possible in C or C++ (see https://doc.visionappster.com/latest/api/tool/c/), but the next release will come with Python support.

    posted in Raspberry Pi
  • RE: Where do you get Builder? (for Mac)

    I see. The Docker image only contains the Engine. To run the Builder on Mac, your only option is to use a virtual machine and use either the Windows or the Linux binary.

    The Builder (and the Engine) actually do run on Mac, but Apple's SDK licensing terms prohibit building native extensions on non-Mac hardware. Since such extensions are the whole point of our business, Mac users are crippled. It is a big bummer, but nothing we can change.

    posted in Builder
  • RE: Where do you get Builder? (for Mac)

    The "VisionAppster" software distribution contains the Builder. The installer will ask you if you want to install a local instance of the Engine as well. All installers are available at https://download.visionappster.com/.

    The fact that you need to ask tells me that we need to improve our message. Thanks for the question!

    -Topi-

    posted in Builder
  • RE: ARM Docker Image

    Hi,

    Merged the ARM repository to the main repo. Now both 32 and 64 bit ARM images can be found from https://hub.docker.com/r/visionappster/va-engine

    posted in Raspberry Pi
  • RE: ARM Docker Image

    Hi,

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

    posted in Raspberry Pi
  • RE: (beta3) Remote camera "404"

    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.

    posted in Builder