AZtecCrystal data export and Grain boundary fitting issues #113
Replies: 6 comments 1 reply
-
|
Beta Was this translation helpful? Give feedback.
-
Thank you for your advice, we have tried it and have some updates. Indeed, our EBSD step size is smaller than the DIC map (more than twice), therefore this can be the source of our issues. We also tried resizing the DIC map (up to DIC step size 0.244 micron) and the overall image but the grain boundaries still do not match. Resolutions (in pixels) and pixel/step sizes of our data:
The image below shows the set-up of the homologous points in figures 15 and 16 (overall SE image and EBSD, respectively) and the reference matrix with the transformation matrix. As you can see, the transformation matrix is in the upper left corner of the image and it is significantly smaller. It is obvious, that the grain boundaries do not correspond to the DIC map in the figure 21, as I mentioned before. |
Beta Was this translation helpful? Give feedback.
-
Hello, |
Beta Was this translation helpful? Give feedback.
-
Hi @kata-neumann sorry that you are still having issues with your data alignment. I have looked briefly at your slides. On slide 2 I'm not convinced that the BS image is from the same region as the DIC map. In the DIC map middle, left I can see some straight (probably twin) boundaries where the slip bands change direction but I cannot see these boundaries in the same location of the BS image. The pattern image must be the reference image you applied the correlation to (only perhaps with the pixels binned to create a more manageable size, which is then set when setting the image path). I'm happy to have a call to try and get this issue sorted for you, just send me an email (michael.atkinson@manchester.ac.uk). |
Beta Was this translation helpful? Give feedback.
-
Hi Kata, It looks like you are getting close! To add to what Michael said, another key thing to getting an accurate match between the pattern/DIC and the EBSD map are the parameters on setPatternPath. The second argument 'windowSize' gives the scaling between the pattern image and the DIC data. This is the size of a pixel in pattern image relative to pixel size of DIC data i.e 1 means they are the same size and 2 means the pixels in the pattern are half the size of the dic data. I think you have used the EBSD/pattern ratio which will not give the correct result? |
Beta Was this translation helpful? Give feedback.
-
Hello, I have an additional question originating from our studied materials which experience TRIP or TWIP effects. Do you plan to implement into the defDAP a chance to analyze such materials? That means being able to work with EBSD map from later stages of a test (not just reference as it is now) while new interfaces and boundaries are already present. The issue is that the map will be significantly deformed and not in the original size as DIC map. |
Beta Was this translation helpful? Give feedback.
-
We have encountered the issue with data import into the DefDAP while our data are exported from AZtecCrystal v2.1 and return an error message (please below). When we use the same EBSD data exported from AZtec v5.1 it works well. We use the AZtecCrystal to crop the initial EBSD map just to the area where the DIC image acquisition was performed. What can be done to avoid the error message? Is it necessary to crop the initial EBSD data which are covering a significantly large area than DIC?
The second issue is related to the grain boundary fitting to a DIC map. After we select homologous points, the grain boundaries do not fit well on the DIC map (see below). Only the grain boundary fragments are shown in the final image. What can be the reason since we provided high-quality EBSD maps with a minimum of zero solution points? It should be also noted that obtained transformation matrix after DefDAP resolved homologous points between the EBSD map and SEM image, is significantly smaller than the reference and shifted from the central position of the plot. Could this be the reason for not completing the grain boundary overlay on the DIC map? Or can some issues originate from the SEM (pattern) image (we use a SE-detector image instead of a BSE one)?
More general questions:
Beta Was this translation helpful? Give feedback.
All reactions