How are the java files in package org.sikuli.basics.proxies generated from C/C++ code using SWIG ?

LOL, I am new to SWIG too ;-)

Your big advantage (which is my hope on getting further) is your much deeper knowledge about C/C++ (I can "read" C++ stuff, but until know I did not dare to make substantial changes to the native level))

This is the command file I once used to produce the "swigged" stuff on Windows (until I found out, that I only need to swig on my Mac and the generated stuff will be sufficient for building on Windows and Linux).
So this script might not exactly fit to the current source structure.

@echo off
setlocal
set BASE=%SIKDEVELOP%
set ODIR=%BASE%\Script-Java\org\sikuli\script\natives
set ICV=c:\opencv\build\include
set IVISION=%BASE%\Resources\natives\Vision
set J1=%JDKHOME%\include
set J2=%JDKHOME%\include\win32
set LOCAL=c:\MinGW\msys\1.0\local
set SWIGEXE=c:\swigwin\swig.exe
echo on
%SWIGEXE% -java -package org.sikuli.script.natives -outdir "%ODIR%" -c++ "-I%J1%" "-I%J2%" "-I%ICV%" "-I%IVISION%" -I%LOCAL%\include -o "%IVISION%/visionJAVA_wrap.cxx" "%IVISION%/vision.swig"
endlocal

ODIR - where the generated java goes
IVISION - the native sources

- this is the actual productive script I use on Mac
#!/bin/sh
odir=$DEVSRC/VisionJava
icv=/usr/local/include/opencv
ivision=$DEVSRC/Vision
sysJava=/System/Library/Frameworks/JavaVM.framework/Headers

/usr/local/bin/swig -java -package org.sikuli.basics.proxies -outdir $odir -c++ -I$sysJava -I$icv/opencv -I$icv -I$ivision -I/usr/local/include -o $ivision/visionJAVA_wrap.cxx $ivision/vision.swig

BTW: I would prefer to discuss things like that directly on github.

Awesome, I tried this on my windows. It produced me all the java interfaces except openCV.java. I don't know the reason for it. Any ideas why this happened?

Also, regarding MinGW is it necessary to set it is an environment variable? I couldn't find the directory c:\MinGW\msys\1.0\local\include.

- openCV.java ...
... is not generated by SWIG as you can see in the head of the file. It is simply some Java code, that I decided to be here.

- MinGW
as far as I understood: You are using Visual Studio and hence MinGW does not have any meaning to you (I hope, you did not install it, since it is a hard job to have both on the same machine).
What is found in my environment in c:\MinGW\msys\1.0\local\include. should be in your environment somewhere else.
Since I did not run the Windows version of SWIG (if I ever did that), but the MinGW version (hence the Unix/Linux version), SWIG seemed to need some include file.
If this is not on your system and SWIG does not complain anything: just be happy.

Okay, cool.

after all this hard work too, even now I cannot link dll to java code. I don't know where I went wrong. still exploring on this.

anyways, my ultimate goal is to remove the integration of tesseract (for my custom project) with sikuli-ide as tesseract is not developed to identify text on screens. The normal DPI we have on our screens is 96 DPI. They recommend a minimum of 200 or 300 DPI. Tess is best for scanned documents as the DPI there is generally higher. I did a lot of research on this and found that screen font OCR is disturbed by a lot of factors such as ClearType and AntiAliasing etc... So, I decided not to use Vector Fonts on my system as MS uses some patented Font Rasterization technique to introduce the above funky effects. I'm using only raster (bitmap) fonts for all my applications now. So, I now do a pixel comparison (in other words template matching, where I have templates of each character stored in some folder) to identify the location of the character on the screen. This is my text finding idea.

so, for this if I knew the exact procedure to how to build sikuli-ide from scratch, I thought it'd be useful for me to integrate my code into the existing one. The fight still continues. ;)

Well, for the following error

