Re: Question for areaDetector overlay and file plugin

[Mark Rivers via Tech-talk <tech-talk at aps.anl.gov>]

Hi Eddy,

     

•    Looking at the implementation reveals that you have to give the filename pattern exactly as shown on the GUI. Otherwise the code will crash.

That is not quite true, there is some flexibility.  It is documented here:

https://areadetector.github.io/areaDetector/ADCore/NDArray.html#asynndarraydriver

The explanation for NDFileTemplate says this:

Format string for constructing NDFullFileName from NDFilePath, NDFileName, and NDFileNumber. The final file name (which is placed in NDFullFileName) is created with the following code: epicsSnprintf(FullFilename, sizeof(FullFilename), FileTemplate, FilePath, Filename, FileNumber); FilePath, Filename, FileNumber are converted in that order with FileTemplate. An example file format is

“%s%s%4.4d.tif”
. The first %s converts the FilePath, followed immediately by another %s for Filename. FileNumber is formatted with %4.4d, which results in a fixed field with of 4 digits, with leading zeros as required. Finally, the .tif extension is added to the file name. This mechanism for creating file names is very flexible. Other characters, such as _ can be put in Filename or FileTemplate as desired. If one does not want to have FileNumber in the file name at all, then just omit the %d format specifier from FileTemplate. If the client wishes to construct the complete file name itself, then it can just put that file name into NDFileTemplate with no format specifiers at all, in which case NDFilePath, NDFileName, and NDFileNumber will be ignored.

Many sites use scripts to construct the full file name and write that to the FileTemplate PV.  These scripts can be written in Bluesky, other Python code, spec, IDL, etc.  The scripts often take care of other tasks such as setting the Acquire time, setting the camera modes, etc.  Those scripts can certainly create a filename that contains the date and any other desired information.

I think that writing a few line Python script is much easier that subclassing the C++ classes.

• Thanks for this hint! I looked at that part of the code trying to understand where and how the file name is exactly constructed and I think maybe the best approach would be to patch  NDPluginFile::attrFileNameSet()?

I don't think that is what you would modify.  attrFileNameSet() is code that builds the file name from NDAttributes attached to the NDArray.  For example the driver might know that one array contains the flat field image, and so it sets an attribute that will cause the filename to contain the string "FlatField".

The code that builds the filename without attributes, i.e. for the GUI is here:

https://github.com/areaDetector/ADCore/blob/84da95763e24ac2a76b37b99f2276b58afc71e59/ADApp/ADSrc/asynNDArrayDriver.cpp#L192

1. Overlay plugin: If I use a text label I can change the font based on 4

different options. Is there a way to scale the size in addition to that? For

our images, the label is very small.

     1a. If not, I would need to modify the font selection part in the

overlay module to provide larger font sizes? Is that something which is

reasonable to do? Helpful for any hints of how to approach this

There is currently no way to scale the size, you would need to add additional fonts.  The fonts are defined in this file:

https://github.com/areaDetector/ADCore/blob/master/ADApp/pluginSrc/NDPluginOverlayTextFont.cpp

The comments say that the fonts came from here:

https://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html

That site has many fonts, so it should not be too hard to add more.  I would be happy to accept a Pull Request, since I agree that the current fonts are rather small.

Mark

---

From: Tech-talk on behalf of Blomley, Edmund (IBPT) via Tech-talk
Sent: Wednesday, June 18, 2025 5:55 AM
To: Jörn Dreyer; tech-talk at aps.anl.gov
Subject: RE: Question for areaDetector overlay and file plugin

Hey Jörn,

        > Looking at the implementation reveals that you have to give the filename pattern exactly as shown on the GUI. Otherwise the code will crash.

I was wondering if there are actually other options as the one shown in the GUI and if not: why even try to provide a setting. I assume it was foreseen to be more flexible at some point?

        > If you want to have the date and time included in your filename, the simplest way would be to create your own plugin that overwrites NDPluginFile::openFileBase. This function will be called for each file to be opened. It will call the openFile function of the file plugin (e.g. HDF5File).

Thanks for this hint! I looked at that part of the code trying to understand where and how the file name is exactly constructed and I think maybe the best approach would be to patch  NDPluginFile::attrFileNameSet()?
Here just before this line https://github.com/areaDetector/ADCore/blob/84da95763e24ac2a76b37b99f2276b58afc71e59/ADApp/pluginSrc/NDPluginFile.cpp#L603
There I could check the content of the prefix looking for the "usual" time syntax ("%x") and replace that?


        > Just adding another button is not fail save! What if you forget to press the button before starting to write? What if you write files in auto increment mode?

Yeah I am aware that this would obviously be bad design and fail in multiple scenarios. Just need to balance this against my basically non-existing c programming experience to come up with a solution 😉
But now of course I hope I will figure out a solution with a local patch to the FilePlugin.

Cheers
eddy