-
Notifications
You must be signed in to change notification settings - Fork 9.2k
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
Memory access violation when using SetRectangle for 8Bit images #4127
Comments
Please provide also an example image. |
I added two images to the initial post. The parameters for SetRectangle are 613, 2311, 86, 28 to extract the number. |
Where did you add images? |
I added them to the initial post as Test-Images.zip. Don't know why they vanished. Anyway, I attach the zip again to this post. |
Perhaps a small extentions to my inital post and the mentioned HistogramRect function. |
Seems like a bug in Tesseract implementation of OtsuThreshold and 8Bit images:
|
Seems like I got a similar issue. I am currently using version 5.3.0. This is the stack info I printed out:
|
Current Behavior
Hi
I got a memory access violation when using SetRectangle and an 8Bit image.
I only tested the simple example from the tesseract documentation (SetRectangle_example from https://tesseract-ocr.github.io/tessdoc/Examples_C++.html).
My image is a PNG file. When saving as 8Bit image I got the crash in debug mode. When I save the image in 32bit, then it works properly.
The VS debugger recognized the violation in the method HistogramRect in the file otsuthr.cpp in line 157: int pixel = GET_DATA_BYTE(linedata, (x + left) * num_channels + channel);
I tried to look if there is an error in the formula for calculating the address. But I am not familiar with the Tesseract internals (installed it last week for the first time), so I have no idea what the error causes.
But I think the mentioned method is a little weird. The input parameter src_pix is a pointer to the small rectangle image part, not to the overall (big) image (width and height have the size of the rectangle). Based on this it uses the WPL of the small rectangle image (src_wpl) and not of the whole original picture with much bigger resolution.
But when calculating the address of the pixels, the algorithm uses the pixel coordinates of the rectangle within the whole big picture (left, top, width, height), these are "global" pixel coodinates. So it seems, that the image is only a shallow structure pointing to the memory of the actual loaded image.
But if this is true: why does the line const l_uint32 *linedata = srcdata + y * src_wpl; use the WPL of the small rectangle and not of the actual whole image? If it is the memory of the loaded image, then it should be the stride based in the width of the image and not the width of the small rectangle.
On the other side: it seems to work properly with 32 bit images. So if the address calculation is wrong, then it should also cause problems with all other channel counts.
These are my thoughts. Hope it helps a little bit.
Best regards
Expected Behavior
No response
Suggested Fix
No response
tesseract -v
Tesseract 5.3.2
Operating System
Windows 10
Other Operating System
No response
uname -a
No response
Compiler
MSVC 2022 17.7.4, x64
CPU
No response
Virtualization / Containers
No response
Other Information
No response
The text was updated successfully, but these errors were encountered: