Re: Compressed image without NDPluginCodec

["Sukhanov, Andrei via Tech-talk" <tech-talk at aps.anl.gov>]

Hi Michael.

Will the PNG format be supported? Image processing of all our 70+ cameras relies on this format. The lossy compression is not allowed since in many cases the beamlet shapes could be tiny, also many cameras are in radiation area and they develop many speckles. Speckle removal works well only on original image.

/Andrey

---

From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Michael Davidsaver via Tech-talk <tech-talk at aps.anl.gov>
Sent: Friday, March 6, 2026 9:39 AM
To: Érico Nogueira Rolim <erico.rolim at lnls.br>
Cc: tech-talk at aps.anl.gov <tech-talk at aps.anl.gov>
Subject: Re: Compressed image without NDPluginCodec

 

On 3/6/26 6: 58 AM, Érico Nogueira Rolim wrote: On 2/14/26 01: 57, Michael Davidsaver via Tech-talk wrote: On 2/13/26 12: 29 PM, Nariyoshi, Pedro via Tech-talk wrote: Hello all, I have been trying to create a records to display an image on a CS-Studio Phoebus

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

 

ZjQcmQRYFpfptBannerEnd

On 3/6/26 6:58 AM, Érico Nogueira Rolim wrote:

On 2/14/26 01:57, Michael Davidsaver via Tech-talk wrote:

On 2/13/26 12:29 PM, Nariyoshi, Pedro via Tech-talk wrote:

Hello all,

I have been trying to create a records to display an image on a CS-Studio Phoebus screen. The problem is that transmitting the waveforms directly is quite bandwidth intensive. For our cameras, we tend to use NDPluginCodec with NDPluginPva, which works fairly well, but I would like to avoid having to write some glue code to send the waveforms to a dummy asynNDArrayDriver. I have been trying (without much success) to do it. I have tried creating a json to load via dbLoadGroup and via p4p, but as soon as I set the codec to jpeg and try to send compressed data, everything stops working:

Mark Rivers has recently done some work with the new NDPluginPvx and compression, which may be relevant.

 nt.wrap doesn't like the compressed data,

Correct, so far.  I would be interested if someone had time to look at adding support to P4P.  Identifying python libraries implementing the various compression algorithms would be step one.

For P4P, would the library then be able to handle compression transparently (à la libhdf5)?

Do you think PVXS would ever support such a mechanism, or would it remain a lower level tool and simply forward already compressed buffers and compression metadata?

I like the "batteries included" model.  So, yes.  I would like to see P4P support NTImage codecs.  As with HDF5, I see the main complication as one of dependency management.  With a dynamic runtime like python, it is easier to have optional dependencies if necessary.  eg. P4P already has qtpy as an optional dependency.

The standard library includes a few very common compression algorithms, which should be preferred if applicable.  I would hope that one of the common image handling libraries like PIL/Pillow could be used for most others.  This might reasonably be added as a required dependency.  Some more "exotic" codec, needing a less common library, might still be added as an optional dependency.