Menu
▾
▴
RE: NTImage and other NTTypes
|
From: <jam...@di...> - 2011-11-30 13:41:47
|
Ok, I'll do that. > This is what was confusing me, I wasn't sure whether you were proposing a > different design, a specialization, or a different NT type. I assumed there > was a difference - that areaDetector can detect images, but images are > general. Like the difference between RAW and "CannonCameraControlData". AreaDetector defines the standard image type in EPICSv3. It's pretty general, there's an array, some metadata, and a pixel format. The only more general image type would have no metadata, but as that's optional (in that it's an array of things of possibly zero length) there's no overhead. Bit like going for TIFF instead of RAW. James > -----Original Message----- > From: Greg White [mailto:gr...@sl...] > Sent: 30 November 2011 13:22 > To: Rowland, James (DLSLtd,RAL,DIA) > Cc: mal...@bn...; epi...@li... > Subject: Re: NTImage and other NTTypes > > This is what was confusing me, I wasn't sure whether you were proposing a > different design, a specialization, or a different NT type. I assumed there > was a difference - that areaDetector can detect images, but images are > general. Like the difference between RAW and "CannonCameraControlData". > > If they are in fact the same, then please just work with Nikolay to define the > single Ntype for images. > > Additionally, I propose we replace the present definition of nameValuePair_t > with the following; > > structure nameValuePair_t > string name > int dataType; // pvData type code, [1,6] > string sValue > string[] sValues > double dValue > double[] dValues > long iValue > long[] iValues > > *Marty* - i realize this affects you. But I have also to redo rdbService in > the light of final definitions of Normative Types. So, this just encourages us > to get on with it. > > Greg > > On 30 Nov 2011, at 13:36, <jam...@di...> wrote: > > > Yes looks good. > > > >> Secondly, can you put together then a complete proposal for the NT > >> for areaDetector, that I can just put in the specification document. > > > > I can but are you proposing that the areaDetector NT is different from > NTImage? If not, I'll send something to Nikolai. If so, I don't think that's a > good idea. AreaDetector provides an existing spec for an NTImage. > > > > James > > > >> -----Original Message----- > >> From: Greg White [mailto:gr...@sl...] > >> Sent: 30 November 2011 11:00 > >> To: Rowland, James (DLSLtd,RAL,DIA) > >> Cc: mal...@bn...; epi...@li... > >> Subject: Re: NTImage and other NTTypes > >> > >> OK, excellent. Two things then. > >> > >> First, about the idea for a nameValueVariantPair_t and the same > >> variant idea with respect to NTTable. How's this; we complete the > >> equivalence of the two types nameValueVariantPair_t and NTTable, and > >> the two encoding mechanisms, by defining nameValueVariantPair_t so that the > values can be arrays. > >> > >> That is, adding to what you wrote: > >> > >>> structure nameValueVariantPair_t > >>> string name > >>> int dataType; // pvData type code, [1,6] > >>> string sValue > >> string[] sValues > >>> double dValue > >> double[] dValues > >>> long iValue > >> long iValues > >> > >> In this way, a nameValueVariantPair_t may be used to encode columns > >> of a table. A functional table may then be encoded as either an > >> instance of the normative type NTTable, or non-normatively as a > >> structure containing an array of nameValueVariantPair_t. > >> > >> structure > >> nameValueVariantPair_t[] columns > >> > >> The advantage of this is that, if you like, it closes the type system > >> for table like data. We have two complete systematic ways of doing a > >> single functional thing (exchanging a table). User doesn't get > >> confused about how to do it, they'd use a or b. Use "a" if the types > >> are simple, and "b" if they're more complex, or they just prefer b. > >> > >> For an example of b (with an NTtable), see rdbService's encoding > >> server side in RdbServiceFactory.java getData method [1] and decoding > >> in rdbClient.java lines 190-236 [2]. These encode and decode the > >> result of any JDBC query against a SQL db. > >> > >> > >> Secondly, can you put together then a complete proposal for the NT > >> for areaDetector, that I can just put in the specification document. > >> > >> Cheers > >> Greg > >> > >> [1] > >> http://epicspvdata.hg.sourceforge.net/hgweb/epicspvdata/exampleJava/f > >> ile/576e5 9c105e9/src/rdbService/RdbServiceFactory.java > >> [2] > >> http://epics-pvdata.hg.sourceforge.net/hgweb/epics- > >> pvdata/exampleJava/file/576e59c105e9/src/rdbService/RdbClient.java > >> > >> > >> > >> > >> > >> > >> On 30 Nov 2011, at 11:09, <jam...@di...> wrote: > >> > >>> Hi Greg > >>> > >>> Yes that's it. In areaDetector the metadata is (wait for it...) an > >>> array of > >> tagged unions which looks like this: > >>> > >>> structure[] attributeList > >>> structure NDAttribute > >>> string name > >>> string description > >>> string source > >>> structure NDAttrSource > >>> int index > >>> string[] choices > >>> structure NDAttrDataType > >>> int index > >>> string[] choices > >>> long iValue > >>> string sValue > >>> double dValue > >>> > >>> So the name-value pair is not sufficient. We have discussed a table > >>> with > >> some redundant columns as one way of packing this: > >>> > >>> struct MetadataTable > >>> string [] names > >>> string [] descriptions > >>> string [] sources > >>> int [] NDAttrSource > >>> int [] NDAttrDataType > >>> long [] iValue > >>> string [] sValue > >>> double [] dValue > >>> > >>> I'd argue against sending all metadata as strings as the as the user > >>> would > >> have to do the casting and the point of the EPICSv4 type system is to > >> provide a useful type system and avoid that. Instead of the table I > >> propose a normative > >>> > >>> structure nameValueVariantPair_t > >>> string name > >>> int dataType; // pvData type code > >>> string sValue > >>> double dValue > >>> long iValue > >>> > >>> Which would solve this problem. I'll dig up some real-life examples > >>> of > >> metadata. > >>> > >>> James > >>> > >>>> -----Original Message----- > >>>> From: Greg White [mailto:gr...@sl...] > >>>> Sent: 30 November 2011 09:51 > >>>> To: Rowland, James (DLSLtd,RAL,DIA) > >>>> Cc: mal...@bn...; epi...@li... > >>>> Subject: Re: NTImage and other NTTypes > >>>> > >>>> Hi James, At the PSI meeting we said that the definition of each NT > >>>> would > >> not > >>>> be allowed to include another NT (though I don't think we minuted a > >> resolution > >>>> because we weren't that well organised). Given that, can I strawman > >>>> what you're proposing. please correct this: > >>>> > >>>> structure NTdetector > >>>> <<All field*s* that are in NDArray>> enum_t pixelFormat > >>>> nameValuePair_t[] metadata > >>>> > >>>> Cheers > >>>> Greg > >>>> > >>>> > >>>> On 29 Nov 2011, at 18:03, <jam...@di...> > >>>> <jam...@di...> wrote: > >>>> > >>>>> Hi > >>>>> > >>>>> I'm going to repeat my desire for the EPICSv3 detector support to > >>>>> be a > >>>> superset of areaDetector NDArray, which is perhaps the only > >>>> structured type present in EPICSv3 that is commonly used. This > >>>> means a type that contains a multi-dimensional array, a pixel format enum > and some extensible metadata. > >> I > >>>> don't care if it's stored as a tuple of a table, an array and a > >>>> pixel > >> format > >>>> enum or whatever. There would need to be a very good reason for not > >>>> making > >> it > >>>> compatible. > >>>>> > >>>>> James > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Greg White [mailto:gr...@sl...] > >>>>>> Sent: 29 November 2011 16:43 > >>>>>> To: Nikolay Malitsky > >>>>>> Cc: epi...@li... Developers > >>>>>> Subject: NTImage and other NTTypes > >>>>>> > >>>>>> Nikolay, > >>>>>> > >>>>>> How is the NTimage definition going? > >>>>>> > >>>>>> My feeling is you're on the hook for NTimage, NTNDArray, > >>>>>> NTXAlarm, and to check the definition as it is now of NTStatistic. > >>>>>> > >>>>>> Cheers > >>>>>> Greg > >>>>>> > >>>>>> > >>>>>> ----------------------------------------------------------------- > >>>>>> ---- > >>>>>> --------- All the data continuously generated in your IT > >>>>>> infrastructure contains a definitive record of customers, > >>>>>> application performance, security threats, fraudulent activity, > >>>>>> and more. Splunk takes this data and makes sense of it. > >>>>>> IT sense. And common sense. > >>>>>> http://p.sf.net/sfu/splunk-novd2d > >>>>> > >>>>> -- > >>>>> 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. > >>>>> Any opinions expressed within this e-mail are those of the > >>>>> individual and > >>>> not necessarily of Diamond Light Source Ltd. > >>>>> 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. > >>>>> 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 > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > >>> -- > >>> 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. > >>> Any opinions expressed within this e-mail are those of the > >>> individual and > >> not necessarily of Diamond Light Source Ltd. > >>> 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. > >>> 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 > >>> > >>> > >>> > >>> > > > > > > -- > > 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. > > Any opinions expressed within this e-mail are those of the individual and > not necessarily of Diamond Light Source Ltd. > > 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. > > 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 > > > > > > > > -- 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. Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd. 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. 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 |