[Nexus] DECTRIS again
Watts Benjamin
Benjamin.Watts at psi.ch
Tue Oct 23 17:02:26 BST 2012
This is exactly what the NeXus version numbers should be used for. We
should try to make clear distinctions between new and old formats so
that software reading the files doesn't have to guess.
Ben
-----Original Message-----
From: nexus-bounces at nexusformat.org
[mailto:nexus-bounces at nexusformat.org] On Behalf Of
Tobias.Richter at diamond.ac.uk
Sent: Dienstag, 23. Oktober 2012 17:37
To: nexus at nexusformat.org
Subject: Re: [Nexus] DECTRIS again
My argument is wasn't against accommodating Dectris. But if we do offer
fast track service strictly speaking (outside of the current
constitution) to some the conditions should be clear and not subjective.
The other issue about the geometry was targeted at programs written for
reading the existing non-modular detectors. They would not look for the
module information. There should some information missing in order for
them not to silently assume the wrong geometry. Then the user is aware
and will spot the module when investigating.
Regards,
Tobias
________________________________________
From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on
behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
Sent: 23 October 2012 14:58
To: Discussion forum for the NeXus data format
Subject: Re: [Nexus] DECTRIS again
Hi all,
On 10/22/2012 03:59 PM, Tobias.Richter at diamond.ac.uk wrote:
> Hi all,
>
> I did recall us deciding something for the exposure_time, but at least
it wasn't known to all in this mailing list.
>
> The scheme would work with something like this:
>
> detector:NXdetector
> data[j,k,l] = [....]
> detector_arm[1] = [250]
> @transformation=translation
> @vector={1,0,0}
> @units=cm
> @depends_on=/entry/instrument/something/brick
> depends_on=detector_arm
> module:NXdetector_module
> data_origin[2] = [l,m]
> data_size[2] = [n,o]
> module_offset[1] = [250]
> @transformation=translation
> @vector={0,1,1}
> @units=mm
> @depends_on="../detector_arm"
> fast_pixel_direction[1] = [0.172]
> @transformation=translation
> @vector={1,0,0}
> @units=mm
> @depends_on="module_offset"
> slow_pixel_direction[1] = [0.172]
> @transformation=translation
> @vector={0,1,0}
> @units=mm
> @depends_on="module_offset"
> module:NXdetector_module
> ....
>
> This is just a (hopefully) complete illustration to show what we need
to specify. I am more than happy for suggestions to modify this.
This is another version of what I have suggested, but has the advantage
that we do not need x and y arrays. I can live with this, all necessary
data is specified.
As was with my suggestions.
Just wasting some more space....
> We would also need to make sure that interpreting the detector in the
traditional way fails. Otherwise software will pick up the wrong
geometry.
Please elaborate.
> I am not sure why we are in such a rush, though. They are not about to
ship a detector like that in the next days, are they? We can put
something like the above in front of them and say that is vaguely what
it will contain. But we will need to put some thought into it. In the
end the way we currently use the Pilatus that information would be
written by me anyway as I have no intention updating the detector on its
geometry all the time.
The thing is that DECTRIS wishes to call two meetings pretty soon and
until then the thing should be ready. And early, such that they can
prepare example files, reading code etc...
The first of this meeting, with DA analysis SW people will already by
end of november. As DECTRIS pays for it, it is s a closed meeting.
The second, with a larger audience including those of you who want,
will be in January.
This is why I try to rush this. Waiting for the next code camp or NIAC
meeting will not do.
> Bottom line is: It should not be too obvious that institutions
actually devoting manpower towards NeXus do not receive the same
fast-track service for their requirements.
Well, I think this DECTRIS thing is important to get NeXus through the
door of many facilities.
IMHO a little exertion on our side is justified.
Regards,
Mark
> Regards,
>
> Tobias
>
> ________________________________________
> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org] on
> behalf of Mark Koennecke [Mark.Koennecke at psi.ch]
> Sent: 19 October 2012 16:25
> To: Discussion forum for the NeXus data format
> Subject: Re: [Nexus] DECTRIS again
>
> Tobias, Pete,
>
>
> On 10/18/2012 05:06 PM, Tobias.Richter at diamond.ac.uk wrote:
>> Hi,
>>
>> I'm with Ben on the critique of the "exposure_time".
> I was of the impression that we decided on the last Telco to make them
> use count_time.
> This is what I forwarded to them.
>
>> For the modules one problem is that the "data" will be one big image
array. So we need to identify the module slice with something
[x,y,dx,dy]. This would apply to the last slicerank/2 dimensions of the
dataset (in case of scans).
>>
>> With that if you have one displaced module were this in the data:
>>
>> +--------------+
>> | |
>> | |
>> | |
>> | +----+
>> | | |
>> +---------+----+
>>
>> Is actually like this in real space:
>>
>> +--------------+ +----+
>> | | | |
>> | | +----+
>> | |
>> | +----+
>> | |
>> +---------+
>>
>>
>> You would need to describe that as at least three modules unless we
make the scheme more complex.
>>
>> For the elements the (simplified) CIF standard uses
>> * an origin relative to the nominal detector position
>> * a fast vector with pixel displacement along it
>> * a slow vector with pixel displacement along it The detector normal
>> is in the direction of the cross product of the two vectors.
>> There are more complicated schemes for non-regular/rectangular, e.g.
hexagonal pixels. I'd suggest we deal with those as and when required.
> Can you please give an example of a NXdetector_element group with
this?
> I agree that having those
> arrays is a tad overkill.
>
> Concerning Pete's reply:
>
> yes, NXdetector is the class which would benefit the most if we take
> apart NeXus to become more OO-oriented. IMHO, in NXdetector there are
> two opposing forces:
>
> - We already have a means to describe each detector pixel
individually.
> This is the most general
> case. But this is cumbersome.
> - We wish to maintain the spatiality of the detector in order to give
> the user what she expects: if she
> has an area detector, she should see that on file. And not a
> description of each pixel.
>
> When entering the realm of OO-NeXus I am now starting to think more of
> interfaces. OO does not match so well anyway. And I have reservation
> against a more complicated hierarchy anyway.
> The interface approach would mean: You start with a plain NXdetector,
> if you a 2D you add these fields, if you have TOF do this, if you have
> 2D and TOF do this, etc.
>
> So, I think we could go quick with a solution to the problem: if you
> have a patched together detector do this. I do wish to give DECTRIS a
> timely answer on this. May be modelled on CIFS approach.
>
> Have a nice weekend,
>
> Mark
>
>
>> I am not sure how this translates into your second option, Mark.
>> If we assume the pizels are all evenly spaced, I think we do not need
the arrays for the positions, though.
>>
>> Comments?
>>
>> Tobias
>>
>> ________________________________________
>> From: nexus-bounces at nexusformat.org [nexus-bounces at nexusformat.org]
>> on behalf of Watts Benjamin [Benjamin.Watts at psi.ch]
>> Sent: 04 October 2012 15:07
>> To: Discussion forum for the NeXus data format
>> Subject: Re: [Nexus] DECTRIS again
>>
>> Hi,
>> I'm happy with all the names except that "exposure_time", which is
>> clearly used in contradiction to the meaning of the word "exposure"
>> and the nature of the hardware. (Only a light source or shutter would
>> control an actual exposure time.) If a new field is required, then I
>> would prefer it be named "accumulation_time". However, the field
>> "count_time" already exists in NXdetector and would suit the purposes
>> of DECTRIS perfectly well. My reccommendation therefore is that
>> DECTRIS use "count_time" instead of making a new "exposure_time"
field.
>>
>> For describing the positions of the detector modules, I vote for the
>> CIF-like option since forward-compatibility is more of an issue than
>> backwards-compatibility in this case.
>>
>> Cheers,
>> Ben
>>
>>
>> -----Original Message-----
>> From: nexus-bounces at nexusformat.org
>> [mailto:nexus-bounces at nexusformat.org] On Behalf Of Mark Koennecke
>> Sent: Donnerstag, 4. Oktober 2012 14:39
>> To: Discussion forum for the NeXus data format
>> Subject: [Nexus] DECTRIS again
>>
>> Hi,
>>
>> there are still some open points about the DECTRIS detector which
>> have come up.
>>
>> First the time issue: I got better documentation what the times
>> actually
>> mean:
>>
>> frame_time = exposure_time + detector_readout_time
>> frame_time: time at which data is sent to readout-computer, i.e.
>> defines the speed of the data collection or the speed and can be put
>> on the same level as exposure time for an integrating detector (like
>> a CCD, Imaging Plate,...)
>> exposure_time: time during which detector counts X-rays
>> detector_readout_time: time the detector takes for a complete readout
>> of all chips, i.e. defines the minimum time after which the detector
>> can count again
>>
>> With this explanation, are we now happy with the names?
>>
>> And a new issue came up: detector modules. The EIGER detector
>> consists of various modules which are arranged to build the full
>> detector. There are gaps between the modules. The EIGER SW calculates
>> a combined image from the contributions of the modules. In the case
>> of a flat detector the DA SW looks at the mask to find out about
gaps.
>> Happiness al around.
>>
>> But the modules may be arranged along an arbitrary form, may be half
>> sphere. The detector SW will still recombine the modules to an image,
>> just for the user to look at it. But then the DA SW needs the
>> position and orientation of the individual modules. And an indication
>> at which indices the module starts in the combined image. The
>> question is now how to describe those modules. As the DA may need it,
>> this is no longer DECTRIS private but should be addressed by us.
>>
>> The first option would be to have NXgeometries in NXdetector:
>>
>> NXdetector
>> module01,NXgeometry
>> NXtranslation
>> NXorientation
>>
>> module02,NXgeometry
>> NXtranslation
>> NXorientation
>>
>> .....
>> This option is missing the index information. I am not sure if we
>> want to add that to NXgeometry. I am also not sure if we still wish
>> to advocate the use of NXgeometry. IMHO, the CIF mapping is better
>> and NXgeometry may be deprecated soon.. But is not yet....
>>
>> The second option would be a new group: NXdetector_module looking
>> like
>> this:
>>
>> NXdetector
>> module01,NXdetector_module
>> x[nx]
>> @offset=...
>> @vector= ...
>> y[ny]
>> @offset=...
>> @vector=....
>> x_data_offset
>> y_data_offset
>> The x any y arrays describe the pixels of the module, the offset and
>> vector attributes the position and orientation in space. The indices
>> go into the x,y_data_offset.
>>
>> Of course there are other options......
>>
>> What do you think? We should reach an agreement at the next telco
>> latest.
>>
>> Best Regards,
>>
>> Mark Koennecke
>>
>>
> _______________________________________________
> NeXus mailing list
> NeXus at nexusformat.org
> http://lists.nexusformat.org/mailman/listinfo/nexus
>
_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus
--
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
_______________________________________________
NeXus mailing list
NeXus at nexusformat.org
http://lists.nexusformat.org/mailman/listinfo/nexus
More information about the NeXus
mailing list