2. Context

There are two distinct usage scenarios for frontend-backend configuration in CARTA. Firstly, when used as a desktop application, the frontend and backend both run locally. The backend is run as an application that communicates with the frontend, which is presented to the user as a desktop application in the form of an Electron-wrapped web view [1].

The second usage scenario is that of a remote viewer, where the backend is running on a remote server, while the frontend is loaded in the user’s browser of choice (as long as that choice is Chrome, Firefox, Safari or Edge) by visiting a URL associated with the remote server. A third possible configuration is running the desktop Electron application, while connecting to a specific server IP for remote data. This is not a high priority, as most usage scenarios would be better handled through accessing the frontend through a remote URL.

In both of these scenarios, communication between the frontend and backend takes place over a standard WebSocket [2] communication channel, with message formats defined using protocol buffers [3], based on the message structures defined in Section 4.1.

Image data is sent to the frontend as either uncompressed or compressed floating point data. The frontend can request which type of data is sent from the backend, which compression library to use, and what compression quality to use. Two lossy floating-point compression libraries are supported in the ICD: ZFP [4] and SZ [5] (although SZ is not implemented at this point on either the frontend or backend). A general investigation of the compression performance of these two libraries shows that ZFP is consistently faster, while SZ offers slightly better compression ratios at the expense of compression and decompression speed. The current implementation of the SZ library is not thread safe, meaning that compression on the backend would have to be implemented sequentially. Note that, due to the frontend’s use of web workers to decompress data, this limitation is overcome, as each web worker operates in a separate execution space. ZFP should be preferred when network bandwidth is sufficient. In the case of a desktop application, uncompressed data or very high quality ZFP compressed data should be favoured. When using uncompressed data, the FP32 floating point data is copied directly to and from the uint8 array specified by TileData (using 4 uint8 entries per 32-bit floating point entry).

Contour data is streamed as either uncompressed floating points, or compressed decimated fixed-point data. Contour data is losslessly compressed using the Zstandard [6] library, after being decimated to a fixed-point value. Vector overlay data follows the same approach as image data.