rhardih's profile - activity

Do you perhaps know who else to ping?

Maybe @berak knows?

You should consider splitting your APK into architecture specific versions:

https://developer.android.com/google/...

That way you only need to include one version of OpenCV pr. APK, e.g. arm64-v8a.

That should give you the size reduction you're looking for.

In the case of the tickets with a QR code preset, it seems the numbers you are interested in are in a fixed position relative the the QR code. I would start by locating said QR code in the image, as that is probably the easiest task and then proceed to find the numbers relative to that.

Here's an example of how to find a QR code:

http://eric-yuan.me/simple-qr-code-scanner-1/

The next part is to then determine a set of coordinate ranges corresponding to the location of the numbers in your tickets. Using the list of contours you already found in locating the QR code, you should now be able to stepwise filter-out found contours that fall outside of these specified ranges.

Once you have found the location of each number, cut out a region of interest from each area and then send those onto whatever OCR engine you've decided to use. OpenCV comes with an api wrapper for Tesseract, if you've compiled in support for it.

Currently I have an OpenGL texture that I would like to map onto a cv::UMat for processing with OpenCV, but somehow I missed a vital piece of information in the documentation which says:

Currently OpenGL is supported only with WIN32, GTK and Qt backends on Windows and Linux (MacOS and Android are not supported)

I've not been able to find out exactly why OpenGL support is limited to only the above platforms, or if there's plans for adding support in the near future.

Has anyone else managed to work around this limitation and somehow found a way to map/populate a cv::UMat from an OpenGL texture on Android, despite the lack of direct support in cv::ogl?

Currently my solution is to copy back the texture data to host memory and then populate a normal Mat from there. This is painfully slow however and it would be much preferable if data could stay on device memory and just use the T-API.

You're probably missing a link to libtegra_hal.a. In my case OpenCV builds and installs to: platforms/build_android_arm/install, so the lib is located at platforms/build_android_arm/install/sdk/native/3rdparty/libs/armeabi-v7a/libtegra_hal.a.

Adding -L"<opencv-dir>/platforms/build_android_arm/install/sdk/native/3rdparty/libs" -ltegra_hal, should do it.

I don't know anything about the size of the characters unfortunately. They will be in all kinds of sizes and font types.

I'm trying to build a simple price-tag scanner and I've gotten reasonably far with regards to binarisation and general de-noising.

However, feeding an image like this to Tesseract doesn't yield very good results. Tesseract seems very sensitive to the amount of artifacts present in the picture, aside from what is to be recognised, as well as even slight skews on the text. Here's an example, where a ROI around a price has been selected and binarised:

Asking Tesseract to OCR this image, is rather useless: flflflflfl.

However, if I could manage to somehow consistently deskew and crop to just the numbers, it's a whole different thing:

Now Tesseract provides a clean result: $33.25

In this case, because of the straight black line at the top, I could use a Hough transform and calculate the angle, in order to deskew the image, but there won't always be straight lines to use, so that won't work in general.

I could also use an ER filter to get just the text region, but then I'd get a rectangle without rotation and I'd still need to figure out how to crop/deskew again regardless.

So my question is, if there's some clever way to extract a relatively tight bounding box, a'la minAreaRect(), around just the number, in order to make presentable cutout to feed to Tesseract?

I've had luck using Docker to build OpenCV consistently across systems. It's a better way to guarantee you get the same tool-chain on every build.

Are you sure you've specified the flag correctly? I used these exact flags, and it worked just fine:

-D CMAKE_C_COMPILER=/usr/bin/arm-linux-gnueabihf-gcc -D CMAKE_CXX_COMPILER=/usr/bin/arm-linux-gnueabihf-g++ -DCMAKE_AR=/usr/bin/arm-linux-gnueabihf-ar

It shouldn't be necessary to edit the generated cmake files by hand.

@humam-helfawi Remember to mark the answer as correct.

