Problem with guess_bins with 360 degree scans

[jadball]

Line 435 here is incorrectly triggered when we collect a 360 degree single-turn scan (often omax - omin is slightly larger than 360)

ImageD11/ImageD11/sinograms/dataset.py

Lines 431 to 441 in 3eb8107

	def guessbins(self):
	ny, nomega = self.shape
	self.omin = self.omega.min()
	self.omax = self.omega.max()
	if (self.omax - self.omin) > 360:
	# multi-turn scan...
	self.omin = 0.0
	self.omax = 360.0
	self.omega_for_bins = self.omega % 360
	else:
	self.omega_for_bins = self.omega

[jonwright]

Do you want the check to be (360 + omegastep), or is there some other problem with it?

[jadball]

I'll need to double-check with the raw data once I'm back in the office to see if that will be sufficient, but it was slightly over 360 degrees for sure (check Wolfgang's last scanning expt)

[jonwright]

The reason the mod360 is in there is for datasets with continuous (e.g. always forward) rotation. If the scan is over by a few degrees, it means some angles get measured twice instead of once. This is more of an intensity normalisation problem rather than a wrong omega bin problem. Omega at 362 degrees and 2 degrees are supposed to be the same projection...?

[jadball]

The problem is that if we go from, say, -181 to 181 degrees, the mod360 is invoked, which forces the omega range to 0-360. This means our omin, omax and omega_for_bins are no longer in agreement with cf.omega which is used later down the line for sinogram histogram generation (top of 2_S3DXRD... .ipynb) for the whole sample mask

[jonwright]

Might be better to use dataset.sinohist for whole sample sinograms and fix the problem in there.
We had a bunch of data using a "full1" or "f2scan" which was always going forward to be quicker - that case will need testing and debugging again at some point. Especially if we upgrade the huber tower to spin faster.

[jadball]

I'll take a look at the notebooks using a 360 scan as a test dataset and try to use sinohist going forward