Best way to display "video" images in web app?

I am writing a web application to display images from a thermal imaging camera. I would like the application to display either static images (for example “get a current image”) or a real-time stream (up to 9 fps ideally although I could live with less and understand network latency would have to be considered). The use case is local (cameras + app + users are on the same network). The App connects to the camera(s) via a socket interface, takes their data and converts it to a false-color image for display in the web browser.

I have code running using a webcanvas. I looked back at the forums to find ideas and found a lot of discussion in about 2014 but not a lot since. Currently the app renders to a picture and the picture is drawn in the webcanvas paint event. The app causes a refresh event on any attached session connected to a camera that generates a new image by calling a method in the session (the method refreshes the webcanvas in the session’s webpage).

However it appears the browser is caching a copy of each picture (determined using the developer tools in chrome). This seems problematic for the display of image streams (could be many thousands or ten thousands of images streamed in a session).

I am a hardware developer primarily and my knowledge of web software development is pretty much nil (that’s why I use xojo!) so I may not even be correctly stating my request/concern.

It seems to me that I don’t need the browser to cache anything (except, perhaps the last image) since each image is unique and won’t be repeated. Is there a best way to implement such a display? Or does the browser automagically handle/limit caching and I shouldn’t worry about it at all?

Issues with caching like this are normally solved in the web world by adding an additional parameter to the URL of the resource you are loading. As an example, when you want to make sure you have the newest version of an image file, instead of accessing:

https://mydomain.com/images/image1.png

You might use the URL:

https://mydomain.com/images/image1.png?v=<CurrentTimeInMilliseconds>

Where <CurrentTimeInMilliseconds> is the actual current ms time value.

What does your image loading code look like? Are you using a WebCanvas or WebImageViewer? Are you first saving these still frames to your server?

I would probably process the frame, save it, then load it in to a WebImageViewer using a WebFile and appending the unique timecode parameter to the URL before setting it to the URL property of the WebImageViewer.

1 Like

It’s also worth noting that, depending upon the camera, it may provide a means of accessing its stream directly. You could then use a WebHTMLViewer and set its URL property to the URL of the stream.

Thanks for the reply, Anthony. This is a custom camera and it only outputs radiometric data that has to be converted into a visual image.

Anthony, I’m sorry I missed this reply. I am using a webcanvas. I have tried two different approaches with it but both have the same result: A bunch of “picture.png” files get cached.

One approach has the Paint event in the webcanvas calling a routine which takes some data from a structure associated with a camera and converting it to RGB pixels which it draws to its graphics.

The second approach has code running in the App converting the camera data into a picture and then notifying the webcanvas to Refresh. In this case its Paint event just draws the picture itself.

I don’t necessarily save all the camera images to files so the solution must work from data in memory.

I don’t want any caching at all, since once replaced, an image will never be drawn again. And, of course, I want some amount of performance. Even running with the browser on the computer that the App is running on, I can barely manage 2 updates per second and there’s a lot of flickering (unlike using a canvas on a desktop app).

It seems to me that a custom control could be made using the WebSDK but this is far beyond my abilities.

Forum for Xojo Programming Language and IDE. Copyright © 2021 Xojo, Inc.