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).
