
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>

</head>

<body>

<div>

<div>Clear to me, too - directly on topic for one of the three NeXus motivations: simple plotting</div>

<div><br>

</div>

<div><br>

</div>

<div><br>

</div>

<div id="x_composer_signature">

<div style="font-size:85%; color:#575757"><br>

</div>

<div style="font-size:85%; color:#575757">Sent from a device with a dreadfully small screen</div>

</div>

<br>

<br>

-------- Original message --------<br>

From: GOTZ Andrew <andy.gotz@esrf.fr> <br>

Date: 1/12/18 1:15 AM (GMT-06:00) <br>

To: Discussion forum for the NeXus data format <nexus@shadow.nd.rl.ac.uk> <br>

Subject: Re: [Nexus] Correct way to specify multiple signals <br>

<br>

</div>

<font size="2"><span style="font-size:11pt;">

<div class="PlainText">Armando,<br>

<br>

thank you for your patience - your explainations are clear to me! It is <br>

a pity the Nexus community do not understand them<br>

<br>

Andy<br>

<br>

<br>

On 12/01/2018 06:54, V. Armando Sole wrote:<br>

> On 11.01.2018 23:45, Osborn, Raymond wrote:<br>

>><br>

>> But you haven’t explained why you need multiple signals. If it’s<br>

>> to store the fit with the raw data, then you will also probably need<br>

>> multiple axes, since fitted functions are normally calculated at many<br>

>> more points than the raw data. How would you handle that? And do you<br>

>> propose to store a copy of the fields within the NXentry raw NXdata<br>

>> group?<br>

><br>

> I have proposed both and explicitly mentioned that auxiliary_signals <br>

> and auxiliary_axes would allow to achieve co-plotting raw_data and <br>

> fitted data with different number of points in my reply to Peter's <br>

> proposal.<br>

><br>

> You are focused on the fit, but any data treatment generating more <br>

> than one "signal" makes desirable to be able to group them. PyMca and <br>

> NexPy have no problem on visualizing anything, but plenty of <br>

> developers complain about the fat they are "forced" to create a <br>

> separated NXdata for each "signal" if they want the end user to <br>

> inspect the data in a friendly way. The fit case is just so evident <br>

> that should be enough to justify having that feature.<br>

><br>

> Other simple use case that I aim to have solved at the ESRF is to <br>

> achieve the goal of providing the user with a simple way to browse the <br>

> entries of an HDF5 file generated during the acquisition and <br>

> presenting them what they had at acquisition time. As you know <br>

> sometimes (even with SPEC) users are moving one motor and visualizing <br>

> more than one counter together. Having multiple signals would allow <br>

> the user to retrieve that information at the cost of a single click <br>

> instead of selecting what they want as x axis and at least one click <br>

> for each of the associated signals. The difference in user experience <br>

> is incomparable. Users and scientists of our beamlines moving to HDF5 <br>

> find tedious to have to interact so much.<br>

><br>

> To summarize with the SPEC analogy, in our view the default plot of an <br>

> entry associated to a measurement should be able to visualize one of <br>

> the plots the user was seeing when acquiring the data. If the user was <br>

> watching multiple counters on a plot, that goal cannot be achieved <br>

> with the current definition of NXdata and could be solved by <br>

> implemented the requested feature. You have everything on NeXus to <br>

> allow that (NXentry@default set to the default NXdata group) except <br>

> the capability to have multiple signals.<br>

><br>

>><br>

>> Before we can make meaningful comments, you have to give an explicit<br>

>> example.<br>

><br>

> I said we would do it for the XRF fit case and that I expected to have <br>

> for next week.<br>

><br>

> In the mean time please think about what the default NXdata plot <br>

> associated to an entry should be when the user was simultaneously <br>

> visualizing several counters at acquisition time.<br>

><br>

>> You keep on denying that you mean what both<br>

>> Ben and I have inferred you to mean, but until we see your example,<br>

>> it’s impossible to tell.<br>

><br>

> Sorry but I have to quote yourself and my answer that I thought it <br>

> could not be clearer:<br>

><br>

> RAY: but I don't think it is necessary for NeXus to then specify all <br>

> other possible non-default plots.<br>

><br>

> ARMANDO: Nobody is asking for it.<br>

><br>

> As I said, next week there will be the example for a fit output but to <br>

> have multiple signals is desirable for more than just the fit: exactly <br>

> the use case of the default plot.<br>

><br>

> Best regards,<br>

><br>

> Armando<br>

> _______________________________________________<br>

> NeXus mailing list<br>

> NeXus@nexusformat.org<br>

> <a href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a><br>

<br>

_______________________________________________<br>

NeXus mailing list<br>

NeXus@nexusformat.org<br>

<a href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a><br>

</div>

</span></font>

</body>

</html>