Identification of probe type

[yanngelebart]

Hello,
I am working on the C++ implementation of the MFMC 2.0.0 spécification as output file format for our in-house UT simulation software, and for use in our collaborative project ADVISE (Bristol participates).
The format requires to describe a probe as a collection of elements, as if they were all different, while industrial users and probe makers describe their probes as arrays of identical elements (for linear and matrix array), or as a collection of sets of identical elements (for sectorial arrays).
This is not a problem when writing the file, even if it is not very efficient in term of file size, but when reading the file in order to compute an image, it requires to compare all elements one to the other in order to identify the type of array which was used.
Would it make sense to add an optional <PROBE 1>/<PROBE_TYPE>" integer attribute which values could be
0 = not defined
1 = linear
2 = matrix
3 = sectorial
4 = ...
Best regards

[paulwilcox1971]

@yanngelebart,

I understand your point. In fact, there are several instances in the file where there could be more efficient descriptions to deal with common configurations (e.g. same argument applies to regular FMC data). The initial spec was intentionally written to provide maximum flexibility, but this comes at the expense of efficiency of space, and the problem you described of 'reverse engineering' the physical probe from the information in the file. I can see two ways forward:
Option 1. Allow a <PROBE_TYPE> attribute supplemented by relevant physical parameters (e.g. <NUMBER_OF_ELEMENTS>, <ELEMENT_PITCH> etc for the type of probe), which can be used instead of the current element-by-element definition.
Option 2. As for 1, but still require the element-by-element definition which remains mandatory (and takes precedence if there is a conflict).

In both cases the community have to agree the appropriate parametric descriptions of different probes. The advantage of Option 1 is that the file becomes 'lighter' but at the expense of requiring a change in any API's written to read files to include probe-type-specific functions. The advantage of Option 2 is that it standardises additional functionality that many users may desire, but does not require a change in the API to read files. Option 2 would be my preference for this reason, which I think is also what you proposed.

Best regards,

Paul

PS I can see why it is often desirable to get the probe specification from the file but do you actually need to have it for imaging purposes? Algorithms such as TFM can be written purely in terms of element positions, independent of their spatial configuration in a probe.

[yanngelebart]

@paulwilcox1971,

You are wright, my preference would also go for option 2.

I would go further and suggest to the community the following parametric description.

For linear array :

• number_of_element (integer)
• element_size (length 2 real vector) //index 0 is along major axis, 1 is along minor axis
• first_element_position (length 3 real vector) //in probe coordinate system, which origin is at center of the array
• direction_minor (length 3 real vector) //Element are disposed increasing along this direction
• direction_major (length 3 real vector) //major cross minor vector should point in the UT propagation direction
• pitch_minor (real) //element pitch in minor direction

For matrix array, I would :

• make number_of_element a length 2 vector
• replace pitch_minor by pitch (length 2 vector)
  For both, index 0 is along major axis, 1 is along minor axis

Bests regards,

Yann

PS : In term of imaging algorithm, I don't see a specific algorithm which would require more than what is already in the specification for probe description. However, in order to have a format that is fully useful in order to share data between organisations, I think it is highly desirable to get probe specification in "clear" within the file, but you seem to agree too.