Incompatible dimension error in type conversion from `mwSize*` to `int*`

[szcf-weiya]

Hello, thanks for your great work!
I am trying to run the program in Ubuntu 18.04 with R2019a installed. First of all, I compiled the CPP files with GCC7.5, all is OK although I have to add some type conversions since it throws errors like

/Segmentation/Watershed/SeededWatershed.cpp:156:46: error: cannot convert ‘const mwSize*
{aka const long unsigned int*}’ to ‘const int*’ in initialization
const int *dims = mxGetDimensions(prhs[0]); // Array of image dimensions.

With following modifications,

$ diff SeededWatershed.cpp original-SeededWatershed.cpp 
156c156
<     const mwSize *dims = mxGetDimensions(prhs[0]);  // Array of image dimensions.
---
>     const int *dims = mxGetDimensions(prhs[0]);  // Array of image dimensions.
$ diff MergeWatersheds.cpp original-MergeWatersheds.cpp 
36c36
< 	const mwSize *dims = mxGetDimensions(prhs[0]);  // Array of image dimensions.
---
> 	const int *dims = mxGetDimensions(prhs[0]);  // Array of image dimensions.
57c57
< 	MergeSegments(numDims, (int*)dims, aLabels, aImage, aMergeThreshold, aMinSize, oNewLabels);
---
> 	MergeSegments(numDims, dims, aLabels, aImage, aMergeThreshold, aMinSize, oNewLabels);

I can successfully finish the compilation.

However, I am struggling in the error when I apply the program on the dataset http://data.celltrackingchallenge.net/training-datasets/Fluo-N2DH-SIM+.zip

Unexpected Standard exception from MEX file.
What() is:std::bad_array_new_length
..

Error in Track (line 180)
    numDets,...

Error in RunBaxterAlgorithms_ISBI_2020 (line 63)
    cells = Track(imData,...

BTW, actually I am using the version downloaded from http://celltrackingchallenge.net/participants/KTH-SE/, but it seems that it agrees with the latest version here.
Then I dig into the program and determine the bug should occur on the following line

BaxterAlgorithms/Tracking/Viterbi/CellTrellis.cpp

Lines 53 to 54 in 4f52463

	// Add count objects to detections.
	double *tmpCountProbs = new double[aMaxCount+1];

and I print out aMaxCount, which surprisingly equals to -3!! Then I note the type conversion in

BaxterAlgorithms/Tracking/Viterbi/ViterbiTrackLinking.cpp

Lines 72 to 80 in 4f52463

	// Get the dimensions of the inputs.
	const int *countSize = (int*) mxGetDimensions(prhs[1]);
	const int *migSize = (int*) mxGetDimensions(prhs[2]);
	const int *mitSize = (int*) mxGetDimensions(prhs[3]);
	const int *apoSize = (int*) mxGetDimensions(prhs[4]);
	const int *appearSize = (int*) mxGetDimensions(prhs[5]);
	const int *disappearSize = (int*) mxGetDimensions(prhs[6]);
	int tMax = (int) mxGetNumberOfElements(prhs[0]); // Allow numDetsA to be either row or column vector.
	int maxCount = countSize[1]-3; // first element is t, second is detection index and the third is the debris probability

Write a separate toy script to figure out what happens,

// file toy.cpp
#include <math.h>
#include <matrix.h>
#include <mex.h>
#include <stdio.h> 
#include <cstdlib>
#include <iostream>

using namespace std;

void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
  cout << "first dim = " << mxGetDimensions(prhs[0])[0] << ", "
          "second dim = " << mxGetDimensions(prhs[0])[1] << endl; 
  const int *dims = (int*) mxGetDimensions(prhs[0]);
  cout << "dims[0] = " << dims[0] << ", "
       << "dims[1] = " << dims[1] << ", "
       << "dims[2] = " << dims[2] << ", "
       << "dims[3] = " << dims[3] << endl; 
}

the output is

>> mex toy.cpp
>> toy(rand(2,3))
first dim = 2, second dim = 3
dims[0] = 2, dims[1] = 0, dims[2] = 3, dims[3] = 0

Amazing!! Here is a gap with zero!!
Then I am guessing this phenomenon should be due to the bits difference between these two types. Finally, I found the official description of the 32-bit/64-bit API of MEX, https://www.mathworks.com/help/matlab/matlab_external/upgrading-mex-files-to-use-64-bit-api.html. And I try to compile the above toy example with -compatibleArrayDims option, it looks OK!

>> mex -compatibleArrayDims toy.cpp
>> toy(rand(2,3))
first dim = 2, second dim = 3
dims[0] = 2, dims[1] = 3, dims[2] = 0, dims[3] = 0

Now back to your program, we need -compatibleArrayDims to avoid such error, but I am thinking it seems more suitable to replace the type conversion from swSize* to int* with direct use of swSize*.

[klasma]

Thank you very much for pointing this out. Sorry that I have not had time to look into this yet. I am guessing that the Linux compiler handles these conversions differently than the Windows compiler. I will try to fix the error so that the code works on both Windows and Linux.

[klasma]

I just pushed the commit "Removed type conversions from mwSize* to int* in mex files." to master. I switched to direct use of mwSize as you suggested. I still cast some of the values to int to avoid having mwSize everywhere, but I no longer cast the pointers. Let me know if this does not solve your problem or if you see a better way of implementing this.