Mystex stage fails

Had ran ODM with few values and following were outcomes:

  1. When ran ODM with 5 files with default max_texture_size it failed with an error - ran out of memory. Here 99% of texturing step got completed and it failed at last stage

  2. Next when ran ODM with 24 files with default value it failed with std::bad_alloc error

  3. When ran ODM with max_texture_size as 26460*17004(tif file dimensions) it failed with an error bad input something…

  4. When ran ODM with max_texture_size as 32768 * 32768 or 65536 * 65536 it goes in infinite loop.

  5. When ran ODM with values above 16*1024 and below 32768 * 32768 values with failed with an error “Oh no! It looks like your CPU is not supported”

  6. In some cases it failed with an error std::bad_length

To summarize for set of tif files with following properties:

  1. Size: 1.3 GB
  2. Dimensions: 26460*17002
  3. Pixels: 550MP

Texturing fails with different error at sorting stage with above reasons

1 Like

Maybe try this:
MAX_TEXTURE_SIZE (439330 * 1024)

That should fit an entire image in one texture page… No idea how bad this will break, though.

It failed with an error std::bad_alloc

Alright, so it seems like we’re exceeding something in MVS_Texturing that just setting the MAX_TEXTURE_SIZE bigger doesn’t address.

Okay, it looks like we’re using UINT (Unsigned Integer), which I think is just slightly too small to allocate such gigantic texture dimensions into. I think this means we’d need to re-write mvs-texturing entirely to use another allocation (UINT64?) instead of UINT32.

I’m pretty sure you cannot process images this large with ODM (what kind of images are these? Satellite?)

1 Like

Can you help with updated the script?

1 Like

Trust me, you do not want me near code.

After Max_texture_size 24*1024, the script starts failing with an error std::bad_alloc…

1 Like

Yep, so like I said above, I think we’d need to be re-writing the code to use another UNIT storage that is bigger than 32bit since we’re getting larger texture dimensions than it can hold. Just adjusting the script isn’t going to address that limitation.

For Max_Texture_Size in range of (8 * 1024) and (24 * 1024), the script exits when an error - ran out of memory

Yeah got it, but who will be rewriting code? Any idea, which set of script has to be updated?

Piero, possibly, and it looks like the entire program might have to be re-written to use UNIT64 instead of UNIT32. So, all of the cpp files in mvs-texturing source tree. And I have no idea if that’s possible or what that might break.

Will be helpful, if manage to get the updated script

Any update?

Not from our end, Vivek. It looks like an absolutely massive undertaking.

Are you able to contribute code to help us?

Have been trying for few days, but didn’t work. If someone can help with some instructions will be helpful

1 Like

As far as I can tell, anything that isn’t using UINT64 or larger for value/data storage will need to be re-written, as UINT/UINT32 is what seems to be overflowing.

The texturing stage issue is now finally resolved. It worked after setting appropriate value for max_texture_size & padding size in generate_texture_atlas.cpp file and padding size in texture_atlas.cpp file.

The image texturing code is completely independent of INT type and it is capable to process images of any pixel size.

Below is the logic for calculating the Max_Texture & Padding Size for Images with larger pixels (i.e above 100 MP)

  1. Update generate_texture_atlases.cpp with std::cout statement after line 43 to fetch “padding value” & after line 47 to fetch width & height value

  2. Next, update texture_atlas.cpp with following:

    • Include #include after line 16
    • Add std:cout statement after line 66 to print width & height value
  3. Compile files(follow instructions mentioned git read section) to generate binary files and print (padding, width & height values).

Using above printed values, the logic to set “Max_Texture_Size” → “It value should be bit less the Image Width Size”

In our case, the Image(size 1.3 GB) its width was 26460 and its Max_Texture_Size is 26702.

Please note, in order to derive right value of Max_Texture_Size it may require some trails & hit.

Below are some common errors & their reason:

  1. Ran out of Memory: Max_Texture_Size is too less and texturing stage failed after Image sorting.

2.std::bad_alloc error: Max_Texture_Size value is too high

The max_texture_size value should be little less then the max width size of image.

1 Like

Hope the above information will be helpful to the community.