[error] java.lang.UnsatisfiedLinkError ( java.lang.UnsatisfiedLinkError: org.sikuli.basics.proxies.

 which I posted as a different question you said

 "seems that your build procedure does not yet produce a useable VisionProxy at the moment.
VisionProxyJNI.new_FindInput__SWIG_0()J is an entry expected in VisionProxy.dll"

To know the all entries in VisionProxy.dll (which are in VisionProxyJNI.java) what can I do? Should I use a dependency walker? How can I bring them if something's missing? Should I debug it properly or something better answer is there ? :P

Please confirm the above assumptions of mine. This time I'll struggle more to finally resolve this.

ok, understood.

With the problems you have, I cannot help you further: I never did before, what you do and I only know in the moment, that my build processes produce valid libraries for Mac, Windows and Linux (Ubuntu).
And that is what I want. I have no idea about what is wrong with your build process.
When I had problems with missing dependencies, I successfully used a dependency walker.

In a few weeks I will start to step down to the native level, but in the moment I have other priorities - sorry.

In my VisionProxy.dll, I cannot find any entry points. If you have any idea about this, please reply or else I'll resolve by googling and come here to post solution here soon. Thanks for spending your valuable time. :)

Hi RaiMan,

Finally found out the reason for findFailed of my case. The reason is while making a SWIG call it fails to set the target. Target has correct path and correct type, but the target->data (and target->datastart and target->dataend) is null. That is why in find function in native level it does not produce proper result and find is failed. Since VisionJAVA_wrap.cxx is an auto-generated file, I didn't dare to make changes. You have any ideas where might this might be gone wrong ? Is it because of wrong vision.i ?

Btw, I attached running sikuli-ide.jar (java.exe) before it calls VisionProxy.dll to my Visual Studio and started debugging :)

for me the situation has not changed ;-)

... but I just setup a Windows 8 Pro64 and I am on the way to setup my development environment (NetBeans7.4, VS Express 2013 for Desktop) and I already successfully built WinUtil.dll :-)

So I guess, within the next 2 weeks I am on the road with this.
I will tell you if I have any idea in between.
My next steps: build 64-Bit versions of OpenCV and Tesseract (I will the be able to build the 32-Bit versions too)

--- but the target->data (and target->datastart and target->dataend) is null.
Where in the code can I see this?

As already mentioned, I would prefer to communicate directly per mail,to easily add attachments.
my mail: look at https://launchpad.net/~raimund-hocke

Just to recall,

In VisionJAVA_wrap.cxx there are following 4 functions (there are others too, but they don't bother us at the moment ;) ),

For source:
Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setSource_1_1SWIG_10
Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setSource_1_1SWIG_11

For target:
Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setTarget_1_1SWIG_10
Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setTarget_1_1SWIG_11

for source, Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setSource_1_1SWIG_11 gets called first and later Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setSource_1_1SWIG_10 gets called.

and for target, only Java_org_sikuli_basics_proxies_VisionProxyJNI_FindInput_1setTarget_1_1SWIG_10 gets called.

Does this mean target is not properly read ? Any ideas why this is happening ?

-- target->data (and target->datastart and target->dataend)

these are all not in the code. But, I can see their values using VisualStudio debugger. arg3 is a pointer in VisionJAVA_wrap.cxx and arg3->target->data is the image data, which contains the RGB values obtained by reading the image stored in form of ASCII characters.

To simplify,

In Vision.cpp, the following code section when called in find_image functions returns a target whose rows = 0, columns = 0, but I can see the target in the path with my eyes.

Mat
FindInput::getTargetMat(){
   return target;
}

Sorry for still replying. But I wanted to say that I solved the problem entirely and the mistake is that in vision.cpp in line-88, the case for target_type==TARGET_TYPE_MAT has not been handled and I fixed it by adding one line. I sent a pull request on github.

Kindly approve it. Thanks for your support all the way. You really rock :)

I can now start my hacking all the way.

Thanks RaiMan, that solved my question.