Hi, I am sharing reproducible findings for the registration/component export error:
"One or more images do not match with those used during the registration."
0x10003\0xa066\0x5060
(The ticket have been open to epic under the number 27091242)
There is a long-running discussion of similar symptoms here:
That thread includes reports from 2017 onward, with users reporting unchanged images and unsuccessful attempts to resolve export failures through feature detection or alignment-setting adjustments. It discusses cache, features and settings, but does not establish a decoder-related cause. I cannot say those older cases had the same cause as ours; the findings below document an additional compatibility issue worth investigating.
In our case, the source JPEGs were unchanged. Re-alignment with Force component rematch enabled completed, but exporting the explicitly selected new component still failed. We encountered this in RealityCapture 1.4.1.117425 and RealityScan 2.2.0.119430.
What we established
The same JPEG bytes produce slightly different pixels in these two environments:
- Windows 10 build 19045.6466, WindowsCodecs.dll 10.0.19041.6456.
- Windows 11 build 26300.9711, WindowsCodecs.dll 10.0.26100.9711.
Direct calls to Microsoft’s native WIC JPEG decoder reproduce the difference without RealityScan or WPF. Repeated decoding is stable within each environment: this is a difference between implementations, not random changes on every opening.
The Windows 11 DLL explicitly identifies libjpeg-turbo 3.0.2. I built (with help of an AI) the official upstream 3.0.2 source with SIMD disabled and JDCT_ISLOW, its accurate integer inverse-DCT mode. That build reproduces the entire Windows 11 image bit for bit.
We then compared the reconstructed Y/Cb/Cr component values before RGB conversion. Native Windows 10 WIC and upstream libjpeg-turbo differ by at most one level per component. Applying the SAME colour-conversion calculation to each set of component values reproduces BOTH complete Windows RGB images exactly, with zero residual mismatches.
This locates the measured difference at component reconstruction. The upstream calculation that reproduces Windows 11 is jpeg_idct_islow in jidctint.c: a two-pass fixed-point inverse DCT with intermediate and final rounding.
Source: libjpeg-turbo/jidctint.c at 3.0.2 · libjpeg-turbo/libjpeg-turbo · GitHub
For the sample, 971,973 of 20,813,856 pixels differ (4.6698%), with a maximum RGB-channel difference of 3 out of 255. This counts even tiny changes; it does not mean 4.67% of the image is visibly damaged. One-level differences in reconstructed components can become larger RGB differences during colour conversion.
This is not evidence that libjpeg-turbo is broken. At one independently evaluated pixel, ideal brightness is 24.490431…: upstream returns 24 and the older Windows decoder returns 25. The newer result is closer to the mathematical answer in that example. We have not performed formal ISO conformance testing or traced the exact optimized routine executed inside the Windows DLL. SHA-256 hashes of the files are the same but decoded-pixel hashes are different after OS upgrade, opening older project on windows 11.
Connection to component export
In a separate 35-camera test, we saved PNGs specifically preserving the Windows 10 decoded pixels. Redirecting those inputs in a project copy, while retaining and verifying the original alignment data, restored component export on Windows 11 WITHOUT re-alignment.
This strongly implicates compatibility between historical registration data and decoded image inputs. It does not reveal RealityCapture/RealityScan’s exact internal validation check; Epic needs to confirm that part. The attached sample/reproducer demonstrates the decoder difference, not a complete minimal failing registration project.
Why this matters
We maintain a multi-year photogrammetry catalogue containing historical projects and developed JPEG inputs. Component export and re-import are central to progressively extending, combining and reusing datasets while preserving established registrations, camera poses, calibrations and georeferencing.
Hardware, Windows and application versions will evolve over the lifetime of these datasets. Historical components must remain exportable and reusable when the original inputs and registration data have been retained. JPEGs provide practical storage efficiency and sufficient image quality for our downstream photogrammetry work. Re-aligning historical datasets or converting an entire catalogue to lossless images is not a sustainable compatibility strategy.
Could Epic investigate which consistency check rejects these inputs, why Force component rematch does not resolve it, and provide a supported compatibility or migration workflow preserving existing registrations and JPEG inputs?
Technical evidence and standalone reproducer: Unique Download Link | WeTransfer