libtiff is no longer needed for OpenCL, so remove that dependency.
It is still suggested for Windows to redirect warning messages
from the tesseract executable to the console.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
With Debian package beignet-opencl-icd 1.2.1-1, Tesseract + OpenCL fails:
[DS] Profile file not available (tesseract_opencl_profile_devices.dat); performing profiling.
[DS] Device: "Intel(R) HD Graphics IvyBridge M GT2" (OpenCL) evaluation...
ASSERTION FAILED: sel.hasDoubleType()
at file /home/geier/beignet/backend/src/backend/gen_insn_selection.cpp, function void gbe::ConvertInstructionPattern::convertDoubleToSmallInts(gbe::Selection::Opaque&, const gbe::ir::ConvertInstruction&, bool&) const, line 5269
Trace/breakpoint trap
Using a pure float expression (instead of double) fixes this issue.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
CL_PROGRAM_NUM_DEVICES expects a cl_uint.
Passing size_t results in a wrong value for numDevices on hosts where
sizeof(cl_uint) != sizeof(size_t).
Signed-off-by: Stefan Weil <sw@weilnetz.de>
CL_CONTEXT_NUM_DEVICES expects a cl_uint.
Passing size_t results in a wrong value for numDevices on hosts where
sizeof(cl_uint) != sizeof(size_t). This results in errors like these:
Tesseract Open Source OCR Engine v3.05.00dev with Leptonica
OpenCL error code is -44 at when clCreateKernel kernel_HistogramRectAllChannels .
OpenCL error code is -44 at when clCreateKernel kernel_HistogramRectAllChannelsReduction .
OpenCL error code is -48 at when clSetKernelArg imageBuffer .
...
Signed-off-by: Stefan Weil <sw@weilnetz.de>
gcc report:
In file included from /usr/include/leptonica/alltypes.h:36:0,
from /usr/include/leptonica/allheaders.h:34,
from openclwrapper.h:2,
from openclwrapper.cpp:11:
openclwrapper.cpp: In static member function 'static PIX* OpenclDevice::pixReadMemTiffCl(const l_uint8*, size_t, l_int32)':
/usr/include/leptonica/environ.h:442:68: warning: format '%d' expects a matching 'int' argument [-Wformat=]
(void)fprintf(stderr, "Warning in %s: " a, __VA_ARGS__), \
^
/usr/include/leptonica/environ.h:427:61: note: in definition of macro 'IF_SEV'
((l) >= MINIMUM_SEVERITY && (l) >= LeptMsgSeverity ? (t) : (f))
^
opencl/openclwrapper.cpp:1162:3: note: in expansion of macro 'L_WARNING'
L_WARNING("tiff page %d not found", procName);
^
Signed-off-by: Stefan Weil <sw@weilnetz.de>
gcc report:
opencl_device_selection.h: In function 'ds_status getNumDeviceWithEmptyScore(ds_profile*, unsigned int*)':
opencl_device_selection.h:589:13: warning: value computed is not used [-Wunused-value]
*num++;
^
This is caused by a buggy implementation which increases the value of num
instead of *num.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
It is only used locally in opencl/openclwrapper.cpp.
For all other files which include openclwrapper.h, the compiler
complained about an unused static variable:
opencl/openclwrapper.h:175:16: warning:
‘MORPH_BC’ defined but not used [-Wunused-variable]
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Both arrays are only used in openclwrapper.cpp, so move them into that
file.
The first element of both arrays was unused. Remove it and fix the code
which reads the array elements accordingly. Sort this code, too.
These changes reduce the code size a little bit:
text data bss dec hex filename
2461743 6676 2742784 5211203 4f8443 1/api/tesseract (old)
2461599 6676 2742784 5211059 4f83b3 2/api/tesseract (new)
Signed-off-by: Stefan Weil <sw@weilnetz.de>
valgrind report: Mismatched free() / delete / delete []
gpuInfo->mpArryDevsID is created by "new cl_device_id[1]",
so it must be destroyed by delete[].
Signed-off-by: Stefan Weil <sw@weilnetz.de>
gcc report:
opencl/openclwrapper.cpp:3245:22: warning:
deprecated conversion from string constant to 'char*' [-Wwrite-strings]
Signed-off-by: Stefan Weil <sw@weilnetz.de>
gcc report:
opencl/openclwrapper.cpp:84:23: warning:
converting to non-pointer type 'char' from NULL [-Wconversion-null]
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Windows.h works on Windows, but not for cross builds on Linux hosts
with case sensitive file systems which only provide windows.h.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Also fixed a writable strings warning/error.
warning: ISO C++11 does not allow conversion from
string literal to 'char *' [-Wwritable-strings]
Several were of this form and fixed as the compiler suggested:
openclwrapper.cpp:2411:33: error: non-constant-expression cannot be narrowed
from type 'int' to 'size_t' (aka 'unsigned long') in initializer list
[-Wc++11-narrowing]
size_t local_work_size[] = {block_size};
^~~~~~~~~~
openclwrapper.cpp:2411:33: note: insert an explicit cast to silence this issue
size_t local_work_size[] = {block_size};
^~~~~~~~~~
static_cast<size_t>( )
Should have low impact on other platforms/compilers. The change makes
the code more correct.
https://code.google.com/p/tesseract-ocr/issues/detail?id=1351
What steps will reproduce the problem?
1.Use tesseract build with OpenCL.
2.Pass full color image with width which is not multiple of 32.
3.Recognition is way too slow and does not recognize anything.
I read the article on http://www.sk-spell.sk.cx/tesseract-meets-the-opencl-first-test and decided to give OCL a try. The initial result was as per point 3 above. After some debugging I figured the problem is that the OCL version of threshold rect generation does not account for padding bits in the output pix lines. To prove my discovery I made a quick fix in oclkernels.h replacing the definition of kernel_ThresholdRectToPix
Just a reminder: it is necessary to force OCL kernel recompilation after changing this source (e.g. delete “kernel - <device>.bin” from the exec folder).
The fix is working but I am not sure about it since the original source apparently works for other people (as per the article). If I am right the OS/GPU are irrelevant since the bug is algorithmic, but mine are Windows/AMD. Also similar fix is applicable to kernel_ThresholdRectToPix_OneChan(), but there the input array might have some padding bytes as well, so its indexing will need further adjustments. I can come with some prove/fix for it either - I have not played with it yet.
Disclaimer: I have no prior experience with image processing and tesseract source or with GPU computing and OpenCL (but please do explain if I am wrong).
