Comparing orientations between EDAX and Oxford format hexagonal-symmetry datasets

[Gregory Sparks]

[MTEX version 5.2.8]

I have two EBSD datasets taken from approximately the same area of a HCP Ti sample at different times. One was collected using EDAX hardware and software (data is stored as a .ang text file). The other was taken using an Oxford system (data is stored as a .ctf text file). I was trying to compare orientations between equivalent grains in the two datasets (e.g. get the average orientation within a grain from each dataset, then use the "angle" function to find the angle between those two mean orientations). However, the different definitions for the EDAX and Oxford data formats mean that even two "equivalent" grains (displaying similar/identical IPF map colors and clearly identifiable as the same grain from boundary shape) actually have substantially different orientations as defined internally in MTEX, because of the 30° basis vector rotation between the two formats. Does MTEX have a way to adjust for this by transforming one set of orientation values, during data import or otherwise? I found the "rotate" function for EBSD data with the 'keepXY' flag that can change Euler angles, but from the documentation that seems to be designed to rotate all Euler angles in a dataset around a fixed axis in the sample frame, which isn't what is required. I also tried the .transformReferenceFrame function, but that didn't seem to do what I wanted either, at least the way I was using it. I'm pretty sure using the same crystal symmetry definition while loading the two files isn't the way to go, since that messes up the IPF maps for the dataset using the wrong symmetry definition. 

The brute force way is to just open the .ctf data in OIM Analysis (which I know does have such a transformation routine, as it automatically offers to do so when importing a .ctf file) and then re-save it in .ang format, but I was hoping there was some way to do it purely in MTEX. I can run the latter on my personal computer, while for OIMA I have to get access to one of the workstations with OIMA licenses. Plus, converting raw data from one format to another like that always makes things a bit messy. But if there's no way around it, I'll just have to add another step to my data processing pipeline. 

Thanks,

Greg

[Rüdiger Kilian]

Hi Greg,

Oxford / Edax systems use the opposite reference systems for hexagonal/trigonal symmetry ('X||a' and 'Y||a'), see here: https://mtex-toolbox.github.io/CrystalReferenceSystem.html

If this is ignored, there will be rotation 30 degree.

Did you take this into account?

Cheers,

Rüdiger

[Gregory Sparks]

Hi Rüdiger,

As far as I know, this was taken into account. The code for importing the data is as below (barring the data paths):

fname1 = 'C:\path\to\EDAX\data.ang';
CSang = {...
  'notIndexed',...
  crystalSymmetry('6/mmm', [3 3 4.7], 'X||a', 'Y||b*', 'Z||c*', 'mineral', 'Ti', 'color', [0.53 0.81 0.98])};


fname2 = 'C:\path\to\Oxford\data.ctf';
CSctf = {...
  'notIndexed',...
  crystalSymmetry('6/mmm', [3 3 4.7], 'X||a*', 'Y||b', 'Z||c*', 'mineral', 'Ti', 'color', [0.53 0.81 0.98])};


setMTEXpref('xAxisDirection','east');
setMTEXpref('zAxisDirection','intoPlane')


data{1} = EBSD.load(fname1,CSang,'interface','ang','convertEuler2SpatialReferenceFrame', 'setting 2');
data{2} = EBSD.load(fname2,CSctf,'interface','ctf','convertEuler2SpatialReferenceFrame');

The crystalSymmetry definitions were modeled after those created by the import_wizard function for their respective files. Are they incorrect?

Thanks,

Greg

Addendum: I am getting different results from two scripts that should nominally be doing the same thing, although the code is not identical between the two. I will report back once I investigate this in more detail. 

Edit: Found the cause of the difference, in one case I had angle(ori1, ori2) and in the other I had angle(ori1,ori2)/degree, so the calculated angles were not in the same units. After converting both to degrees the answers are identical, but I'm still not getting small angles between theoretically similar orientations. angle() does output in radians, correct? 

[David Grund]

I observed a similar behaviour and wanted to share it.

When I import a file using the import_wizard and select any valid referencesystem apart from the default ( X | | a*, Y | | b) for hexagonal-symmetry, it automatically jumps back to the default when I switch to the next phase and switch back to the previous. Even if I don't "check" on the system and I import the file directly or create a script it uses the default reference system instead of my selected.

[Rüdiger Kilian]

Hi Greg,

I just checked with an EDAX and an Oxford file and I get

'X||a*', 'Y||b'

from the Oxford file and

'X||a', 'Y||b*'

from the EDAX file and this seems correct for me. Could you share the (mean) Euler angle(s) for both grains, and potentially all lines of code used to derive those?

David, with respect to import_wizard not registering the user defined symmetry, this is clearly a bug and shall be fixed, so thanks for reporting that.

Cheers,

Rüdiger

[Gregory Sparks]

Hi Rüdiger,

Thanks for confirming that I set up the symmetries correctly! The datasets have a matching large grain in the upper left corner, so a quick code for single corresponding Euler angles from each dataset is as follows (using the data imported as described above): 

roi = [0 0 50 50];
data{1} = data{1}(inpolygon(data{1},roi));
data{2} = data{2}(inpolygon(data{2},roi));


e1 = mean(data{1}('Ti').orientations)
e2 = mean(data{2}('Ti').orientations)
mis = angle(e1,e2)/degree

The resulting MATLAB output is as follows:

e1 = orientation (show methods, plot)
  size: 1 x 1
  crystal symmetry : Ti (6/mmm, X||a, Y||b*, Z||c)
  specimen symmetry: 1
 
  Bunge Euler angles in degree
     phi1     Phi    phi2    Inv.
  110.516 34.1986 255.299       0
 
 
