IPF gridded legend rendering: PUCM produces sub-pixel edge artifacts not seen in TSL/NH
Draft GitHub issue body. Issues are disabled on imikejackson/EbsdLib;
enable them and paste this, or file under a different repo, or convert
to a TODO in the v3.1 plan.
Summary
When generate_ipf_legends (or LaueOps::generateIPFTriangleLegend(..., gridded=true)) is called with ColorKeyKind::PUCM, the resulting
gridded SST legends contain visible sub-pixel white/dark dot
artifacts along SST boundaries on most Laue classes (cubic m-3m,
cubic m-3, hex 6/m, tetragonal 4/m, trigonal -3m, trigonal -3,
monoclinic 2/m). TSL and NH gridded legends from the same code path
are artifact-free.
Sample affected outputs (after running
Bin/generate_ipf_legends and viewing
Testing/Temporary/IPF_Legend/<class>/<class>_PUCM_GRIDDED.png):
- Cubic m-3m: ~4 single-pixel white dots along the [001]–[011] edge of
the SST, evenly spaced.
- Trigonal -3m: 2 single-pixel dark dots in the upper portion of the
kite SST.
- Tetragonal 4/m, Cubic m-3, Hex 6/m: pixel-level artifacts in the
"Discontinuous Colors" SST extensions.
Root cause investigation (from the v3.0 release Phase 4.5 sweep)
The artifacts come from the inner PUCM key (wlenthe's
dispatchPucm(group, direction)) returning near-white/near-black
"singular" colors for certain (eta, chi) cell-center directions that
are well INSIDE the SST's angleLimits rectangle. The three existing
gridded fixes — b3aafc4 (chi-clamp), 89aca99 (no-push-outside-SST),
2c20533 (route 3-arg through inner key) — all live in
GriddedColorKey and are key-agnostic, so they're already applied to
PUCM via the shared decorator. But:
- TSL's closed-form
r = 1 − chi/chiMax is smooth at the SST boundary;
no singularities.
- NH's
FundamentalSectorGeometry::polarCoordinates clamps radius to
[0, 1] and produces graceful colors at boundaries.
- PUCM's
direction2Color(eta, chi, angleLimits) ignores angleLimits
entirely (line 131 of PUCMColorKey.cpp: (void)angleLimits;),
converts (eta, chi) → Vec3, and hands off to wlenthe. wlenthe has
its own per-Laue-class FZ check and produces near-singular colors at
certain (eta, chi) cell-centers that fall just outside its
fundamental sector.
Attempted no-API-change fix (fall back to unsnapped (eta, chi) when
the chi clamp triggers): tested in the v3.0 prep, did not eliminate
the visible dots. The problematic cell-centers are inside the
angleLimits rectangle but outside wlenthe's actual SST shape
(curved [011]–[111] arc on cubic m-3m, etc.).
Suggested fix (post-v3.0)
Add an isInSST(const Vec3& direction) virtual to IColorKey with a
return true default. Override in PUCMColorKey to call wlenthe's FZ
check (whatever PUCM uses internally — needs to be lifted to the
public API). In GriddedColorKey::direction2Color(eta, chi, ...),
after snapping, reconstruct the direction and test
m_InnerKey->isInSST(snappedDir). If false, fall back to the
unsnapped (eta, chi).
Scope:
- ~20 lines + 1 new virtual on
IColorKey (non-breaking; existing
inner keys outside EbsdLib compile unchanged).
PUCMColorKey gets the only non-default implementation.
- TSL and NH inherit the default and are unaffected.
Why this was deferred from v3.0
- Per-pixel IPF maps (
make_ipf, render_ebsd,
WritePoleFigureFilter's IPF outputs) do NOT go through
GriddedColorKey. They compute color per pixel directly. So the
artifacts only affect the legend rendering, not the IPF map.
- The artifacts are 1–2 pixels on a 1024–2000 px legend canvas — only
visible when zoomed into SST boundaries.
- The v3.0 release notes already characterize PUCM as a verbatim
wlenthe port. "wlenthe's edge behavior shows on our 1° grid" is
defensibly a wlenthe characteristic.
References
Source/EbsdLib/Utilities/GriddedColorKey.cpp — the gridded decorator
(where the eventual fix would land, plus the existing chi-clamp at
lines 107–114).
Source/EbsdLib/Utilities/PUCMColorKey.cpp — PUCM's wlenthe dispatch
(line 121–135). direction2Color(eta, chi, angleLimits) currently
ignores angleLimits.
Source/EbsdLib/Utilities/IColorKey.hpp — the base class that would
gain the isInSST virtual.
- Prior NH-era fixes: commits
b3aafc4, 89aca99, 2c20533. These
apply to all inner keys but don't cover wlenthe's interior
singularities.
IPF gridded legend rendering: PUCM produces sub-pixel edge artifacts not seen in TSL/NH
Summary
When
generate_ipf_legends(orLaueOps::generateIPFTriangleLegend(..., gridded=true)) is called withColorKeyKind::PUCM, the resultinggridded SST legends contain visible sub-pixel white/dark dot
artifacts along SST boundaries on most Laue classes (cubic m-3m,
cubic m-3, hex 6/m, tetragonal 4/m, trigonal -3m, trigonal -3,
monoclinic 2/m). TSL and NH gridded legends from the same code path
are artifact-free.
Sample affected outputs (after running
Bin/generate_ipf_legendsand viewingTesting/Temporary/IPF_Legend/<class>/<class>_PUCM_GRIDDED.png):the SST, evenly spaced.
kite SST.
"Discontinuous Colors" SST extensions.
Root cause investigation (from the v3.0 release Phase 4.5 sweep)
The artifacts come from the inner PUCM key (wlenthe's
dispatchPucm(group, direction)) returning near-white/near-black"singular" colors for certain
(eta, chi)cell-center directions thatare well INSIDE the SST's angleLimits rectangle. The three existing
gridded fixes —
b3aafc4(chi-clamp),89aca99(no-push-outside-SST),2c20533(route 3-arg through inner key) — all live inGriddedColorKeyand are key-agnostic, so they're already applied toPUCM via the shared decorator. But:
r = 1 − chi/chiMaxis smooth at the SST boundary;no singularities.
FundamentalSectorGeometry::polarCoordinatesclamps radius to[0, 1]and produces graceful colors at boundaries.direction2Color(eta, chi, angleLimits)ignoresangleLimitsentirely (line 131 of
PUCMColorKey.cpp:(void)angleLimits;),converts
(eta, chi)→ Vec3, and hands off to wlenthe. wlenthe hasits own per-Laue-class FZ check and produces near-singular colors at
certain
(eta, chi)cell-centers that fall just outside itsfundamental sector.
Attempted no-API-change fix (fall back to unsnapped
(eta, chi)whenthe chi clamp triggers): tested in the v3.0 prep, did not eliminate
the visible dots. The problematic cell-centers are inside the
angleLimits rectangle but outside wlenthe's actual SST shape
(curved [011]–[111] arc on cubic m-3m, etc.).
Suggested fix (post-v3.0)
Add an
isInSST(const Vec3& direction)virtual toIColorKeywith areturn truedefault. Override inPUCMColorKeyto call wlenthe's FZcheck (whatever PUCM uses internally — needs to be lifted to the
public API). In
GriddedColorKey::direction2Color(eta, chi, ...),after snapping, reconstruct the direction and test
m_InnerKey->isInSST(snappedDir). If false, fall back to theunsnapped
(eta, chi).Scope:
IColorKey(non-breaking; existinginner keys outside EbsdLib compile unchanged).
PUCMColorKeygets the only non-default implementation.Why this was deferred from v3.0
make_ipf,render_ebsd,WritePoleFigureFilter's IPF outputs) do NOT go throughGriddedColorKey. They compute color per pixel directly. So theartifacts only affect the legend rendering, not the IPF map.
visible when zoomed into SST boundaries.
wlenthe port. "wlenthe's edge behavior shows on our 1° grid" is
defensibly a wlenthe characteristic.
References
Source/EbsdLib/Utilities/GriddedColorKey.cpp— the gridded decorator(where the eventual fix would land, plus the existing chi-clamp at
lines 107–114).
Source/EbsdLib/Utilities/PUCMColorKey.cpp— PUCM's wlenthe dispatch(line 121–135).
direction2Color(eta, chi, angleLimits)currentlyignores
angleLimits.Source/EbsdLib/Utilities/IColorKey.hpp— the base class that wouldgain the
isInSSTvirtual.b3aafc4,89aca99,2c20533. Theseapply to all inner keys but don't cover wlenthe's interior
singularities.