Repository navigation
Conversation
…D#674) ubi_to_rgb(ubis, group, view, key, axis) gives TSL and HSV inverse pole figure colours for all 32 point groups, their settings and the R groups on rhombohedral axes. No B matrix or Cartesian frame: the fold uses integer operations on uvw, angles use the symmetrised metric (warns above 5e-3 strain). key_image / plot_key draw the legend. The keys (ImageD11/ipf_keys.py) and the check colours (test/ipf_oracle.json) are generated from MATLAB MTEX 7.2.0 by test/ipf_keys/. Differences from MTEX, measured on the check directions: the hue integral is exact (MTEX: 5.5e-5), the 4-corner centre is the area centroid (TSL m-3, 23: 4.7e-3), and the HSV hue correction starts at 0 (MTEX starts at 1.7e-3 and jumps on one half circle: up to 9.5e-3). Maths: docs/sphx/ipf_colour_math.md. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The sector of a key is the same figure in every metric its group allows (tested to 1e-12 at 20 % strain), so the hue integral is tabulated once per call and each grain only integrates the rest of one piece. Colours change by 2.3e-13; 1e6 ubi take 2-8 s on one core instead of 14-21 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
unitcell.get_ipf_colour*, grain.get_ipf_colour, nb_utils.get_rgbs_for_grains, TensorMap.get_ipf_maps and the nb_utils inverse pole figure plots use rgb_colors instead of orix, with key="tsl" or "hsv". The point group comes from the space group (unitcell.ipf_group). Colours from ubi use each ubi's own metric (grains, TensorMap voxels); from U or an orix orientation, the unit cell's. rgb_colors.plot_ipf draws grains on the key, zoomed to the sector. orix orientations stay (get_orix_orien*, get_ubi_from_orix_orien). get_ipf_maps now skips voxels with a NaN UBI (it raised before when any were present). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
I suggest we don't merge without some way to refactor and manage the complexity (e.g. move into a sub-module with it's own tests in there) |
ImageD11/rgb_colors/ holds the code, key table, maths doc, tests and the key-generation tools. test/test_rgb_colors.py imports its tests for CI. unitcell, grain, nb_utils and TensorMap take backend="rgb_colors" (default) or "orix" (the previous orix TSL code, unchanged). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
|
@jadball : In theory this should be ready to merge now, and replace the other open IPF PR. But it is Claude written and largely untested. For now, I don't have a clear idea how to recognise correct colors...! |
|
I trust it better than code I can write - please feel free to merge. There are some basic sensible checks you can do as a human - pick a unit cell, align one of its real-space axes (a,b,c) to a direction in the sample frame (e.g. put b along y), then look at the IPF plot along that sample direction. You should see, for IPF-y, a dot in [010]. For the colouring, it then depends on the key, which different programs choose differently... |
Entirely by Claude (deepseek did not succeed).
While impressive, my feeling is that there is currently too much in here to merge as is. The reason to generate it are:
I wonder if this should re-factor as a folder submodule (like ImageD11.rgb_color) with the code bomb contained inside a folder and a user selectable 'backend' for using pymtex vs orix and just the simplified API. Adding so many lines of generated code is a bit of a concern, especially as this essentially duplicates other packages.