Home › Forums › TWAIN Classic › From Java with user interface Twain › Re: no raw data?
I spent something around three days digging into the internals, ended up with part done sorting things to where they should be and stuff like:
javascannerukcommscomputingdeviceukcommscomputingnewsindex.html
due to the usual. There’s a stubb for the idea on google, someone has taken the position of Team Lead and has a discussion avenue stubbed with some code to work with, I sorta need to set aside the compression work as likely to drill-in to historical matters and get nothing done. ( me – maybe them too )
….javaEZTWAIN1VCEZTWAIN.C has a message loop already coded at line 198 so I can get in the message loop, thus achieving a way to retire the allocated resources on long loads when a shutdown hook in code might be the way someone else would do it.
At 958 in EZTWAIN.C the code
hDSMLib = LoadLibrary(szSMDir);
…. I guess what we do here is load the twain dll and call into that, but I do not see the point of the copy operation in there, ( that was some C/CPP code deeper in the exploration ) efforts to just get the datastream drilled in on what we know and loath:
“… ( some commercial entity ) …. is no longer in business, TIFF Class F remains in use and is considered by some to be an excellent storage format for facsimile data.”
( not the tiff stuff, the 🙄 no-longer-in-business-because-tried-to-do-something: USEFUL )
… is there some call that will get me TWAIN_RGB ? I do not see what the pallette is for, ( if I can get ) a simple translation that will get the datastream extracted by going through the pallette operation or whatever it wants to do arriving at what amouts to a pointer into the data, with a height x width value and a way to do grayscale[][] from the DIB would really help matters for me right this moment.
I spent last night stubbing a dll to receive the call from Java – there are issues there as Java code practice is that numbers are signed, always, nothing else is signed ….. getting direct bitops and byte ops on image data directly in Java is asking for it.
I did manage to run javah on my Java sources, contorted from the preliminary work of bahri.gencsoy
here’s what I have stubbed in the dll to recieve the call into native code:
/* Gabriel DeClieu (also referenced as Mathieu Gabriel De
* Clieu and Chevalier Gabriel Mathiew de Clieu) was a French
* naval officer whom is attributed to bringing coffee to the
* Americas in 1723. It is said that the Dutch unwittingly
* provided Louis XIV of France with a coffee bush that
* Gabriel DeClieu in turn made due with a seedling which he
* transported to Martinique whilst supposedly sacrificing his
* water ration to the seedling after a storm ravaged his
* vessel. Within 50 years of an official survey a recorded 19
* million coffee trees are said to have sprouted within that
* time. It is said that 90% of the world's coffee spread from
* this single plant.[source: wiki]
*/
__declspec(dllexport) long _callUncompressedCMYKload(void* data_pointer, long data_size)
{
;//int fntessjnidll(void)
}
//
__declspec(dllexport) long _callUncompressedCMYKstore(void* data_pointer,long data_size)
{
;//int fntessjnidll(void)
}
note placing active code behind comment marker for now
and there hung on the java does not do signed character stuff and how to call in,….. i was running low on brain-calories at that point, and had been for several hours.
I tried to write a C++ class for this, don’t think I really need that, probably Java will load a dll just as well …. still sorting things where they need to be – Issue 93: TessDLL wraper for java at google goes into several issues, I just wrote my own Java code and dug in for the effort:
// remove this line to get the file to compile.
private Khazad khazad = new Khazad();
// load dll I am prototyping:
static{Runtime.getRuntime().loadLibrary("****DLL");}
// the designer of testJeractApproach affirms under the
// reasonable person test that there are no intentions of basing
// the work on practices of the 16-bit bus.
public testJeractApproach(File fileName)
{
//
super();
//
dataBufferByte = new DataBufferByte(DataBufferByte.TYPE_INT,0x40000);
//
edgeDetector = new CannyEdgeDetector();
}
//
skipping the issue of L-2 writebacks and so on ( for now ) that the use of java.io.File raises, going for some sort of “read the scanner” as a delcared buffer and begin some sort of edge detection or other work, first just getting the thing to run so I could use it for my own work in my daily business, from Java, to do intake on warehousing reports.
The whole thing stalled on getting grayscale[][] as image_height / image_width – I do not have the skills to do imaging on a flat dataspace ( [] rather than [][] ) and at that point I had about five thought trains running in parallel, looking at function calls buried so deep in thousands of lines of code that I felt my grasp of where I was at evaporating like Coffee Aroma being breezed out an Open Window…..
gonna have to set down the work for a few days and take care of business.