e2 = orientation (show methods, plot)
  size: 1 x 1
  crystal symmetry : Ti (6/mmm, X||a*, Y||b, Z||c)
  specimen symmetry: 1
 
  Bunge Euler angles in degree
     phi1     Phi    phi2    Inv.
  291.336 34.3524 48.3993       0
 
 
  The involved symmetries have different reference systems
  1: Ti (6/mmm, X||a*, Y||b, Z||c)
  2: Ti (6/mmm, X||a, Y||b*, Z||c)
  I'm going to transform the data from the first one to the second one
 


mis =


   68.6561

I should note that today I got access to an OIMA workstation and re-checked the raw data, and am now suspicious that something weird is going on with the .ctf data. When I load the .ang and the .ctf data into OIMA and check pole figures, choosing the "rotate basis vectors by 30°" option for the .ctf, they of course still do not match at first (since the coordinate systems were differently defined for the two data collection systems). However, this should be correctable by a combination of 90° rotations. I found that this was NOT possible, with the .ctf data being 30° off from the .ang data at best. However, if I re-loaded the .ctf data into OIMA and did NOT choose the "rotate basis vectors by 30°" option, I was able to bring the two data sets into good coincidence using 90° rotations. That's not how it's supposed to work, is it? Possibly a setting was changed somewhere in the Oxford collection system / software. 

Experimentally, I also found that in MTEX, with the data imported as it is now and as described above, if I rotate the Euler angles of either data set by 180° about the z-axis using e.g.

rotate(data{2}('Ti'), 180*degree, 'keepXY')

the datasets come into good coincidence. This does mimic the effect of the EDAX data having been collected in "Setting 1" rather than "Setting 2", but I am >95% confident that the EDAX data was collected in Setting 2. It was still set to that when I checked recently (although the EDAX data was admittedly collected a while ago), and I don't think anyone ever really changed it. The raw .osc file used to generate the .ang file also defaults to Setting 2 when imported into OIMA. 

Thanks,

Greg

[Rüdiger Kilian]

Hi,

I was going to say, the data is related by a 180° rotation around z which makes me wonder if you'd have of the rare systems where this roation isn't required. The option 'convertEuler2SpatialReferenceFrame' in the ctf interface does exactly do this rotation to correct the misalignement of the different coordinate systems usually present on many Oxford systems to just have one single x,y coordinate system in Mtex.

Can you comment also which software you used to export the ctf? There used to be some menu on Aztec (I guess it might still be there) to specify the reference frames for exporting ctf. However, apparently for early software version they did basically nothing. Maybe now it does and you picked the correct setup or your system is set up in a way that it does not need the 180 degree rotation?

Cheers,

Rüdiger

[Gregory Sparks]

I am now confident that this is the answer! In the AZtec software, there is a page for "Specimen Geometry" that lets you pick the orientation of the "CS0" ("sample") coordinate system. There are six preset values that can be picked, or a custom coordinate system can be defined manually (you may or may not be allowed to select non-90° rotations for this; I didn't check). The page actually explicitly says that this CS0 system is not used internally by AZtec, as it instead uses the "CS1" ("acquisition") coordinate system internally, but that if the data is exported to a Channel5 Project (which includes .CTF files), then it will be affected by the choice of CS0  system. I'm not sure which is the default setting, but from the drawing of the sample with the coordinate axes labeled shown in the menu, I was able to determine that the correct rotation to transform the CS0 axis to the spatial reference frame for my case was a 180° rotation about the y-axis (not the x-axis as is done by the default CTF importer), and verified that this brought my data sets together as it should. 

I should also note that the exported CTF files appear to actually record this choice of coordinate system, specifically by recording Euler angle triplets between the the CS0 and CS1 coordinate systems (for my data this was (0,0,0); the coordinate systems were the same). These are recorded as part of the CTF header like so:

AcqE1    0.0000
AcqE2    0.0000
AcqE3    0.0000

It should be possible to write a new CTF import function that automatically reads off these angles and then applies the correct transformation to the imported data, similarly to how the ANG importer applies different rotations for "setting 1", "setting 2", etc, but automated instead of manual, since the coordinate system used is actually recorded in the data file. I'm not sure how new the AZtec software needs to be before this matters, though ... this system is pretty new, but I have no experience with any older versions of AZtec, so it might have been present there as well. 

Thank you very much for your assistance, and I hope this information helps the MTEX team!

Best regards,

Greg

[Rüdiger Kilian]

Hi,
glad to hear you found the solution. The misalignment of CS1 and CS0 has caused some headache in the past (https://groups.google.com/forum/#!msg/mtexmail/EpOQo04KsmM/ugvOYTOqBgAJ).

Reading the 'AccqE' fields and planning the rotation accordingly shouldn't be very difficult. However, I'm neither sure if this hold for all software version and might be rather wrong for older ctf files. I remember that using this option bach in 2014 or so did not produce any difference in the Euler angles in the ctf files. Maybe someone who kept track on older versions might have an insight since when these rotations apply.

Cheers,

Rüdiger

[Gregory Sparks]

Hi,

I did notice that if I changed the CS0 setting in the AZtec project and re-exported the same data, the only thing that changed in the resulting CTF was the header AcqE values. The Euler angles for the crystal orientations remained the same. I thought maybe you had to change the setting and then actually collect new data to get it to properly use the new reference system, but it might just be ignoring it like you say it used to. Who knows. I'll likely just keep using this setting for the foreseeable future, since I know it works now.

Cheers,
Greg

[Rüdiger Kilian]

David,
the bug with the import_wizard (unrelated to this thread) is hopefully fixed in the recent development version.
Cheers,
Rüdiger