I've hit a small but consistent issue on X-Trans bodies whose in-camera (RAF EXIF) crop origin isn't a multiple of 6 (the X-Trans CFA period). Clearest example, Fujifilm X-Pro2:

• RAF EXIF crop (RawImageCropTopLeft / RawImageCroppedSize): origin (16,16), size 6000×4000
• LibRaw output: origin (18,18), size 5998×3998

LibRaw rounds top_margin/left_margin UP to the next multiple of 6 — see src/utils/open.cpp, the X-Trans branch (`makeIs(LIBRAW_CAMERAMAKER_Fujifilm) && imgdata.idata.filters == 9`). As the code stands this is necessary: the raw CFA is cropped to the active-area margins BEFORE demosaicing, so for X-Trans the margins must land on the 6×6 CFA period — otherwise xtrans[r%6][c%6] is out of phase and the image comes out with a strong color cast (magenta on X-Pro2). We confirmed this: honoring the EXIF crop exactly (origin 16,16) without the alignment produces the magenta.

So for these bodies there's an unavoidable trade-off today: a ~2 px shift and loss of 2 rows/2 cols vs the camera's authoritative photographic area (current behavior), or correct framing but wrong color.

Possible direction for a fix: the constraint comes from cropping the CFA before demosaic. If LibRaw demosaiced the full active area first and applied the EXIF crop afterward on the demosaiced RGB (it already exposes the EXIF crop via raw_inset_crops), the crop origin could be any value with no 6-alignment needed, and the EXIF-truthful crop (16,16,6000,4000) could be honored exactly. That would mean demosaicing a few pixels into the masked/border region to feed the edge interpolation, then discarding them.

Affected: any X-Trans body whose RAF EXIF crop origin isn't a multiple of 6 (X-Pro2 is the clearest). Bodies already 6-aligned (e.g. X-E5) are unaffected.

Is honoring the EXIF crop for X-Trans (post-demosaic) feasible? Happy to provide sample RAFs. Thanks!