This is an old revision of the document!
Quick start guide to getting the sensor working. Basically, follow sections below to:
x-rays are dangerous…make sure you know what you are doing. Not responsible for death, injury etc
Image | Vendor | Product | Works? | Notes |
---|---|---|---|---|
Gendex | GXS700 small (type 1) | Yes* | Linux VM problematic from Windows VMWare and VirtualBox | |
Gendex | GXS700 large (type 2) | Yes | Primary device I develop for | |
Dexis | Platinum | Probably | Test failed but DUT was likely broken | |
Dexis | Plus 690 | Probably | Test failed but DUT was likely broken |
I don't know if any other vendors (ex: schick) use the same hardware
Prereq:
“$ cmd” means type “cmd” into a terminal
Do (I'll improve this as people run into problems):
This step tests the sensor without actually firing x-rays at it. This is also useful for calibrating sensor defects
Suggest you force a capture first to verify your sensor is working
Please do this and send me the result. This helps me understand the sensors better to provide better support
Send me the directory “dump” that it creates. If you are going to send me data from multiple sensors, please move the directory before re-running as it will overwrite.
Troubleshooting:
Known issues:
Misc:
See also: GXS700 general troubleshooting
Update: originally this was though to be a visualization issue. Now its believed to be a USB controller issue
TLDR: 2017-10-10 size 1 test results:
Above: good capture on one machine. Capture took about 3 seconds
Above: same sensor on a different native Linux machine. Capture took about 30 seconds
So if you have a size 1 sensor, unfortunately you may need to use native Linux.
Details: Size 1 sensors use USB interrupt transfers while size 2 sensors use USB bulk transfers. Unfortunately, interrupt transfers seem to be relatively poorly supported aside from HID (keyboard/mice). This may be partially due to them doing large interrupt transfers while HID does very small transfers.
Parallels has not been tested. Would be interested in feedback.
Size | Machine | USB controller | OS | Virtualization | OS native | Result | By | Notes |
---|---|---|---|---|---|---|---|---|
1 | Thinkpad Carbon X1 | Intel Sunrise Point-LP USB 3.0 xHCI Controller (rev 21) | Ubuntu 14.04 x64 | Native | N/A | Works | JM | . |
1 | JM desktop | Intel ICH10 | Ubuntu 14.04 x64? | VMWare | Windows 7 Pro x64 | Fail | JM | Slow capture / corrupted |
1 | User1 desktop | ? | Ubuntu 14.04 x64? | VMWare | Windows 7? | Fail | User1 | Slow capture / corrupted |
1 | User1 desktop | ? | Ubuntu 14.04 x64? | Virtual Box | Windows 7? | Fail | User1 | System freeze |
1 | User1 desktop | ? | Ubuntu 14.04 x64? | Native | N/A | Fail | User1 | System freeze |
1 | Thinkpad T61P | Intel 82801H | Ubuntu 12.04 x64 | Native | N/A | Fail | JM | |
1 | Thinkpad W520 | Ubuntu 14.04 x64 | Native | N/A | Works | USB3 port | ||
1 | Thinkpad W520 | Ubuntu 14.04 x64 | Native | N/A | Fail | USB2 port Kernel panic! |
Above: kernel panic W520 USB 2 port
decode.py has a “-e” option to do histogram equalization. This often brings out additional detail by re-mapping from 16 bit grayscale to shifted 8 bit grayscale. This works because humans can see 8 bits much easier than 16. TOOD: could we display usable 16 bit images by using two colors?
Example
$ python decode.py -e capture_004.bin capture_004e.png
NOTE: future revisions may require .png input instead of .bin
I haven't messed with the default trigger settings but I suspect you could do very low x-ray triggering if desirable
I use a Gendex GE-100 x-ray head. I've found these readily available for <$75 on both eBay and Craigslist. This accepts near line level AC inputs for both HV and filament making this easy to control from commodity variacs.
I control the setup via a DLI WPS7. When wired correctly:
do something like:
$ WPS7_HOST=wpsip WPS7_PASS=mypassword python fire.py
to fire an x-ray (ie when the sensor is armed. wpsip is something like 192.168.0.1
Note: you can also set these environment variables in files like .bashrc so you don't have to type them for each command
I recommend you use a hard wired ethernet line and have a way to cut power to the switch remotely if it fails. I do this by running an extension cord across the room so that it can be be pulled in event of WPS7 failure (stuck switch, etc).
TODO: use WPS7 scripting capability to make switch throws atomic
Takes raw, uncalibrated images. I've been asked a few times if I could provide calibration files for the Windows driver or could even use their calibration files on my driver. However, I'm not really interested in supporting their proprietary format. If someone submits a patch though I'll probably merge it in.
That said, I'm not against coming up with an independent calibration scheme. I know how to take dark frames (see API) which is the key component. Uncalibrated images have been generally good enough for me so I haven't put work into this. If you are interested though shoot me a line.
I haven't played around too much with trying to maximize quality. One thing that's clear though is that the sensor should be as close as possible to the object to be x-rayed. The tube to sample distance doesn't seem to matter as much
stitch.sh has an example workflow using pr0ntools (panotools). At the core its using mask.py to generate transparency masked images to use the full, albeit irregular, sensor area.