By the way, you have more than 2 billion fixels in that file…
The number of entries in that image is not the number of fixels, but the number of fixel-fixel connections. Following the typical pipeline usually results in ~500K fixels, and around ~500M - 1B fixel-fixel connections. So it’s not hard to see that by having 4.6M fixels - an order of magnitude larger than normal - the number of fixel-fixel connections could easily exceed 2B. This doesn’t cause an issue at the
fixelconnectivity stage because the export of that particular image is done using custom code that doesn’t utilise the standard image backend library.
There’s no way you’d be able to run
fixelcfestats with that, for instance, you’d need terabytes of RAM for that…
Apart from being orders of magnitude off,
fixelcfestats also now requires very little RAM, as long as it can memory-map the previously stored fixel-fixel connectivity matrix. It’s
fixelconnectivity that’s the heavy consumer, and the fact that the issue is encountered at the
fixelfilter stage suggests that it was in fact successful despite these numbers.
tcksift: [WARNING] filtering has reached quantisation error but desired termination criterion has not been met;
tcksift: [WARNING] disabling cost function quantisation check
This is unrelated. All this says is that the quanitsation check, as described in the SIFT manuscript, which in the absence of the use of a
-term_* command-line option results in termination of the algorithm, was disabled, because you explicitly requested that filtering be performed to a greater extent, and it’s therefore doing everything it can to try to reach that desired termination criterion. This error messages regularly causes questions, but I honestly don’t know how to re-phrase the error message without turning it into a paragraph.