Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem with isContinuous 'PhiWidth' #23

Closed
KyleStiers opened this issue Oct 2, 2018 · 9 comments
Closed

Problem with isContinuous 'PhiWidth' #23

KyleStiers opened this issue Oct 2, 2018 · 9 comments

Comments

@KyleStiers
Copy link

Hello

When I attempt to run xdsme providing the set of diffraction images I get the following error:

Warning: time data 'Thu Aug 23 2018 14:33:01.647976' does not match format '%a %b %d %H:%M:%S %Y'
... Using time.time() instead.
Traceback (most recent call last):
  File "/programs/x86_64-linux/xdsme/20170725/bin/noarch/xdsme", line 1739, in <module>
    if not _coll.isContinuous(inputf):
  File "/data/programs/x86_64-linux/xdsme/20170725/XDS/XIO/XIO.py", line 861, in isContinuous
    phi_range = self.image.header['PhiWidth']
KeyError: 'PhiWidth'

Is this related to Issue #1 ?

Any ideas on a workaround or fix?

@JunAishima
Copy link
Contributor

could you describe what type of images you're using? I've used ADSC and Eiger HDF5 files without any problems. the directory XIO/plugins has some interpreters (*_interpreter.py) that should give you an idea of what header values need to be populated for PhiWidth to get a value.

@KyleStiers
Copy link
Author

KyleStiers commented Oct 3, 2018

I'm using images from a Pilatus detector. I ran xio_info on one of the images and got this:

Warning: time data 'Thu Aug 23 2018 14:33:01.647976' does not match format '%a %b %d %H:%M:%S %Y'
... Using time.time() instead.
>> Interpreting header of image:  /data/------/082318/10-01/10-01_1/10-01_1_0001.img
>> Image format:      adsc
{'BeamX': 147.2471,
 'BeamY': 142.0419,
 'DateSeconds': 1538589618.656785,
 'DateStr': 'Thu Aug 23 2018 14:33:01.647976',
 'Distance': 180.0,
 'EdgeResolution': 1.4840371378948147,
 'EndianType': '<',
 'ExposureTime': 0.2,
 'HeaderSize': 3072,
 'Height': 2820,
 'ImageType': 'adsc',
 'Message': [''],
 'PixelX': 0.1001,
 'PixelY': 0.1001,
 'SensorThickness': 0.0,
 'TwoTheta': 0.0,
 'Wavelength': 1.000032,
 'Width': 2952}
>> Loading /data/------/082318/10-01/10-01_1/10-01_1_0001.img
>> 2952 x 2820 pixels
>> Distance: 180.0 mm, Lambda: 1.000 A
Traceback (most recent call last):
  File "/programs/x86_64-linux/xdsme/20170725/bin/noarch/xio_info", line 69, in <module>
    _test1(filename)
  File "/programs/x86_64-linux/xdsme/20170725/bin/noarch/xio_info", line 32, in _test1
    im.data_info()
  File "/data/programs/x86_64-linux/xdsme/20170725/XIO/XIO.py", line 458, in data_info
    data = self.getData()
  File "/data/programs/x86_64-linux/xdsme/20170725/XIO/XIO.py", line 493, in getData
    _data = struct.unpack(_fmt, _data)
struct.error: unpack requires a string argument of length 17428608

So it is an ADSC type, apparently, but still not working. Can I supply PhiWidth from the command-line somehow to make sure it's getting the right value?

@JunAishima
Copy link
Contributor

I don't think it should be getting ADSC as the type - XIO.py should be recognizing the header as either a "minicbf" or "MSC Pilatus" which look like the two Pilatus types that can be recognized.

Can you show the miniCBF header, if it is a CBF file? or is it a tiff? tiff may be a problem because the two types above seem to assume a miniCBF file coming out of the Pilatus.

@legrandp
Copy link
Owner

legrandp commented Oct 4, 2018

From the pixel size, Height and Width, this can't be a Pilatus image. Could you send us an image so that we can check ?

@JunAishima
Copy link
Contributor

this looks like it's from ALS beamline 4.2.2 in Berkeley, CA, USA (just googled the image dimensions). this is not a large production common detector so there will not be any code that can read the images in xdsme yet. it's a fast CMOS detector capable of shutterless operation

@KyleStiers
Copy link
Author

Woops, you're right - I was thinking of our home source but these images are from ALS 4.2.2 with a CMOS-based Taurus-1 detector. So I guess that explains it

@KyleStiers
Copy link
Author

I guess the question I have left then is why XDS processing works on these images directly, but not in xdsme. Is the problem just with gathering the necessary metadata on the file-type?

@legrandp
Copy link
Owner

legrandp commented Oct 6, 2018

Yes. XDS is almost not reading the header's metadata. That's where xdsme helps using the XIO module. Since, data from this particular detector are not frequent, I have never had a request to make xdsme compatible with it. I may be not so difficult.

@legrandp legrandp closed this as completed Oct 6, 2018
@KyleStiers
Copy link
Author

Thanks for looking into it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants