Check failed: max_num_elems

[longtimenotalk2]

I'm studying the nerfies https://github.com/google/nerfies and using colmap to create a dataset of images. when execute with colmap exhaustive_matcher \ --SiftMatching.use_gpu 0 \ --database_path "{str(colmap_db_path)}" in "Nerfies_Capture_Processing.ipynb", a failure report is shown as:

F0402 02:21:26.684835 182500 cache.h:132] Check failed: max_num_elems > 0 (0 vs. 0) Check failure stack trace: @ 0x7f8caf9285cd google::LogMessage::Fail() @ 0x7f8caf92a433 google::LogMessage::SendToLog() @ 0x7f8caf92815b google::LogMessage::Flush() @ 0x7f8caf92ae1e google::LogMessageFatal::~LogMessageFatal() @ 0x744b45 colmap::LRUCache<>::LRUCache() @ 0x7394b6 colmap::FeatureMatcherCache::Setup() @ 0x739955 colmap::ExhaustiveFeatureMatcher::Run() @ 0x882ecc colmap::Thread::RunFunc() @ 0x7f8cac918b30 (unknown) @ 0x7f8cad03f6ba start_thread @ 0x7f8cabe2d41d clone @ (nil) (unknown)

I want to know the reason of this failure and how to fix it.

Thanks a lot!

[Equidamoid]

For those who find this ticket by the error message, check that:

• the image path is correct
• your libfreeimage is compiled with the image format you use enabled (mine was without jpeg by some reason)

[paudom]

Hi @Equidamoid when you say:

your libfreeimage is compiled with the image format you use enabled.

How can I see which type is enabled?

Package: freeimage
Version: 3.18.0
Port-Version: 24
Depends: imath, jxrlib, libjpeg-turbo, libpng, libraw, libwebp, openexr, openjpeg, tiff, zlib
Architecture: x64-linux
Multi-Arch: same
Abi: f03585f7da8056b44de1bca8a13acf22b0b43eedbefa486da3d23a9ad283eee5
Description: Support library for graphics image formats
Type: Port

[Equidamoid]

@paudom welp, for me this question was easy to answer: I just looked at the Portage's use flags for media-libs/freeimage.

I briefly looked into the headers installed by freeimage, and I don't see any configuration info there, so the only thing left for me now is to make assumptions (it's a looooooong time since I touched port files, and it was on mac, so it may not count). The best way to know is to look at the compilation logs, I suppose. Or write a small "hello world" that tries to open the files you have with freeimage.

I see that your package manager lists openjpeg as a dependency, so I'd guess that your freeimage is built with jpeg support. Not sure what format you need.

[Linusnie]

I had a similar issue on windows and for me the problem was due to the path to the feature files being too long. Moving the files to a base folder with shorter name solved the issue

I have LongPathsEnabled set to 1 in the registry but it doesn't seem to make a difference in this case

[r530044129]

don't use something like .png, it's too big, try the .jpg

[omrastogi]

For those who find this ticket by the error message, check that:

• the image path is correct
• your libfreeimage is compiled with the image format you use enabled (mine was without jpeg by some reason)

This helped. I had inputted the wrong path :)

[hadjiprocopis]

I can confirm what @omrastogi said about FreeImage distribution missing jpeg support when installing it on Linux Fedora using their package manager. The header file /usr/include/FreeImage.h states so (on Fedora). The solution was to download FreeImage's source code, compile and install it.

On compiling FreeImage, note that it does not support C++ standard 17. And so you must explicitly edit Makefile.XXX (where XXX is for your system, e.g. for GCC this is XXX=gnu) and add this line CXXFLAGS += -std=gnu++14 (after the bunch of similar lines).