<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I agree here that the core goal of NeXus is the coherent *storage*
of data. NXdata was defined in order to allow a quick view of the
data in order to aid in sorting files. If we extend NeXus to
describe views of the data then we will certainly have problems with
the infinite number of possible plots that people could want to
describe. Line plots with multiple lines is a fairly simple case
that can be well defined rather simply, so an NXplot1d could make
sense to at least experiment with, but I would oppose making NXdata
more complicated by burdening it with this extra function. The core
need that I see from Armando is a way for analysis programs to store
their plotting outputs in the NeXus files, rather than the
experiment control system describing the ways the raw data can be
viewed.<br>
<br>
Therefore, I would support an NXplot that specifically describes a
view of data (raw or processed). In order to see how much work is
needed to provide the flexibility "everybody" is going to want, just
look at the list of options in any plotting software (Excel, Matlab,
Matplotlib, Origin, etc.) and you will see that it is extensive.
Perhaps a good way forward is to write an NXplot definition by
copying all of the options provided by the various plotting
packages. They all tend to provide very similar options to each
other, so it should be possible to provide descriptions of 99% of
the plots that people commonly make. Then we will at least have
something concrete to base further discussion on.<br>
<br>
Cheers,<br>
Ben<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/01/18 15:56,
<a class="moz-txt-link-abbreviated" href="mailto:Jacob.Filik@Diamond.ac.uk">Jacob.Filik@Diamond.ac.uk</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:91595EF9DACB9843AA623AB59EE84318A066C91D@exchmbx01">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0cm;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";
color:black;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:"Times New Roman",serif;
color:black;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
color:black;}
span.EmailStyle20
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Another
suggestion might just be to put any extra auxiliary NXdata
inside the raw NXdata.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I
fear this conversion is going into dangerous/interesting
territory. Software packages usually have an associated file
format, which is strongly linked to the application and its
data model.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Is
it the job of Nexus to allow NeXpy/DAWN/Mantis/Mantid… to be
able open a processed file from pyMCA of raw data, say
collected at Diamond, and display it in a the “richest” way
it can? Where richest is a function of how deeply the
application developer has implemented reading the standard?<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I
can understand that it may not be the job of Nexus to
provide a complete application data model for all
experiments and all applications ever, but wanting an
application to be able to plot 2 related datasets at the
same time seems like it shouldn’t be out the scope (but also
should not break applications using a more simple Nexus
structure).<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Anyway,
just my point of view.<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Jake<o:p></o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"
lang="EN-US">From:</span></b><span
style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:windowtext"
lang="EN-US"> NeXus
[<a class="moz-txt-link-freetext" href="mailto:nexus-bounces@shadow.nd.rl.ac.uk">mailto:nexus-bounces@shadow.nd.rl.ac.uk</a>]
<b>On Behalf Of </b>V. Armando Solé<br>
<b>Sent:</b> 11 January 2018 14:40<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:nexus@nexusformat.org">nexus@nexusformat.org</a><br>
<b>Subject:</b> Re: [Nexus] Correct way to specify
multiple signals<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 11/01/2018 15:36, Osborn, Raymond
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">I saw the Github issue and responded
before I realized there was already a lengthy
correspondence here. I will have to read more carefully
what has already been contributed here, but I wanted to
quickly summarize what I wrote there (<a
href="https://github.com/nexusformat/NIAC/issues/25"
moz-do-not-send="true">https://github.com/nexusformat/NIAC/issues/25</a>):
<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">“In my view, it is the role of the
NeXus standard to provide a way to offer a default plot
for each NXdata group, but I don't think it is necessary
for NeXus to then specify all other possible non-default
plots. Any program is free to provide that option within
the current standard as NeXpy does.”<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Please see the issue for my reasoning
- basically, you can do what Armando requests, i.e.,
plot multiple signals, now without adding extra
complexity to the standard.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
The goal is not to foresee any possible plot. It is to provide
a default plot. I post the answer I sent to github here too:<o:p></o:p></p>
<div>
<pre>On 11/01/2018 15:04, Ray Osborn wrote:<o:p></o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>To summarize - in my view, it is the role of the NeXus standard to<o:p></o:p></pre>
<pre>provide a way to offer a default plot for each NXdata group,<o:p></o:p></pre>
</blockquote>
<pre>Exact, but to me the default plot for a fit is the raw_data, the used<o:p></o:p></pre>
<pre>uncertainties and the fitted curve.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>NeXus provides everything for it except the possibility to put the<o:p></o:p></pre>
<pre>auxiliary curve.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>but I don't think it is necessary for NeXus to then specify all other<o:p></o:p></pre>
<pre>possible non-default plots.<o:p></o:p></pre>
</blockquote>
<pre>Nobody is asking for it.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<pre>Any program is free to provide that option within the current standard<o:p></o:p></pre>
<pre>as NeXpy does. <o:p></o:p></pre>
</blockquote>
<pre>PyMca does it too, so that is not the problem. However, consider the<o:p></o:p></pre>
<pre>marvellous opportunity NeXus offers to provide the output of a fit (or<o:p></o:p></pre>
<pre>other treatments), with uncertainties, axis labels, and fitted curve at<o:p></o:p></pre>
<pre>the cost of defining two group attributes.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
<pre>If NIAC tells me that Peter Chang's solution is not going to be<o:p></o:p></pre>
<pre>considered at all, it is fine with me too. We'll implement those two<o:p></o:p></pre>
<pre>attributes at our side and they will not conflict with any other<o:p></o:p></pre>
<pre>implementation.<o:p></o:p></pre>
<pre><o:p> </o:p></pre>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<p align="justify"> </p>
<p align="justify">-- </p>
<p align="justify">This e-mail and any attachments may contain
confidential, copyright and or privileged material, and are for
the use of the intended addressee only. If you are not the
intended addressee or an authorised recipient of the addressee
please notify us of receipt by returning the e-mail and do not
use, copy, retain, distribute or disclose the information in or
attached to the e-mail.<br>
Any opinions expressed within this e-mail are those of the
individual and not necessarily of Diamond Light Source Ltd. <br>
Diamond Light Source Ltd. cannot guarantee that this e-mail or
any attachments are free from viruses and we cannot accept
liability for any damage which you may sustain as a result of
software viruses which may be transmitted in or with the
message.<br>
Diamond Light Source Limited (company no. 4375679). Registered
in England and Wales with its registered office at Diamond
House, Harwell Science and Innovation Campus, Didcot,
Oxfordshire, OX11 0DE, United Kingdom<br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
NeXus mailing list
<a class="moz-txt-link-abbreviated" href="mailto:NeXus@nexusformat.org">NeXus@nexusformat.org</a>
<a class="moz-txt-link-freetext" href="http://lists.nexusformat.org/mailman/listinfo/nexus">http://lists.nexusformat.org/mailman/listinfo/nexus</a>
</pre>
</blockquote>
<br>
</body>
</html>