Results from contourc in MathScript not match

[MengHuiHanTang]

I have a simple .m file which I am trying to convert to labview code using the Mathscript Node. 

The matlab code is simple as follows

           % read image    

           im= double(imread(image_path));

           C  = contourc(im,[0.8 0.8]);

I checked the latest version of Mathscript Node. Both 'imread' and 'contourc' are supported built-in functions. So far so good. So I put the code in the Node (for contour functions in MathScript, I had three options: contour, contours, contouris. Only contour is supported by Run Time Engine, so I selected 'contour').

BUT, the result from Mathscript does not match that from Matlab. From Matlab, it is a 2X126 matrix, while from Mathscript, it is a 2X200 matrix. I tried other two contours and contouris as well, same result.

SO what is happening here. How should I match the original matlab code with a 'contourc' function in it? Thanks.  

[0utlaw]

Hello MengHuiHanTang,

Based on your description, it seems as though the MathScript node is returning higher-resolution contour lines (two identical lines at the same relative height) than you expect (200 points per contour line) - is that correct?

Without knowing more about the image you are loading as well as what the expected results actually represent, it is difficult to say why the results are not what you expect, but if you could post a sample of the image you are using as well as the expected vs. actual results (the contour plot images as well as the output arrays would be great!) we may be able to point out why this is happening.  Also, for reference- how large is the bmp image in question? (file size and pixels.) 

Additionally, it appears that you are using the "contour" pop-up plotting function, rather than the "contours" (legacy name "contourc") contour line calculating function- only the latter is supported in the run-time environment.

Regards,

[MengHuiHanTang]

Hi,Tom，

Thanks for the reply. 

My point is mainly to point out that the result from LabVIEW 'contour' is DIFFERENT from Matlab 'contour' function. In theory they should be identical, since LabVIEW MathScript is built to run .m files. So the result from Matlab code is the EXPECTED result. I am expecting LabVIEW MathScript generates the same result. But now they are different. It is not about whether 'contourc' in MathScript returns a lower or higher resolution of contour lines.

I tried 'contourc', 'contours', 'contouris' and 'contour' in MathScript. They all output the same results, but all different from the EXPECTED from Matlab code.  

The image I used for test is a black/white BMP image, 150X150 in size. The output from Matlab is a 2X126 array; the one from MathScript is a 2X200. Here is the screenshot of the results. 

It won't let me attach a BMP file. So I have to convert the original image to a png file as an attachment.

[0utlaw]

Hello MengHuiHanTang,

You're correct - the results the two environments are different.  However, this is expected- the .m standard defines a syntax, not necessarily the implementation of a function, and in some cases the results may be different depending on the underlying libraries.  In this case, that's what we are seeing, but both answers are correct.

As per this document (http://www.ni.com/white-paper/9292/en ), many MathScript functions are converted into G Code before compilation; this appears to be the case in this situation as the output of the MathScript contours (contourc) function is is nearly identical to the output of the LabVIEW Contour Line.vi. The results are not identical, but as I'm not familiar with the low-level goings-on as to how the MathScript node is parsed and converted I can't speak definitively as to why at this time.  Specifically, it appears that the result is shifted by one pixel (rising vs. falling boundary) and the MathScript result includes a duplicate point at the beginning and end of the contour line result.

If you could provide more information on the intent behind your code and/or why you require a specific number of points for your algorithm I may be able to advise as to how to decimate the data in an appropriate fashion to achieve the results you are looking for.

Best Regards

[MengHuiHanTang]

Tom,

I read through that document you provided link to. It only says how labview compilers make the execution more efficient. It does not mention anything that the same function would generate different results out of the two environments, especially when the two functions even share the same name. I would assume they are identically implemented, but they are not. Should LabVIEW MathScript team mark this fact out somewhere so other people know about it?

In my case, I don't have more information to put here. As I said in the begginnig, I had a .m file which I would like to convert to LabVIEW code, so I tried the easy route MathScript which runs .m file. I did that, but the results are different, adn you agreed. 

I will post the VI with the expected array from Matlab and the result from LabVIEW. Thanks for the reply.  

[billko]

---

@MengHuiHanTang wrote:

Tom,

I read through that document you provided link to. It only says how labview compilers make the execution more efficient. It does not mention anything that the same function would generate different results out of the two environments, especially when the two functions even share the same name. I would assume they are identically implemented, but they are not. Should LabVIEW MathScript team mark this fact out somewhere so other people know about it?

In my case, I don't have more information to put here. As I said in the begginnig, I had a .m file which I would like to convert to LabVIEW code, so I tried the easy route MathScript which runs .m file. I did that, but the results are different, adn you agreed. 

I will post the VI with the expected array from Matlab and the result from LabVIEW. Thanks for the reply.  

---

Hi, Meng:

Tom used a bit of confusing language, but what I think Tom is saying is that some Mathscript functions are mapped to the closest G equivelant, so the results may differ from what you were expecting.  I have no idea why it is that way, but because it is that way, we also have to deal with the fact that - in my experience anyway - no translation program is 100% accurate.

[MengHuiHanTang]

Tom, 

This is the VI with saved array in the front panel. I don't have any specific number of points for the contour line, just want the result from MathScript same as the one from Matlab which seems to have 126 points. So if you have any means to decimate the data, that would be great and appreciated. Thanks. 

[MengHuiHanTang]

Bill, 

I get your point. I am acturall thinking about the workaroud. But in this case, contourc is such a basic function. Without further notice, I just assumed they work the same until I tracked the error all the way back to it. If LabVIEW MathScript could simply give a friendly alert somewhere that the results might be different due to any reason, I would not make that assumption and would save a lot of time. Anyway, lesson learned. 

[billko]

---

@MengHuiHanTang wrote:

Bill, 

I get your point. I am acturall thinking about the workaroud. But in this case, contourc is such a basic function. Without further notice, I just assumed they work the same until I tracked the error all the way back to it. If LabVIEW MathScript could simply give a friendly alert somewhere that the results might be different due to any reason, I would not make that assumption and would save a lot of time. Anyway, lesson learned. 

---

I agree!  Because you were unaware of the differences, it delayed your project about a week.  😞

[0utlaw]

Hi MengHuiHanTang,

I did some digging into the differences between the results and the biggest differences between the contours returned appear to be around the sharpest "outside corners" in the image - areas where the contour transitions from an x-traverse to a y-traverse or vice-versa.  The other major difference (and potentially the reason for your question) is that the coordinate pairs returned are in reverse order (rows 0 and 1 are swapped, although you may have already realized that.)  The contours also appear to start/stop at different points.

That being said, the MathScript solution does appear to more accurately reflect the contour in your binary image:

After taking a look at that, I attempted to remove duplicate (and near-duplicate or identical when rounded off to an actual pixel value) points from both arrays provided, and this proved what I'd suspected- the only practical difference between the two results is the addition of a point at the sharp corners in the image (the reduced data sets have 99 and 102 points respectively; these are actually the plots shown above.) 

It should be possible to create an algorithm to remove these, although I don't really see why it is necessary and without a larger sample set I cannot say how doing this would actually affect your results- could you provide additional information on the intent behind this data reduction or the context in which the data will be used?  In particular, knowing where/how your algorithm is failing would be extremely helpful. Is it that you need precisely 126 points? Is the order of the points in the contour important?  Are the corners causing a problem? 

Regarding your idea for a "flag" on functions, that sounds like it would be very helpful! I'd recommend that you post in on the LabVIEW Idea Exchange. 

Regards,