| 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 | Index | 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 <2022> 2023 2024 2025 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | RE: EPICS areaDetector plugin & phoebus |
| From: | Mark Rivers via Tech-talk <tech-talk at aps.anl.gov> |
| To: | "Kasemir, Kay" <kasemirk at ornl.gov> |
| Cc: | "tech-talk at aps.anl.gov" <tech-talk at aps.anl.gov> |
| Date: | Mon, 11 Apr 2022 16:12:54 +0000 |
|
Ø
As far as I know, implementations of compression/decompression like the one for ImageJ call out to native libraries That is true. But the decompression libraries are all built in ADSupport in a way that makes them easy to call from other applications and languages, including Java. They are called from ImageJ, and also from the HDF5 library via its
run-time plugin mechanism. This means that HDF5 applications do not need to be linked with the decompressors, they can find and load them at run-time. Because they are built from source in ADSupport, there are minimal dependencies on OS packages. Mark From: Tech-talk <tech-talk-bounces at aps.anl.gov>
On Behalf Of Kasemir, Kay via Tech-talk > I’ve forgotten if CSS/Phoebus supports compressed PVA NTNDArray objects, but that would help a lot when visualizing large arrays. It doesn't. As far as I know, implementations of compression/decompression like the one for ImageJ call out to native libraries, see decompress*.. code in
https://github.com/areaDetector/ADViewers/tree/78cb7127d655685d9f4f2c83f0d83c7e5b758d58/ImageJ/EPICS_areaDetector. If we supported that in Phoebus, we could no longer offer a generic Windows/Linux/Mac version, everybody would have to locally compile the
compression code. |