I appreciate getting confirmation that an issue exists. ZDenko's observation that SetRectangle is acting like it is treating the "top" argument as "bottom" is likely a clue and has to do with the image coordinate system. I looked at tesseract API doc and could not find where the internal coordinate system was discussed, but SetRectangle - as it was defined - suggests that internally, tesseract considers the top/left corner of the image to be the x=0,y=0 point in the image, with x=width, y=height being the lower right corner of the image. This is how the Apple Mac world originally defined its image coordinate system, but when they moved to OS X/Darwin, they adopted the coordinate system that says the x=0,y=0 point is the lower left corner of the image with x=width, y=height being the upper right corner. Because of these coordinate system differences, our Mac developers have to translate coordinates when making tesseract API calls that require them. If a new developer were to come into the tesseract team and contribute a SetRectangle code change, it would be easy to confuse the two coordinate systems and get it wrong. And yes, elsewhere we use cropped portions of a full image and have no problem with recognition, so we may decide not to use the damaged SetRectangle call at all. Thanks guys!
On Wednesday, August 2, 2023 at 2:37:08 PM UTC-4 tfmo...@gmail.com wrote: > On Tuesday, August 1, 2023 at 4:23:49 PM UTC-4 zdenop wrote: > > > IMO safer solution is to use the cropped image for SetImage. > > > That's a good workaround suggestion, but it clearly sounds like a bug (and > something not covered by the unit tests). > > Tom > -- You received this message because you are subscribed to the Google Groups "tesseract-ocr" group. To unsubscribe from this group and stop receiving emails from it, send an email to tesseract-ocr+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/tesseract-ocr/6e838b20-cf59-4ea0-9509-464df2c8c6fen%40googlegroups.com.
