Skip to content

Ipf rgb color reimplementation - #683

Open
jonwright wants to merge 4 commits into
FABLE-3DXRD:masterfrom
jonwright:ipf-wire
Open

jonwright wants to merge 4 commits into
FABLE-3DXRD:masterfrom
jonwright:ipf-wire

Conversation

@jonwright

Copy link
Copy Markdown
Member

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:

  • orix only has 112/m with c unique for monoclinic, and no one uses that setting (we could ask the orix people about that)
  • pymtex is currently numpy 2
  • only mtex/pymtex offer HSV colors rather than TSL,, and these have fewer jumps for lower symmetries
  • the calculation should not rely on any B matrix convention, so there is no origin choice for orientation space when selecting the colors from a key.

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.

jonwright and others added 3 commits November 4, 2026 08:19
…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>
@jonwright
jonwright requested a review from jadball November 4, 2026 13:01
@jonwright

Copy link
Copy Markdown
Member Author

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>
@jonwright

Copy link
Copy Markdown
Member Author

@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...!

@jadball

jadball commented Nov 10, 2026

Copy link
Copy Markdown
Contributor

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...

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants