Question regarding MGH_POLY_INSIDE vs MGH_PNPOLY

[Matt Considine]

Hi again,
I'm trying to figure out why a mask routine doesn't seem to be working. Test code follows, but the long-and-short of it is that the MGH_POLY_INSIDE routine returns the correct mask while MGH_PNPOLY does not. They both take the same arguments, but differ only in their approach to solving the problem. Or so I thought. Does anyone have experience with this? Thanks,
Matt

PS This assumes that the MGH_MOTLEY library is installed, e.g.
https://sourceforge.net/projects/mghmotley/

[code]
;identify the image file
file = filepath('people.jpg',subdir=['examples','data'])
;read image. it's 256x256 full color
testimg = read_image(file)
;create a window
window, 0, title="test image"
;display image. NOTE THAT THIS WINDOW WILL NOT RESIZE/BEHAVE WELL
tv, testimg, true=1

xvert= [98,132,187,200,203,155,123,85,91,98]
yvert = [167,204,190,174,116,49,50,109,160,167]

max_xvert = MAX(xvert,MIN=min_xvert)
max_yvert = MAX(yvert,MIN=min_yvert)

xvert_range = max_xvert - min_xvert
yvert_range = max_yvert - min_yvert

; which is the larger dimension?

maxside = xvert_range > yvert_range

bounding_box_x = [min_xvert,min_xvert,min_xvert+maxside,min_xvert+maxside,min_xvert]
bounding_box_y = [min_yvert,min_yvert+maxside, min_yvert+maxside,min_yvert,min_yvert]

;set up mask coordinates
xtest = indgen(maxside) # (intarr(maxside)+1)
ytest = (intarr(maxside)+1) # indgen(maxside)

;shift the coordinates
xtest = xtest + min_xvert
ytest = ytest + min_yvert

xtest_image = (indgen(xs) # (intarr(xs)+1)) + min_xvert
ytest_image = ((intarr(ys)+1) # indgen(ys)) + min_yvert

mgh_mask = mgh_poly_inside(xtest,ytest,xvert,yvert) *255 ;MATTC mask is CORRECT
window, 1, title="first mask"
tv,mgh_mask

mgh_mask_pnpoly = mgh_pnpoly(xtest,ytest,xvert,yvert)*255 ;MATTC mask is *INCORRECT*
window, 2, title="second mask"  
tv,mgh_mask_pnpoly

end
[/code]

[giloo]

Hello,
Trying the procedure I get:

GDL> xtest_image = (indgen(xs) # (intarr(xs)+1)) + min_xvert
% INDGEN: Variable is undefined: XS
% Execution halted at: $MAIN$          

But anyway this is hopeless at the moment: the MGH_MOTLEY library uses IDLGr_XXXX objects not implemented in GDL, plus POLYFILLV (idem). These are indeed on our todo list, but the current version, or the next one will not have them, sorry.

[Matt Considine]

Whoops! My mistake. Cutting and pasting omitted two lines that should be at the top :
xs=256
ys=256

Still, I believe this code was run in IDL and returned different masks. So while the MOTLEY library may use objects not implemented in GDL, I don't believe these two routines have that problem.

Thank you for taking the time to try the code!
Best regards,
Matt

PS I have asked Mark Hadfield about this and am awaiting a reply

[giloo]

Actually, your procedure works with GDL under linux (see image attached).
I have checked, IDL give the very same plots/image/masks.
I do not know where the problem is, or if there is one, but the good news is the full compatiblity between GDL and IDL!

[Matt Considine]

The problem is the mask in the upper left. It should look like the mask in the lower right. But - yes - it is good news that the result is the same between GDL and IDL :)

It turns out this is a bug in the MGH_PNPOLY routine and Mark Hadfield has fixed it. His website contains new code, though I suppose that is at the risk of other incompatibilities. For example, when I now run the above code, I get a message saying that a return dataype of BOOLEAN (vs the prior return type of BYTE) is causing a problem.

Is BOOLEAN defined as a datatype that can be returned by a function?

[GregJung]

I can confirm the same result in windows, visually as Gilles' Linux run.

I recommend that if you are to run on windows that you set up to build from the CVS. The windows
binary download is built with specific versions of support libraries, it would be a truly PITA to support a proper distribution on a regular basis.
I have left several notes here about building GDL with windows - the upshot is to install msys2 and compile for mingw-w64 - i686 or x86_64. The pacman retrieval allows download of -most- of the required support libraries in binary form, compiled with a the same mingw-w64 compiler you are using. Installing msys2 will occupy about 1-3 GB depending on whether QT support is maintained.
I suppose MSVC can be used but the finish line is much further down the road in that case, since
you should then be building the requisite support libraries. If you have already built up a wxWidgets library then it may not be too far off.

W.r.t. AVIpack, though, I would wholly recommend that a dual-boot linux partition be used. Accessing the windows (NTFS) files from linux is completely transparent these days, I use the same names ( i.e. /c/, /d, /e) as I use in msys2. The best config for this is from a separate physical disk in a desktop system.
As a user of OpenSuse, I can recommend the Debian Jesse distro because it has the most complete supply of compatible, tested, software packages. While testing plplot against all of its possible bindings
I found a few gaps and snags in the opensuse distributions, whereas the SW available for Debian all worked well.