Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue 1351: OpenCL build - kernel_ThresholdRectToPix() not accounting for padding bits in the output pix?! #17

Merged
merged 1 commit into from
Aug 29, 2016

Conversation

… for padding bits in the output pix?!

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).
@zdenop
Copy link
Contributor

zdenop commented May 14, 2015

I tested this patch and IMO it is only partial solution (for some cases). Issue was escalated to original OpenCL contributor.

@markboettcher
Copy link

Just glanced at the code and wondered why on Earth multiplication and division is being done in every iteration, especially on inner, nested loops. Look at this:

PIXELS_PER_BURST*NUM_CHANNELS)/CHAR_VEC_WIDTH

This is inside a loop nested 3 deep. How many wasted clock cycles is this? Are we assuming that the compiler will optimize this out? If you're benchmarking with debug builds, your numbers are going to be way off, as in meaningless.

@zdenop zdenop merged commit 0497dc0 into master Aug 29, 2016
@zdenop
Copy link
Contributor

zdenop commented Aug 29, 2016

Merged, so we have at least partial fix...

@jimregan jimregan deleted the gcode_issue1351 branch October 17, 2016 17:43
zvezdochiot pushed a commit to ImageProcessing-ElectronicPublications/tesseract that referenced this pull request Mar 28, 2021
Issue 1351: OpenCL build - kernel_ThresholdRectToPix() not accounting for padding bits in the output pix?!
zvezdochiot pushed a commit to ImageProcessing-ElectronicPublications/tesseract that referenced this pull request Mar 28, 2021
Issue 1351: OpenCL build - kernel_ThresholdRectToPix() not accounting for padding bits in the output pix?!
zvezdochiot pushed a commit to ImageProcessing-ElectronicPublications/tesseract that referenced this pull request Mar 28, 2021
Issue 1351: OpenCL build - kernel_ThresholdRectToPix() not accounting for padding bits in the output pix?!
zvezdochiot pushed a commit to ImageProcessing-ElectronicPublications/tesseract that referenced this pull request Mar 28, 2021
Issue 1351: OpenCL build - kernel_ThresholdRectToPix() not accounting for padding bits in the output pix?!
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants