Display Builder for AreaDetector

[tomaszbrys]

Hi We have a camera 2048x1536 mono 8bit. We want to use Display Builder to display images from camera. The camera is able to produce 35fps, the IOC with areaDetector can process around 27fps. CSStudio can display only ~3 fps. We do not want to save any pictures, just display. Is there any way to increase number of pictures displayed by CSS? We try both channel access and pvAccses. Where is the botleneck? We need highest possible resolution, compression is not an option. How we can solve this problem?

/Tomasz

[kasemir]

Not sure about the use case. The display is meant for a human, as part of an overall operator interface to control motors etc. The updates are throttled to reduce CPU load.

For example, at the SNS we have some detector images that are 3600x1580, similar size to yours. The data acquisition is meant to handle individual neutron events at very high rates. The detector image, on the other hand, shows a histogram of where the detector was hit by a neutron, and for that updates once a second are plenty.

The default settings in CSS/Phoebus are thus throttle the PV data early on to 4Hz, plot updates are throttled the same, and general widgets a little less:

# PV throttle (250)
org.csstudio.display.builder.runtime/update_throttle=250

# Display hesitation to accumulate updates (20)
org.csstudio.display.builder.representation/update_accumulation_time = 20
# Pause after updates (100)
org.csstudio.display.builder.representation/update_delay = 100
# Plot update throttle
org.csstudio.display.builder.representation/plot_update_delay = 250

For the display builder in CSS/Eclipse there's no PV throttle, but the display then has these defaults:

# Time waited after a trigger to allow for more updates to accumulate
org.csstudio.display.builder.representation/update_accumulation_time = 20
# Pause between updates to prevent flooding the UI thread
org.csstudio.display.builder.representation/update_delay = 100
# Pause between updates of plots
org.csstudio.display.builder.representation/plot_update_delay = 100

.. which we increased (slowed down) on the production system to 100, 200, 300.

If you want faster updates, you can adjust those settings, but if for some reason you want only fast image displays without increasing the overall CPU usage of CSS, consider running imagej as a separate process for your images.

[tomaszbrys]

Hi Kay, Thank you for you answer. I'll try to adjust those settings which you mention. I've tried using imageJ and it worked faster than CSStudio. The reason why I choose CSStudio is that we wrote an areaDetector Plugin for calibration, which automatically without user intervention can calibrate camera based on many rectangular patterns. The second reason is that user will interact with what he can see and update PV's in IOC.
I also thought since Display Builder is official OPI for EPICS7 it will also perfectly support areaDetector and display images. So, my application is not just simply neutron counter updating histogram once per second. But I will consider running imageJ.

/Tomasz

[kasemir]

I also thought since Display Builder is official OPI for EPICS7

Interesting. Says who? Based on recent EPICS meetings, the EPICS display ecosystem is still very diverse.

Anyway, did some tests with the latest 'phoebus' version of CSS / Display Builder (https://controlssoftware.sns.ornl.gov/css_phoebus/)

Data source was the default setup of the 'Sim' detector, 1024x1024 UINT. Claims to update at ~190Hz, and checking the time stamps from pvget -m -r timeStamp .. confirms that it's indeed in the ~180 Hz range.

My default phoebus settings for SNS beam lines are

# PV throttle
org.csstudio.display.builder.runtime/update_throttle=250

# Display hesitation to accumulate updates
org.csstudio.display.builder.representation/update_accumulation_time = 20

# Pause after updates
org.csstudio.display.builder.representation/update_delay = 100

# Plot update throttle
org.csstudio.display.builder.representation/plot_update_delay = 250

They indeed throttle the image updates to 4Hz exactly as configured. With the CA PV 13SIM1:image1:ArrayData the java process is using 45% CPU, IOC using 40% CPU.

When I use the PV pva://13SIM1:Pva1:Image the image again updates at 4Hz exactly as configured. The advantage of pva is that there's nothing to configure in the image widget beyond the PV name. Data size, 'unsigned' or not are automatically determined. Can change image size at runtime, display will adapt. But it turns out to be less efficient, using using 60% CPU, IOC using 45% CPU.

Next I reduced the throttling:

org.csstudio.display.builder.runtime/update_throttle=1
org.csstudio.display.builder.representation/update_accumulation_time = 1
org.csstudio.display.builder.representation/update_delay = 1
org.csstudio.display.builder.representation/plot_update_delay = 1

Now with both 13SIM1:image1:ArrayData and pva://13SIM1:Pva1:Image I get image updates at 20Hz. Again the CA version is a little more efficient, using 160% CPU, IOC using 70% CPU, while the PVA version is using 180% CPU, IOC using 70% CPU.

There is clearly still some throttling happening, since the image only updates at 20Hz. On the upsize, the CPU load > 100% shows that the code is multi-threaded. It's not using 100% of the UI thread and then blocks. Instead, I can still zoom into the image and pan it around without hesitation. Still, if your eyes are better and you need faster updates than 20Hz, then the display builder is clearly not the tool for your use case.

[kasemir]

As for CA vs. PVA, the DBR_TIME_.. data type from the former is simply wrapped in CSS, while the PVA data requires us to copy the data out of the received monitor buffer. I was worried that this one copy would cause a lot of CPU usage, but in the example I checked with jProfiler that doesn't seem to be the case. The main difference simply seems to be that CA spends time in com.cosylab.epics.caj.impl.DBRDecoder.readValues to read data from the network buffer, while PVA spends time in org.epics.pvdata.factory.ConvertFactory$ImplementConvert.copyStructure. The latter is naturally a little more complex.

[tomaszbrys]

Thank you Kay for all the tests. Yes indeed I do not need anything more than 20Hz, even 10Hz would be enough but 4Hz is a little to small. I will play with CSStudio and the parameters which you have mentioned. I think you can close the issue.

Thank you very much. /Tomasz

[kasemir]

Display Builder in CS-Studio/Eclipse is slower resp. uses more CPU & mem compared to Display Builder in Phoebus. It's JavaFX, and in the former the JFX graphics are hosted within an SWT panel, so basically creating images which are then periodically updated in an SWT canvas. In the latter, it's all plain JavaFX.

Imagej may always be the fastest because that's one process doing nothing but showing the image, and fundamentally there's nothing wrong with running both imagej and CSS.