Do you have an example I can follow of how best to do it? I'd rather not clutter search results with needless duplications.

True enough, but also if the system doesn't have it installed, which is the case for a default Ubuntu for instance. I just tried it out on a stock docker container of ubuntu:16.04 and it seems all the 3rdparty libs are compiled without having to explicitly add any of the -DBUILD_<LIBNAME> flags.

I ran into this very same problem and from what I could gather, it seems CMake doesn't correctly detect binaries for cross-compilation, even though it's indicated in the wiki, that just setting the compiler via the CC env variable, should be enough to detect the rest properly:

https://cmake.org/Wiki/CMake_Cross_Co...

In my case I've installed gcc-arm-linux-gnueabihf and g++-arm-linux-gnueabihf, which has the corresponding binutils as dependencies, so you get the correct linker etc.

However, just running the gnueabihf script in /opencv/platforms/scripts/cmake_arm_gnueabi_hardfp.sh, specifying the correct C and CXX compilers was not enough, since CMake didn't find the gnueabihf version of ar to use:

# ./cmake_arm_gnueabi_hardfp.sh -D CMAKE_C_COMPILER=/usr/bin/arm-linux gnueabihf-gcc -D CMAKE_CXX_COMPILER=/usr/bin/arm-linux-gnueabihf-g++

# cat ../build_linux_arm_hardfp/CMakeVars.txt | grep CMAKE_AR
CMAKE_AR=CMAKE_AR-NOTFOUND
CMAKE_AR=CMAKE_AR-NOTFOUND
CMAKE_CXX_ARCHIVE_APPEND=<CMAKE_AR> q  <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_CXX_ARCHIVE_CREATE=<CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_APPEND=<CMAKE_AR> q  <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_CREATE=<CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_AR=CMAKE_AR-NOTFOUND
CMAKE_AR=CMAKE_AR-NOTFOUND
CMAKE_CXX_ARCHIVE_APPEND=<CMAKE_AR> q  <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_CXX_ARCHIVE_CREATE=<CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_APPEND=<CMAKE_AR> q  <TARGET> <LINK_FLAGS> <OBJECTS>
CMAKE_C_ARCHIVE_CREATE=<CMAKE_AR> qc <TARGET> <LINK_FLAGS> <OBJECTS>

Which results in the following linker command for zlib:

# cat 3rdparty/zlib/CMakeFiles/zlib.dir/link.txt
CMAKE_AR-NOTFOUND qc ../lib/libzlib.a  CMakeFiles/zlib.dir/adler32.c.o CMakeFiles/zlib.dir/compress.c.o CMakeFiles/zlib.dir/crc32.c.o CMakeFiles/zlib.dir/deflate.c.o CMakeFiles/zlib.dir/gzclose.c.o CMakeFiles/zlib.dir/gzlib.c.o CMakeFiles/zlib.dir/gzread.c.o CMakeFiles/zlib.dir/gzwrite.c.o CMakeFiles/zlib.dir/inflate.c.o CMakeFiles/zlib.dir/infback.c.o CMakeFiles/zlib.dir/inftrees.c.o CMakeFiles/zlib.dir/inffast.c.o CMakeFiles/zlib.dir/trees.c.o CMakeFiles/zlib.dir/uncompr.c.o CMakeFiles/zlib.dir/zutil.c.o

So in order to fix it, set the path to ar explicitly, as with the compiler versions:

# ./cmake_arm_gnueabi_hardfp.sh -D CMAKE_C_COMPILER=/usr/bin/arm-linux-gnueabihf-gcc -D CMAKE_CXX_COMPILER=/usr/bin/arm-linux-gnueabihf-g++ -DCMAKE_AR=/usr/bin/arm-linux-gnueabihf-ar

@StevenPuttemans

OpenCV includes source for zlib 1.2.8, https://github.com/opencv/opencv/tree..., so it shouldn't be necessary to use the system provided dev packages.