The fix you did for my CPU works. But, it's not all golden. Following is from Claude again:
Environment
- App version: V1.1.5 (Windows build)
- CPU: AMD Ryzen 5 5600G (Zen 3)
- GPU: NVIDIA GeForce RTX 4080 SUPER, CUDA install chosen
- OS: Windows 11
Follow-up to the texrecon AVX-512 crash report — testing V1.1.5, which claims to fix it. Found four separate issues.
1. Dependency auto-update did not actually replace texrecon.exe
After installing CUDA dependencies for V1.1.5 (fresh app launch, clicked through the install prompt), the texrecon.exe left in %APPDATA%\com.example\simple_photogrammetry_gui\texrecon\texrecon.exe was still the old, crashing binary (MD5 69db6f805c736dc7f7dd31f4dc247e61, still crashes with STATUS_ILLEGAL_INSTRUCTION on --help), not the new one bundled in the V1.1.5 release zip's texrecon.zip (MD5 6dbca56a57d73abcdd3052a1c6362607, confirmed working). Manually overwriting the folder with the contents of the release zip's texrecon.zip fixed it — so the fix is real, but whatever install/update logic is supposed to detect and replace an outdated dependency isn't doing so for an existing install being upgraded from V1.1.4 to V1.1.5.
2. GUI never actually launches texrecon (silent hang at "Texturing Mesh")
After manually fixing the binary above and rerunning a full reconstruction through the GUI, every stage up through mesh decimation completed correctly on disk (model_surface_decimated.ply, images_scaled/project.nvm, etc. all present and valid). The UI then sat on "Texturing Mesh" indefinitely (30+ minutes, no crash, no error, no Windows Event Log entry). Checking the process tree, simple_photogrammetry_gui.exe had zero child processes at that point — texrecon.exe was never actually launched. Running texrecon.exe manually from the command line against the same images_scaled/project.nvm + model_surface_decimated.ply the app had already produced worked correctly and completed in ~45 minutes (the view-optimization step is just slow on a 2.6M-face mesh on CPU), confirming the underlying binary is fine — this looks like a separate bug in the app's process-invocation/orchestration for this step.
3. Spaces in source image filenames still break the pipeline (OpenMVS DensifyPointCloud)
Reported since this seems to be an explicit design goal — the V1.1.4 changelog mentions "allows spaces in file paths." Source photos named like 2021-08-27 10.04.11.jpg (space between date and time — a common pattern, e.g. from phone camera exports) still break the pipeline: openMVS\DensifyPointCloud.exe truncates the image path at the first space and fails:
error: unknown image format 'K:/.../dense/images/2021-08-27'
error: failed loading image header
error: preparing images for dense reconstruction failed (errors loading images)
COLMAP's own stages (feature extraction, sparse reconstruction, images.txt export) handle the space correctly — only the OpenMVS DensifyPointCloud stage mishandles it, seemingly splitting the image list/path on whitespace instead of treating each line/entry as a single filename. Workaround: renaming photos to replace spaces with underscores before processing fixes it. Worth checking how the image list is generated/parsed for DensifyPointCloud specifically, since the app's own path handling (and COLMAP) already do this correctly elsewhere.
4. Mesh orientation differs depending on which texturing path is used
Once the manual texrecon run above (issue 2 workaround) completed and the resulting .obj was opened in Blender, the model came out upside down. For comparison, an earlier textured mesh produced via OpenMVS's own ReconstructMesh + TextureMesh (worked around the original AVX-512 crash in V1.1.4 the same way) came out in the correct orientation. The likely cause: texrecon consumes the images_scaled/project.nvm bundle (VisualSFM NVM format), which uses a different up-axis/coordinate convention than OpenMVS's native .mvs scene that ReconstructMesh/TextureMesh operate in directly — so the two texturing backends end up with differently-oriented output for the same underlying reconstruction. Not sure whether this is a real bug in how the NVM export is generated/consumed versus an inherent convention mismatch between the two texturing tools, but flagging it since it means the app's actual (texrecon-based) pipeline produces meshes that need a manual 180° rotation to orient correctly, at least on this project.
The fix you did for my CPU works. But, it's not all golden. Following is from Claude again:
Environment
Follow-up to the texrecon AVX-512 crash report — testing V1.1.5, which claims to fix it. Found four separate issues.
1. Dependency auto-update did not actually replace texrecon.exe
After installing CUDA dependencies for V1.1.5 (fresh app launch, clicked through the install prompt), the
texrecon.exeleft in%APPDATA%\com.example\simple_photogrammetry_gui\texrecon\texrecon.exewas still the old, crashing binary (MD569db6f805c736dc7f7dd31f4dc247e61, still crashes withSTATUS_ILLEGAL_INSTRUCTIONon--help), not the new one bundled in the V1.1.5 release zip'stexrecon.zip(MD56dbca56a57d73abcdd3052a1c6362607, confirmed working). Manually overwriting the folder with the contents of the release zip'stexrecon.zipfixed it — so the fix is real, but whatever install/update logic is supposed to detect and replace an outdated dependency isn't doing so for an existing install being upgraded from V1.1.4 to V1.1.5.2. GUI never actually launches texrecon (silent hang at "Texturing Mesh")
After manually fixing the binary above and rerunning a full reconstruction through the GUI, every stage up through mesh decimation completed correctly on disk (
model_surface_decimated.ply,images_scaled/project.nvm, etc. all present and valid). The UI then sat on "Texturing Mesh" indefinitely (30+ minutes, no crash, no error, no Windows Event Log entry). Checking the process tree,simple_photogrammetry_gui.exehad zero child processes at that point —texrecon.exewas never actually launched. Runningtexrecon.exemanually from the command line against the sameimages_scaled/project.nvm+model_surface_decimated.plythe app had already produced worked correctly and completed in ~45 minutes (the view-optimization step is just slow on a 2.6M-face mesh on CPU), confirming the underlying binary is fine — this looks like a separate bug in the app's process-invocation/orchestration for this step.3. Spaces in source image filenames still break the pipeline (OpenMVS DensifyPointCloud)
Reported since this seems to be an explicit design goal — the V1.1.4 changelog mentions "allows spaces in file paths." Source photos named like
2021-08-27 10.04.11.jpg(space between date and time — a common pattern, e.g. from phone camera exports) still break the pipeline:openMVS\DensifyPointCloud.exetruncates the image path at the first space and fails:COLMAP's own stages (feature extraction, sparse reconstruction,
images.txtexport) handle the space correctly — only the OpenMVSDensifyPointCloudstage mishandles it, seemingly splitting the image list/path on whitespace instead of treating each line/entry as a single filename. Workaround: renaming photos to replace spaces with underscores before processing fixes it. Worth checking how the image list is generated/parsed forDensifyPointCloudspecifically, since the app's own path handling (and COLMAP) already do this correctly elsewhere.4. Mesh orientation differs depending on which texturing path is used
Once the manual
texreconrun above (issue 2 workaround) completed and the resulting.objwas opened in Blender, the model came out upside down. For comparison, an earlier textured mesh produced via OpenMVS's ownReconstructMesh+TextureMesh(worked around the original AVX-512 crash in V1.1.4 the same way) came out in the correct orientation. The likely cause:texreconconsumes theimages_scaled/project.nvmbundle (VisualSFM NVM format), which uses a different up-axis/coordinate convention than OpenMVS's native.mvsscene thatReconstructMesh/TextureMeshoperate in directly — so the two texturing backends end up with differently-oriented output for the same underlying reconstruction. Not sure whether this is a real bug in how the NVM export is generated/consumed versus an inherent convention mismatch between the two texturing tools, but flagging it since it means the app's actual (texrecon-based) pipeline produces meshes that need a manual 180° rotation to orient correctly, at least on this project.