Seems to be error in sources ?
464 views
Skip to first unread message
Matt
Nov 27, 2016, 9:11:40 AM11/27/16
to OpenALPR
I don't understand. What line(s) did you change? I wouldn't expect an error like that unless there was something special about your system since that field is part of stat (defined in sys/stat.h).
yur...@gmail.com
Nov 27, 2016, 12:10:02 PM11/27/16
to OpenALPR
This is screenshot of ..support/filesystem cpp, line 191.
I'm bulding for Android and the definition of "struct stat" differs from classic one:
you can see this in
.../ndk-bundle/platforms/android-<version>/arch-<architecture>/usr/include/linux/stat.h files
my version is 17.
Sincerely.
I'm bulding for Android and the definition of "struct stat" differs from classic one:
you can see this in
.../ndk-bundle/platforms/android-<version>/arch-<architecture>/usr/include/linux/stat.h files
my version is 17.
Sincerely.
Matt
Nov 30, 2016, 7:25:41 AM11/30/16
to OpenALPR
Ahh, that makes sense. Yes, I think we could handle this just like other OS (e.g., Mac OS X) is handled. Add a precompiler directive for Android and use a different function.
yur...@gmail.com
Nov 30, 2016, 10:25:40 AM11/30/16
to OpenALPR
Very slowly I'm moving to win OALPR in windows&ubuntu by Android studio! Just today I receieved the recognition results in java-android code from arm-v7-based tablet. But from begining I named my project as com.<bla-bla>, so all jni objects are named as com.openalpr.<>.. :-(
Now renaming them. The first advanage of this building is the possibility just to copy structure of standard OALPR runtime-dir and openalpr.conf whthout any modifications. And the hope, that postprocessing will be workable.;-)
Sincelery Your
Now renaming them. The first advanage of this building is the possibility just to copy structure of standard OALPR runtime-dir and openalpr.conf whthout any modifications. And the hope, that postprocessing will be workable.;-)
Sincelery Your
yur...@gmail.com
Nov 30, 2016, 12:03:24 PM11/30/16
to OpenALPR
eu ?@####@@?
eu @@####@@
eu @####@@
{"version":2,"data_type":"alpr_results","epoch_time":1480524680627,"img_width":480,"img_height":360,"processing_time_ms":1636.444092,"regions_of_interest":[],"results":[{"plate":"HB5591AB","confidence":88.805443,"matches_template":1,"plate_index":0,"region":"","region_confidence":0,"processing_time_ms":481.292725,"requested_topn":2,"coordinates":[{"x":103,"y":139},{"x":438,"y":132},{"x":441,"y":214},{"x":106,"y":222}],"candidates":[{"plate":"HB5591AB","confidence":88.805443,"matches_template":1},{"plate":"GB5591AB","confidence":87.061150,"matches_template":1}]}]}
Detected by Openalpr 2.3.0,on Android API21 +openCV 2.4
And templates matches too! :-)
Walking to drink beer & write sample with this libraries.
P.S. I'm remember my promises about Kyrgis plates & workfow of building openalpr with Android studio 2.2.0.
yur...@gmail.com
Dec 1, 2016, 6:48:07 AM12/1/16
to OpenALPR
As promised:
https://cloud.mail.ru/public/48FC/4fkofPjhy
Zipped sample project for androidStudio 2.2.0.
Using new Openalpr, 2.3.0 by Matt enumeration :-)
Platform is ARM-7a now, But I m working on x86.
Using OpenCV 2.4 and required OpenCVManager to be installed.
New features:
Can use Openalpr config structure without any tuning.
With sligtly tuning can use individual openalpr.conf for each (or selected) languages.
Multithreaded. Parallel processing of each country/region combination on each core.
(can be tuned to parallel processing of several images).
Modified from existed GiHub sources.
https://cloud.mail.ru/public/48FC/4fkofPjhy
Zipped sample project for androidStudio 2.2.0.
Using new Openalpr, 2.3.0 by Matt enumeration :-)
Platform is ARM-7a now, But I m working on x86.
Using OpenCV 2.4 and required OpenCVManager to be installed.
New features:
Can use Openalpr config structure without any tuning.
With sligtly tuning can use individual openalpr.conf for each (or selected) languages.
Multithreaded. Parallel processing of each country/region combination on each core.
(can be tuned to parallel processing of several images).
Modified from existed GiHub sources.
yur...@gmail.com
Dec 1, 2016, 2:36:58 PM12/1/16
to OpenALPR
Additions-
The pack with Arm-v7a&x86 libs for sample project.
The screenshot of EMULATED (AVD) x86-based NEXUS_5X:
The recognition time is low enough. Who can test this on real tablet?
The pack with Arm-v7a&x86 libs for sample project.
The screenshot of EMULATED (AVD) x86-based NEXUS_5X:
The recognition time is low enough. Who can test this on real tablet?
yur...@gmail.com
Dec 1, 2016, 3:36:06 PM12/1/16
to OpenALPR
Matt
Dec 6, 2016, 2:48:58 PM12/6/16
to OpenALPR
Very cool! How fast is the recognition time on your tablet, I wonder? I've been worried that Android would be too slow. There are some tablets that support OpenCL, but not many. Some of the new Octa-core tablets may be pretty fast just on CPU though (if we recognized each image on all 8 cores).
Any interest in hosting this on GitHub? It would make it easier to access and for more folks to collaborate.
-Matt
Any interest in hosting this on GitHub? It would make it easier to access and for more folks to collaborate.
-Matt
Faisal Shehada
Dec 6, 2016, 4:47:33 PM12/6/16
to OpenALPR
Hello all
please can any one help :(, i need a sample project for car plate recognition :(
yur...@gmail.com
Dec 7, 2016, 4:39:01 AM12/7/16
to OpenALPR
1. For Matt; I't s a great honour for me to be "git-hubbed" coder! :-) But this project is Your child, so my code- is only the toy for him! ;-)
About the speed: I'm tested armv7 platform on this device:
http://e-tesla.pro/tesla-effect-10.1-3g
(Tesla Effect 10.1-3G, but the link is in russian lang :-( ) The summary time on 2 threads (Time on trhread1+Time on thread2, this is the number on indicaton bar of sample program) was about 1.2...1.5 seconds. Some old api-19 based asus tablet (i'ts not my) gives 5...5.2 seconds, but it is about 3 years old. I have no enthusiasts around to make other dangerous experiments with possible explosion-) Hey, aree someone here;-)?
Yesterday I try to subj for MIPS and ARM (non 7) Mips was builded fine, ARM <7 failed on some .s files, because them don,t have some datatypes, existed in ARM-V7. So, old ARMs were marked as "died" and deprecated forever.
The other work I'm planning is to try OpenCv 3: the highest version proimises highes possibilites, is it true? ;-)
2.For Faisial Shedata:
What kind of project do You want? The ALPR "client" application sample is linked above. The other one can be find in ALPR
documentation. The project to bulild LIB******.SO zipped from UBUNTU will be in my next message, It can be easyly transfer
on Windows py changing pathes in CMakelines.txt files .
About the speed: I'm tested armv7 platform on this device:
http://e-tesla.pro/tesla-effect-10.1-3g
(Tesla Effect 10.1-3G, but the link is in russian lang :-( ) The summary time on 2 threads (Time on trhread1+Time on thread2, this is the number on indicaton bar of sample program) was about 1.2...1.5 seconds. Some old api-19 based asus tablet (i'ts not my) gives 5...5.2 seconds, but it is about 3 years old. I have no enthusiasts around to make other dangerous experiments with possible explosion-) Hey, aree someone here;-)?
Yesterday I try to subj for MIPS and ARM (non 7) Mips was builded fine, ARM <7 failed on some .s files, because them don,t have some datatypes, existed in ARM-V7. So, old ARMs were marked as "died" and deprecated forever.
The other work I'm planning is to try OpenCv 3: the highest version proimises highes possibilites, is it true? ;-)
2.For Faisial Shedata:
What kind of project do You want? The ALPR "client" application sample is linked above. The other one can be find in ALPR
documentation. The project to bulild LIB******.SO zipped from UBUNTU will be in my next message, It can be easyly transfer
on Windows py changing pathes in CMakelines.txt files .
yur...@gmail.com
Dec 7, 2016, 5:34:58 AM12/7/16
to OpenALPR
Making OpenAlpr For Android with AndroidStodio 2.2.0
1. Carefully reading here: http://stackoverflow.com/questions/21309592/compile-openalpr-for-android-with-ndk
2.Don' afraid, the only thing you will do- bulding tesseract, But commited tecceract can be easyly import in A-Studio in build/make there!
3. Dowhload files from my link:
https://cloud.mail.ru/public/4tKN/2ksPoVvew
4.I used /opt as base for all path. To avoid security problems, all work was done in Virtual host based on OracleVM wirtual box and installed UBUNTU 16.10 x64. So the first thing I do- chown -hR urry:root /opt "urry" is my username and you must change it in all path strings in CMakeLists.txt!
5.OpenCV_Android_SDK can be commited directly to /opt, I download and install anroid-NDK separately from android developers site an placed it into /opt, but you can try to use studio-supplied one by changing path in CMakeLists files.
6. In my archive you can see the struct of my home-dir. "tess-two" commited and builded tesseract, openalpr-master is commited Matt's catalogue.
7.Try to Open Android project with studio. You must see in project->android view app and openalpr nodes.
To buld them you had to do:
-Clear project
-sync with gradle files
-refresh C++ project
-make your project
!!IMPORTANT !! The project is for mips now!
To Change for other platform 1 in CMakeLists.TXT Change all ../mips/.. pathes to you targers: ../armeabi-v7a/... and so on.
in build.gradle for app and alprlibrary change abiFilter to you targets too.
In a fiew seconds you will have libopenalpr.so and libopenalprjni.so somewhere in "intermediates" folder. Find and use them!
1. Carefully reading here: http://stackoverflow.com/questions/21309592/compile-openalpr-for-android-with-ndk
2.Don' afraid, the only thing you will do- bulding tesseract, But commited tecceract can be easyly import in A-Studio in build/make there!
3. Dowhload files from my link:
https://cloud.mail.ru/public/4tKN/2ksPoVvew
4.I used /opt as base for all path. To avoid security problems, all work was done in Virtual host based on OracleVM wirtual box and installed UBUNTU 16.10 x64. So the first thing I do- chown -hR urry:root /opt "urry" is my username and you must change it in all path strings in CMakeLists.txt!
5.OpenCV_Android_SDK can be commited directly to /opt, I download and install anroid-NDK separately from android developers site an placed it into /opt, but you can try to use studio-supplied one by changing path in CMakeLists files.
6. In my archive you can see the struct of my home-dir. "tess-two" commited and builded tesseract, openalpr-master is commited Matt's catalogue.
7.Try to Open Android project with studio. You must see in project->android view app and openalpr nodes.
To buld them you had to do:
-Clear project
-sync with gradle files
-refresh C++ project
-make your project
!!IMPORTANT !! The project is for mips now!
To Change for other platform 1 in CMakeLists.TXT Change all ../mips/.. pathes to you targers: ../armeabi-v7a/... and so on.
in build.gradle for app and alprlibrary change abiFilter to you targets too.
In a fiew seconds you will have libopenalpr.so and libopenalprjni.so somewhere in "intermediates" folder. Find and use them!
yur...@gmail.com
Dec 18, 2016, 6:19:39 AM12/18/16
to OpenALPR
Here
https://cloud.mail.ru/public/LZAk/gA66YxJNh
is huge zip with tecceract inside oriented to be used in Android Studio 2.2.2.
It's rejected to be used only for armeabi-v7a, but can be easily expanded for other platforms.
Dummy app is sample of usage.
Now it is Opencv3.1 based (just replace opencv sdk for android fron v.2.4.xx to 3.1.xx on disk & rebuild libraries again, I decribe this procedure)
The advatage of migrating semms to be very small: time of recognition decreases on about 10%.
P.S. After alpr libraries were generated by making openalpr module , copy them to ../jni/armeabi-v7a or other arvhitrecture-named folder to be used in DummyApp.apk manualy.
https://cloud.mail.ru/public/LZAk/gA66YxJNh
is huge zip with tecceract inside oriented to be used in Android Studio 2.2.2.
It's rejected to be used only for armeabi-v7a, but can be easily expanded for other platforms.
Dummy app is sample of usage.
Now it is Opencv3.1 based (just replace opencv sdk for android fron v.2.4.xx to 3.1.xx on disk & rebuild libraries again, I decribe this procedure)
The advatage of migrating semms to be very small: time of recognition decreases on about 10%.
P.S. After alpr libraries were generated by making openalpr module , copy them to ../jni/armeabi-v7a or other arvhitrecture-named folder to be used in DummyApp.apk manualy.
Matt
Dec 20, 2016, 9:38:24 AM12/20/16
to OpenALPR
Thanks, Yury. This looks excellent.
yur...@gmail.com
Dec 23, 2016, 12:40:22 PM12/23/16
to OpenALPR
Not all is uncloudly!
I was trying to write some "pseudo-realtime" recognition on android.
The idea was to create several threads(number_of_processor_cores - 2, as supposed) and then to give for each some captured frame from camera's preview stream, While they are working, just look on preview sources and check the final of processing in some thread. When this occured, give to the free thread new task with new frame and so on.
All was written and works fine.... in one minute!! Then application was closed without any stacktrace. And the strange thing: (number of threads * interval of working) seems to be constant!
Looks like a bomb whaiting fot total number of pushes. :-( When emulating "nativerecognize" call with sleep(300)- no problems, the code works infinetly. I tried to modify my code- now I terminate thread after each recognition, then recreate it- the result ith the same. Ohh, fogot to write! The "Camera" class was useed in this series of attempts.
Then I tried to do the same with "Camera2" class. It is very strange,but the time to crash was the same as with "Camera".
Using "Android monitor"(no logs were generated!) I saw, this info:
..........................................................................
12-23 20:17:09.412 182-387/? I/cmr_grab: L 485, cmr_grab_buff_cfg: 2 1 0x4000
12-23 20:17:09.412 182-387/? D/cmr_grab: L 506, cmr_grab_buff_cfg: buf 0: Y 0x20bfe000
12-23 20:17:09.412 182-387/? D/cmr_preview: L 7103, prev_set_zsl_buffer: out cnt 4 width 720 height 480 addr_y 0x20bfe000, addr_u 0x20c52600
12-23 20:17:09.412 182-405/? I/cmr_preview: L 1378, cmr_preview_set_zsl_buffer: out
12-23 20:17:09.412 182-405/? I/SprdOEMCamera: L 734, camera_set_zsl_buffer: done 0
12-23 20:17:09.412 182-405/? D/SprdCamera3EOMIf: L 4799, PushZslbuff: X
12-23 20:17:09.412 182-405/? D/SprdCamera3HAL_Mem: L 261, map: IOMMU MAP iova mem_info->fd = 61, mem_info->addr_phy = 0x20c7e000, mem_info->size = 0x80000
12-23 20:17:09.412 182-405/? D/SprdCamera3Stream: L 130, buffDoneQ: Fnumber 1487, handle 0xb587ae44, SType 1
12-23 20:17:09.412 182-405/? D/SprdCamera3EOMIf: L 4727, PushPreviewbuff: addr_phy = 0x20c7e000, addr_vir = 0xa9b34000, ret = 0
12-23 20:17:09.412 182-387/? I/cmr_grab: L 485, cmr_grab_buff_cfg: 1 1 0x1000
12-23 20:17:09.412 182-387/? D/cmr_grab: L 506, cmr_grab_buff_cfg: buf 0: Y 0x20c7e000
12-23 20:17:09.412 182-387/? D/cmr_preview: L 6821, prev_set_preview_buffer: done cnt 4 addr_y 0x20c7e000
12-23 20:17:09.422 1287-1287/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-23 20:17:09.422 1287-1287/? I/DEBUG: Native Crash TIME: 8708633
12-23 20:17:09.422 1287-1287/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-23 20:17:09.422 1287-1287/? I/DEBUG: Build fingerprint: 'SPRD/s106a/scx35_sp7731gea_hd:5.1/LMY47D/lh22403121723:user/release-keys'
12-23 20:17:09.422 1287-1287/? I/DEBUG: Revision: '0'
12-23 20:17:09.422 1287-1287/? I/DEBUG: ABI: 'arm'
12-23 20:17:09.422 1287-1287/? I/DEBUG: pid: 32744, tid: 453, name: Thread-519 >>> ru.privatetest.realcamapp <<<
12-23 20:17:09.422 1287-1287/? I/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
12-23 20:17:09.442 1287-1287/? I/DEBUG: r0 00000000 r1 000001c5 r2 00000006 r3 00000000
12-23 20:17:09.442 1287-1287/? I/DEBUG: r4 a27ffdb8 r5 00000006 r6 00000000 r7 0000010c
12-23 20:17:09.442 1287-1287/? I/DEBUG: r8 00000002 r9 a2ca4a70 sl b4b8a870 fp 0000000a
12-23 20:17:09.452 1287-1287/? I/DEBUG: ip 000001c5 sp a27fd238 lr b6e2f715 pc b6e526f0 cpsr 600d0010
12-23 20:17:09.452 1287-1287/? I/DEBUG: backtrace:
12-23 20:17:09.452 1287-1287/? I/DEBUG: #00 pc 0003a6f0 /system/lib/libc.so (tgkill+12)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #01 pc 00017711 /system/lib/libc.so (pthread_kill+52)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #02 pc 00018327 /system/lib/libc.so (raise+10)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #03 pc 00014bd1 /system/lib/libc.so (__libc_android_abort+36)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #04 pc 00012f58 /system/lib/libc.so (abort+4)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #05 pc 000e12f7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (ERRCODE::error(char const*, TessErrorLogCode, char const*, ...) const+170)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #06 pc 001623db /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::Textord::TextordPage(tesseract::PageSegMode, FCOORD const&, int, int, Pix*, Pix*, Pix*, bool, BLOBNBOX_LIST*, BLOCK_LIST*, TO_BLOCK_LIST*)+254)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #07 pc 000a81e7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::Tesseract::SegmentPage(STRING const*, BLOCK_LIST*, tesseract::Tesseract*, OSResults*)+730)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #08 pc 00088f89 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::TessBaseAPI::FindLines()+524)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #09 pc 000890e9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::TessBaseAPI::Recognize(ETEXT_DESC*)+32)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #10 pc 000f13f9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::TesseractOcr::recognize_line(int, alpr::PipelineData*)+564)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #11 pc 000f2607 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::OCR::performOCR(alpr::PipelineData*)+134)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #12 pc 000c3a89 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::analyzeSingleCountry(cv::Mat, cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1596)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #13 pc 000c24a5 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognizeFullDetails(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1148)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #14 pc 000c6069 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+68)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #15 pc 000c57e3 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat)+114)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #16 pc 000c54d9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(std::vector<char, std::allocator<char> >)+112)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #17 pc 000bea0b /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Alpr::recognize(std::vector<char, std::allocator<char> >)+58)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #18 pc 0000bd1f /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalprjni.so (Java_com_openalpr_Alpr23_native_1recognize___3B+158)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #19 pc 00001cd3 /data/data/ru.privatetest.realcamapp/cache/slice-slice_4-classes.dex
12-23 20:17:09.512 182-385/? I/cmr_oem: L 567, camera_grab_evt_cb: evt 0x10000, handle 0xb596a000
12-23 20:17:09.512 182-385/? I/cmr_oem: L 275, camera_get_snp_req: 0
12-23 20:17:09.512 182-385/? I/cmr_grab: L 790, cmr_grab_path_capability: video prev 0 scale 0 capture_no_trim 0 capture_pause 1
.........................
Can You explain what to do?
I'm have small experience in C++ and "below zero" in tesseract :-(
P.S. OpenCv2.4 causes the same behavior as 3.1.
The armeabi-v7a targeted project
This is the link for Android studio 2.2.3 project, Armeabi-v7a jni-libs are in it, other can be found in my previous post.
4 and more cores in CPU supposed.
I was trying to write some "pseudo-realtime" recognition on android.
The idea was to create several threads(number_of_processor_cores - 2, as supposed) and then to give for each some captured frame from camera's preview stream, While they are working, just look on preview sources and check the final of processing in some thread. When this occured, give to the free thread new task with new frame and so on.
All was written and works fine.... in one minute!! Then application was closed without any stacktrace. And the strange thing: (number of threads * interval of working) seems to be constant!
Looks like a bomb whaiting fot total number of pushes. :-( When emulating "nativerecognize" call with sleep(300)- no problems, the code works infinetly. I tried to modify my code- now I terminate thread after each recognition, then recreate it- the result ith the same. Ohh, fogot to write! The "Camera" class was useed in this series of attempts.
Then I tried to do the same with "Camera2" class. It is very strange,but the time to crash was the same as with "Camera".
Using "Android monitor"(no logs were generated!) I saw, this info:
..........................................................................
12-23 20:17:09.412 182-387/? I/cmr_grab: L 485, cmr_grab_buff_cfg: 2 1 0x4000
12-23 20:17:09.412 182-387/? D/cmr_grab: L 506, cmr_grab_buff_cfg: buf 0: Y 0x20bfe000
12-23 20:17:09.412 182-387/? D/cmr_preview: L 7103, prev_set_zsl_buffer: out cnt 4 width 720 height 480 addr_y 0x20bfe000, addr_u 0x20c52600
12-23 20:17:09.412 182-405/? I/cmr_preview: L 1378, cmr_preview_set_zsl_buffer: out
12-23 20:17:09.412 182-405/? I/SprdOEMCamera: L 734, camera_set_zsl_buffer: done 0
12-23 20:17:09.412 182-405/? D/SprdCamera3EOMIf: L 4799, PushZslbuff: X
12-23 20:17:09.412 182-405/? D/SprdCamera3HAL_Mem: L 261, map: IOMMU MAP iova mem_info->fd = 61, mem_info->addr_phy = 0x20c7e000, mem_info->size = 0x80000
12-23 20:17:09.412 182-405/? D/SprdCamera3Stream: L 130, buffDoneQ: Fnumber 1487, handle 0xb587ae44, SType 1
12-23 20:17:09.412 182-405/? D/SprdCamera3EOMIf: L 4727, PushPreviewbuff: addr_phy = 0x20c7e000, addr_vir = 0xa9b34000, ret = 0
12-23 20:17:09.412 182-387/? I/cmr_grab: L 485, cmr_grab_buff_cfg: 1 1 0x1000
12-23 20:17:09.412 182-387/? D/cmr_grab: L 506, cmr_grab_buff_cfg: buf 0: Y 0x20c7e000
12-23 20:17:09.412 182-387/? D/cmr_preview: L 6821, prev_set_preview_buffer: done cnt 4 addr_y 0x20c7e000
12-23 20:17:09.422 1287-1287/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-23 20:17:09.422 1287-1287/? I/DEBUG: Native Crash TIME: 8708633
12-23 20:17:09.422 1287-1287/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
12-23 20:17:09.422 1287-1287/? I/DEBUG: Build fingerprint: 'SPRD/s106a/scx35_sp7731gea_hd:5.1/LMY47D/lh22403121723:user/release-keys'
12-23 20:17:09.422 1287-1287/? I/DEBUG: Revision: '0'
12-23 20:17:09.422 1287-1287/? I/DEBUG: ABI: 'arm'
12-23 20:17:09.422 1287-1287/? I/DEBUG: pid: 32744, tid: 453, name: Thread-519 >>> ru.privatetest.realcamapp <<<
12-23 20:17:09.422 1287-1287/? I/DEBUG: signal 6 (SIGABRT), code -6 (SI_TKILL), fault addr --------
12-23 20:17:09.442 1287-1287/? I/DEBUG: r0 00000000 r1 000001c5 r2 00000006 r3 00000000
12-23 20:17:09.442 1287-1287/? I/DEBUG: r4 a27ffdb8 r5 00000006 r6 00000000 r7 0000010c
12-23 20:17:09.442 1287-1287/? I/DEBUG: r8 00000002 r9 a2ca4a70 sl b4b8a870 fp 0000000a
12-23 20:17:09.452 1287-1287/? I/DEBUG: ip 000001c5 sp a27fd238 lr b6e2f715 pc b6e526f0 cpsr 600d0010
12-23 20:17:09.452 1287-1287/? I/DEBUG: backtrace:
12-23 20:17:09.452 1287-1287/? I/DEBUG: #00 pc 0003a6f0 /system/lib/libc.so (tgkill+12)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #01 pc 00017711 /system/lib/libc.so (pthread_kill+52)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #02 pc 00018327 /system/lib/libc.so (raise+10)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #03 pc 00014bd1 /system/lib/libc.so (__libc_android_abort+36)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #04 pc 00012f58 /system/lib/libc.so (abort+4)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #05 pc 000e12f7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (ERRCODE::error(char const*, TessErrorLogCode, char const*, ...) const+170)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #06 pc 001623db /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::Textord::TextordPage(tesseract::PageSegMode, FCOORD const&, int, int, Pix*, Pix*, Pix*, bool, BLOBNBOX_LIST*, BLOCK_LIST*, TO_BLOCK_LIST*)+254)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #07 pc 000a81e7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::Tesseract::SegmentPage(STRING const*, BLOCK_LIST*, tesseract::Tesseract*, OSResults*)+730)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #08 pc 00088f89 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::TessBaseAPI::FindLines()+524)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #09 pc 000890e9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libtess.so (tesseract::TessBaseAPI::Recognize(ETEXT_DESC*)+32)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #10 pc 000f13f9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::TesseractOcr::recognize_line(int, alpr::PipelineData*)+564)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #11 pc 000f2607 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::OCR::performOCR(alpr::PipelineData*)+134)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #12 pc 000c3a89 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::analyzeSingleCountry(cv::Mat, cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1596)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #13 pc 000c24a5 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognizeFullDetails(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1148)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #14 pc 000c6069 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+68)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #15 pc 000c57e3 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat)+114)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #16 pc 000c54d9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(std::vector<char, std::allocator<char> >)+112)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #17 pc 000bea0b /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Alpr::recognize(std::vector<char, std::allocator<char> >)+58)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #18 pc 0000bd1f /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalprjni.so (Java_com_openalpr_Alpr23_native_1recognize___3B+158)
12-23 20:17:09.452 1287-1287/? I/DEBUG: #19 pc 00001cd3 /data/data/ru.privatetest.realcamapp/cache/slice-slice_4-classes.dex
12-23 20:17:09.512 182-385/? I/cmr_oem: L 567, camera_grab_evt_cb: evt 0x10000, handle 0xb596a000
12-23 20:17:09.512 182-385/? I/cmr_oem: L 275, camera_get_snp_req: 0
12-23 20:17:09.512 182-385/? I/cmr_grab: L 790, cmr_grab_path_capability: video prev 0 scale 0 capture_no_trim 0 capture_pause 1
.........................
Can You explain what to do?
I'm have small experience in C++ and "below zero" in tesseract :-(
P.S. OpenCv2.4 causes the same behavior as 3.1.
The armeabi-v7a targeted project
This is the link for Android studio 2.2.3 project, Armeabi-v7a jni-libs are in it, other can be found in my previous post.
4 and more cores in CPU supposed.
Message has been deleted
yur...@gmail.com
Dec 24, 2016, 3:31:20 AM12/24/16
to OpenALPR
Hmmm. prevous post was removed.
New project for Pseudo-realtime recognition on android
What was done:
EACH creation of ANY object in onPrewiewFrame() were "closed" by direct assignment of null. <object>=null
And System.gc() call at the end of each ALPR-processing loops.
VERY,VERY STRANGE SOLUTION!! :-( It seems to be some bug or feature in android's garbage?!
Only my 30ty years experience in programming helps not to trust for any operation system! ;-))
New project for Pseudo-realtime recognition on android
What was done:
EACH creation of ANY object in onPrewiewFrame() were "closed" by direct assignment of null. <object>=null
And System.gc() call at the end of each ALPR-processing loops.
VERY,VERY STRANGE SOLUTION!! :-( It seems to be some bug or feature in android's garbage?!
Only my 30ty years experience in programming helps not to trust for any operation system! ;-))
yur...@gmail.com
Dec 24, 2016, 6:44:34 AM12/24/16
to OpenALPR
Not helped :-(
Time of alive is between 30 sec. to 15 min randomly....
Matt, do You know tesseract? What can be inside?
Monitoring shown no memory leaks in system.... :-(
Time of alive is between 30 sec. to 15 min randomly....
Matt, do You know tesseract? What can be inside?
Monitoring shown no memory leaks in system.... :-(
yur...@gmail.com
Dec 26, 2016, 12:16:00 AM12/26/16
to OpenALPR
New idea: The crash occured even if tablet camera is looking to the floor and not movig, I think, that OpenCV must not to detect any region for recognition and no calls for tesseract are necessary. But why it have been called? Matt, can you look?
yur...@gmail.com
Dec 26, 2016, 6:11:39 AM12/26/16
to OpenALPR
For Matt:
It seems, the idea was valid:
......
12-26 14:04:51.728 31261-31407/ru.privatetest.realcamapp A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x12a8 in tid 31407 (Thread-527)
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp I/Camera-JNI: get_native_camera: context=0xb4b80ee0, camera=0xb49e4fc8
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp I/Camera-JNI: get_native_camera: context=0xb4b80ee0, camera=0xb49e4fc8
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp E/RealCam: Busy
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp E/RealCam: Busy
12-26 14:04:51.828 1023-1023/? I/DEBUG: pid: 31261, tid: 31407, name: Thread-527 >>> ru.privatetest.realcamapp <<<
12-26 14:04:51.858 1023-1023/? I/DEBUG: #00 pc 0045e02e /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::LBPEvaluator::Feature::calc(int) const+13)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #01 pc 0045fd95 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (int cv::predictCategoricalStump<cv::LBPEvaluator>(cv::CascadeClassifier&, cv::Ptr<cv::FeatureEvaluator>&, double&)+164)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #02 pc 004603f9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::runAt(cv::Ptr<cv::FeatureEvaluator>&, cv::Point_<int>, double&)+248)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #03 pc 00461b2d /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifierInvoker::operator()(cv::Range const&) const+172)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #04 pc 001fa431 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::parallel_for_(cv::Range const&, cv::ParallelLoopBody const&, double)+88)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #05 pc 00463509 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectSingleScale(cv::Mat const&, int, cv::Size_<int>, int, int, double, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, std::vector<int, std::allocator<int> >&, std::vector<double, std::allocator<double> >&, bool)+260)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #06 pc 004650c1 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectMultiScale(cv::Mat const&, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, std::vector<int, std::allocator<int> >&, std::vector<double, std::allocator<double> >&, double, int, int, cv::Size_<int>, cv::Size_<int>, bool)+872)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #07 pc 0045d915 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectMultiScale(cv::Mat const&, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, double, int, int, cv::Size_<int>, cv::Size_<int>)+84)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #08 pc 000dfacb /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::DetectorCPU::find_plates(cv::Mat, cv::Size_<int>, cv::Size_<int>)+170)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #09 pc 000dd973 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Detector::detect(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1082)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #10 pc 000c0d13 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::analyzeSingleCountry(cv::Mat, cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+170)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #11 pc 000bfe45 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognizeFullDetails(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1100)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #12 pc 000c35fd /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+68)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #13 pc 000c2ef7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat)+114)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #14 pc 000c2c11 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(std::vector<char, std::allocator<char> >)+104)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #15 pc 000bc3db /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Alpr::recognize(std::vector<char, std::allocator<char> >)+58)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #16 pc 0000bda7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalprjni.so (Java_com_openalpr_Alpr23_native_1recognize___3B+230)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #17 pc 00001cd3 /data/data/ru.privatetest.realcamapp/cache/slice-slice_4-classes.dex
12-26 14:04:52.518 701-31995/? W/ActivityManager: Force finishing activity 1 ru.privatetest.realcamapp/.DirectCamActivity
12-26 14:04:52.518 701-31995/? D/WindowManager: Pausing WindowToken AppWindowToken{1dc14dad token=Token{240e1ac4 ActivityRecord{383e21d7 u0 ru.privatetest.realcamapp/.DirectCamActivity t189}}}
12-26 14:04:52.528 701-31995/? D/InputDispatcher: Focus left window: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.558 701-1065/? W/InputDispatcher: channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
12-26 14:04:52.558 701-1065/? E/InputDispatcher: channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
12-26 14:04:52.568 701-1548/? I/WindowState: WIN DEATH: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.568 701-1548/? W/InputDispatcher: Attempted to unregister already unregistered input channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)'
12-26 14:04:52.568 701-1548/? D/InputDispatcher: Window went away: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.598 701-751/? D/WindowManager: Input focus has changed to Window{106dc6d4 u0 Application Error: ru.privatetest.realcamapp}
12-26 14:04:52.598 701-1151/? I/ActivityManager: Process ru.privatetest.realcamapp (pid 31261) has died
12-26 14:04:52.598 701-751/? D/InputDispatcher: Focus entered window: Window{106dc6d4 u0 Application Error: ru.privatetest.realcamapp}
12-26 14:04:52.799 184-839/? I/Camera2ClientBase: Closed Camera 0. Client was: ru.privatetest.realcamapp (PID 31261, UID 10115)
12-26 14:04:53.229 701-1368/? I/ActivityManager: Force stopping ru.privatetest.realcamapp appid=10115 user=0: from pid 31999
Can this log help?
(The "Busy"- is normal, this is my logging when threads manipulating)
It seems, the idea was valid:
......
12-26 14:04:51.728 31261-31407/ru.privatetest.realcamapp A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x12a8 in tid 31407 (Thread-527)
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp I/Camera-JNI: get_native_camera: context=0xb4b80ee0, camera=0xb49e4fc8
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp I/Camera-JNI: get_native_camera: context=0xb4b80ee0, camera=0xb49e4fc8
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp E/RealCam: Busy
12-26 14:04:51.738 31261-31261/ru.privatetest.realcamapp E/RealCam: Busy
12-26 14:04:51.828 1023-1023/? I/DEBUG: pid: 31261, tid: 31407, name: Thread-527 >>> ru.privatetest.realcamapp <<<
12-26 14:04:51.858 1023-1023/? I/DEBUG: #00 pc 0045e02e /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::LBPEvaluator::Feature::calc(int) const+13)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #01 pc 0045fd95 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (int cv::predictCategoricalStump<cv::LBPEvaluator>(cv::CascadeClassifier&, cv::Ptr<cv::FeatureEvaluator>&, double&)+164)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #02 pc 004603f9 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::runAt(cv::Ptr<cv::FeatureEvaluator>&, cv::Point_<int>, double&)+248)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #03 pc 00461b2d /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifierInvoker::operator()(cv::Range const&) const+172)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #04 pc 001fa431 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::parallel_for_(cv::Range const&, cv::ParallelLoopBody const&, double)+88)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #05 pc 00463509 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectSingleScale(cv::Mat const&, int, cv::Size_<int>, int, int, double, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, std::vector<int, std::allocator<int> >&, std::vector<double, std::allocator<double> >&, bool)+260)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #06 pc 004650c1 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectMultiScale(cv::Mat const&, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, std::vector<int, std::allocator<int> >&, std::vector<double, std::allocator<double> >&, double, int, int, cv::Size_<int>, cv::Size_<int>, bool)+872)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #07 pc 0045d915 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopencv_java.so (cv::CascadeClassifier::detectMultiScale(cv::Mat const&, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >&, double, int, int, cv::Size_<int>, cv::Size_<int>)+84)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #08 pc 000dfacb /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::DetectorCPU::find_plates(cv::Mat, cv::Size_<int>, cv::Size_<int>)+170)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #09 pc 000dd973 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Detector::detect(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1082)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #10 pc 000c0d13 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::analyzeSingleCountry(cv::Mat, cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+170)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #11 pc 000bfe45 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognizeFullDetails(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+1100)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #12 pc 000c35fd /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat, std::vector<cv::Rect_<int>, std::allocator<cv::Rect_<int> > >)+68)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #13 pc 000c2ef7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(cv::Mat)+114)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #14 pc 000c2c11 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::AlprImpl::recognize(std::vector<char, std::allocator<char> >)+104)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #15 pc 000bc3db /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalpr.so (alpr::Alpr::recognize(std::vector<char, std::allocator<char> >)+58)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #16 pc 0000bda7 /data/app/ru.privatetest.realcamapp-1/lib/arm/libopenalprjni.so (Java_com_openalpr_Alpr23_native_1recognize___3B+230)
12-26 14:04:51.858 1023-1023/? I/DEBUG: #17 pc 00001cd3 /data/data/ru.privatetest.realcamapp/cache/slice-slice_4-classes.dex
12-26 14:04:52.518 701-31995/? W/ActivityManager: Force finishing activity 1 ru.privatetest.realcamapp/.DirectCamActivity
12-26 14:04:52.518 701-31995/? D/WindowManager: Pausing WindowToken AppWindowToken{1dc14dad token=Token{240e1ac4 ActivityRecord{383e21d7 u0 ru.privatetest.realcamapp/.DirectCamActivity t189}}}
12-26 14:04:52.528 701-31995/? D/InputDispatcher: Focus left window: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.558 701-1065/? W/InputDispatcher: channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)' ~ Consumer closed input channel or an error occurred. events=0x9
12-26 14:04:52.558 701-1065/? E/InputDispatcher: channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)' ~ Channel is unrecoverably broken and will be disposed!
12-26 14:04:52.568 701-1548/? I/WindowState: WIN DEATH: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.568 701-1548/? W/InputDispatcher: Attempted to unregister already unregistered input channel '264010bb ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity (server)'
12-26 14:04:52.568 701-1548/? D/InputDispatcher: Window went away: Window{264010bb u0 ru.privatetest.realcamapp/ru.privatetest.realcamapp.DirectCamActivity}
12-26 14:04:52.598 701-751/? D/WindowManager: Input focus has changed to Window{106dc6d4 u0 Application Error: ru.privatetest.realcamapp}
12-26 14:04:52.598 701-1151/? I/ActivityManager: Process ru.privatetest.realcamapp (pid 31261) has died
12-26 14:04:52.598 701-751/? D/InputDispatcher: Focus entered window: Window{106dc6d4 u0 Application Error: ru.privatetest.realcamapp}
12-26 14:04:52.799 184-839/? I/Camera2ClientBase: Closed Camera 0. Client was: ru.privatetest.realcamapp (PID 31261, UID 10115)
12-26 14:04:53.229 701-1368/? I/ActivityManager: Force stopping ru.privatetest.realcamapp appid=10115 user=0: from pid 31999
Can this log help?
(The "Busy"- is normal, this is my logging when threads manipulating)
Matt
Dec 26, 2016, 2:47:41 PM12/26/16
to OpenALPR
I've seen strange issues when using the same library across threads. I suspected Tesseract was the culprit, since removing it seemed to resolve the issues. Creating a unique OpenALPR object for each thread works fine, though.
-Matt
yur...@gmail.com
Dec 27, 2016, 5:08:56 AM12/27/16
to OpenALPR
Do You mean, that OPEALPR object needs to be created for each time I have new frame to capture?
So: I can to create several looped threads and each time I whant to make recognition, I have not to put a a new buffered image to existing inside thread OPENALPR object, but create new one and then store it in thread to processing?
The first sample was made in this manner, Not only OALPR, but full THREAD object was creating each time after final of one of threads in threads array.
I'll try Your solution, but it seems, that some multithreading problems are inside OpenCV-Tesseract interaction.
Sincerely Yours
So: I can to create several looped threads and each time I whant to make recognition, I have not to put a a new buffered image to existing inside thread OPENALPR object, but create new one and then store it in thread to processing?
The first sample was made in this manner, Not only OALPR, but full THREAD object was creating each time after final of one of threads in threads array.
I'll try Your solution, but it seems, that some multithreading problems are inside OpenCV-Tesseract interaction.
Sincerely Yours
yur...@gmail.com
Dec 27, 2016, 5:48:58 AM12/27/16
to OpenALPR
Hmmm ( again :-) )
Strange result: 2 times chrushes in about 10 seconds. At other 3..4 attempts works contuniously more, then 15 min( I'm is too lazy to wait more).
I'll comment the code and insert some scaling of images, then put it here as android sample. Can I do this?
Sincerely Yours.
Strange result: 2 times chrushes in about 10 seconds. At other 3..4 attempts works contuniously more, then 15 min( I'm is too lazy to wait more).
I'll comment the code and insert some scaling of images, then put it here as android sample. Can I do this?
Sincerely Yours.
Matt
Dec 28, 2016, 6:05:39 AM12/28/16
to OpenALPR
Yes, each thread should have its own OpenALPR object. For example, one process, and 4 threads would have 4 separate OpenALPR objects for recognizing.
If you had one OpenALPR object and shared it across threads, strange things happen (I'm 90% sure it's just Tesseract that is not fully thread-safe). As long as you don't share the OpenALPR objects across threads, it should work fine.
Here's a discussion about this topic in Tesseract:
If you had one OpenALPR object and shared it across threads, strange things happen (I'm 90% sure it's just Tesseract that is not fully thread-safe). As long as you don't share the OpenALPR objects across threads, it should work fine.
Here's a discussion about this topic in Tesseract:
Their release notes say thread-safe, but that's not technically correct. They are saying "thread-safe" to mean that you can run parallel objects in separate threads that don't communicate. That's not really thread-safety, it's just not broken.
I do plan on dropping Tesseract in the medium (6-12 months) term in favor of a more accurate OCR approach for license plates.
-Matt
yur...@gmail.com
Dec 29, 2016, 1:36:49 AM12/29/16
to OpenALPR
I'm uderstand this. But in my previous (unpredictably crushing ) code EACH thread had it's OWN ALPR object!!
And the solution seems to be in releasing (by assigning NULL to it)and recreating OALPR with "new" operator each time after "recognize" finished.
But (again "but" :-( ) I started my investigations from ctreating new thread with unique OALPRobject for each recognition attempt, Threads were not looped, So after finishing one of them completly new instance of thread with uniq openalpr obj inside was creating instead. This algorithm crushes too. I'm can't understand why RECREATING FULL THREAD causes crushes and RECREATING OALPRobject INSIDE EXISTING LOOPED THREAD seems to be workable! 8-( :-((
The only mind is some JAVA feature like in image processing: if you are loading bitmaps in sycle you must assign null for bitmap object each time before loading new content. In other case only first loaded bitmap guaranted to be seen!
Bitmap bmp;
...
for(.....) {
bmp= BitmapFactory.load(......); //BAD code
....
}
...
-----------------------
Bitmap bmp
.....
for (...){
bmp=null;
bmp= BitmapFactory.load(......);//Workable!
}
......
And the solution seems to be in releasing (by assigning NULL to it)and recreating OALPR with "new" operator each time after "recognize" finished.
But (again "but" :-( ) I started my investigations from ctreating new thread with unique OALPRobject for each recognition attempt, Threads were not looped, So after finishing one of them completly new instance of thread with uniq openalpr obj inside was creating instead. This algorithm crushes too. I'm can't understand why RECREATING FULL THREAD causes crushes and RECREATING OALPRobject INSIDE EXISTING LOOPED THREAD seems to be workable! 8-( :-((
The only mind is some JAVA feature like in image processing: if you are loading bitmaps in sycle you must assign null for bitmap object each time before loading new content. In other case only first loaded bitmap guaranted to be seen!
Bitmap bmp;
...
for(.....) {
bmp= BitmapFactory.load(......); //BAD code
....
}
...
-----------------------
Bitmap bmp
.....
for (...){
bmp=null;
bmp= BitmapFactory.load(......);//Workable!
}
......
Robert
Dec 29, 2016, 9:59:21 AM12/29/16
to OpenALPR
Would you be willing to post a test case that demonstrates the problem to Github?
Matt
Dec 30, 2016, 6:42:48 AM12/30/16
to OpenALPR
Yes, that is very strange. Perhaps some weird memory corruption in the JNI layer... Something like Valgrind may provide clues.
Reply all
Reply to author
Forward
0 new messages