The automatic resolution cutoff is still being done by extrapolating CC1/2 to zero. The standard XDS "*.LP" logs should be there. Typically you look in CORRECT.LP for the XDS stats, and XSCALE.LP for multi-wedge stats. It runs twice, however, so I back up input and output files under sub-directories lp_1 and lp_2. ****************************************************************** 6/11/2016 12:18 PM, Michael wrote: A quick question about some data I'm processing from the pilatus (which is awesome to use, by the way)... I collected 180 degrees of reciprocal space using 0.2 degree oscillations and 0.2 sec exposure time (unattenuated), totaling 900 images and 3 min exposure time. I'm currently processing with Xia2 (XDS) and I'm noticing that the Rmerge and Rmeas are quite high, although the Rpim and CC(1/2) are pretty good. Is this something we should expect with pilatus data on account of the fine slicing and high number of individual measurements? That seems to make sense to me given the potential for merging R-factors to increase as a function of the number of measured reflections - am I right here? 12:44 PM, James wrote: No, this is something that I'm quite concerned about. With the limited testing we have been able to do, I'm definitely seeing noise that goes away when you "attenu-wait". This is why my priority right now is the attenuation during data collection, which currently still doesn't work quite right. I'm also studying the detector's behavior under load, and I have a suspicion there is some computer-driven jitter going on. Not sure yet. In the meantime, safest thing to do is slow down! Cut down the slits and do longer exposures if anomalous data is important. If resolution is all that matters, then this kind of noise won't make any difference. ******************************************************************