OOM

Can you post the full log? Strange it crashed (this is an out of memory error, program ran out of memory)

That's all for now:
[INFO] Bundle adjustment step 1/2
[INFO] Bundle adjustment step 2/2
[INFO] Reconstruction 0: 500 images, 197603 points
[INFO] 1 partial reconstructions in total.
[INFO] Export reconstruction stats
[INFO] running "/code/SuperBuild/install/bin/opensfm/bin/opensfm" compute_statistics --diagram_max_points 100000 "/var/www/data/676218ae-3ffb-4b68-95bb-34c57f3c243b/opensfm"
[INFO] running "/code/SuperBuild/install/bin/opensfm/bin/opensfm" export_geocoords --reconstruction --proj "+proj=utm +zone=50 +datum=WGS84 +units=m +no_defs +type=crs" --offset-x 750101.0 --offset-y 4046683.0 "/var/www/data/676218ae-3ffb-4b68-95bb-34c57f3c243b/opensfm"
[INFO] Updating /var/www/data/676218ae-3ffb-4b68-95bb-34c57f3c243b/opensfm/config.yaml
[INFO] undistorted_image_max_size: 2592
[INFO] Computing band alignment
/code/run.sh: line 9: 40527 Killed python3 $RUNPATH/run.py "$@"

Mm, strange, and ODM processed it fine? did you use the same options? I haven't made many changes to the band alignment code, so I'm not sure why memory usage would differ there.

I use default option，but has five parameter differ，look at the picture

Alternatively, my container is limited to 32 GB of memory and 10 CPU cores. The default setting uses 40 threads. Since ODX heavily relies on the default parameters, it exceeds the 10‑core limit.

Nevertheless, I believe the main cause is the change in  feature‑type , which makes the program run more aggressively.

feature-type shouldn't matter; it's failing at computing band alignment, but I'm not sure why that would happen.

try with half the images, see if it works then

I am using data captured by the M3M drone: 500 JPG images plus 2000 multispectral frames (R, G, RE, NIR). The same dataset runs without any issues on ODM.

Post the full logs (not just the last lines) for both ODM and ODX, maybe we can compare the outputs and see why there would be a difference in memory usage