Creaby's Record Storage

OCR의 경우 관련지식이 없으면 API의 이해가 힘들 수 있으므로 소개해 보고자합니다.

버전은 Tesseract 3.05이며 모든 함수명은 tess-two에서 제공하는 TessBaseAPI를 기준으로 합니다. C코드로 되어있는 Tesseract 원본의 경우 함수명이 약간 다릅니다만, 함수명이 비슷하고 매개변수도 포인터로 되어있다 뿐이지 원하는 정보는 크게 다를 게 없기 때문에 원본 Tesseract를 사용하시는 분도 이해하시는 데 큰 문제는 없을겁니다.

1. 가장 기본적인 API

- init(String datapath, String language) : Tesseract를 사용하도록 초기화합니다. datapath는 traineddata가 있는 주소, language는 사용할 언어를 입력하시면 됩니다.( ex. eng / kor / eng+kor )

- setImage(Bitmap bitmap) : 읽어들일 이미지를 지정합니다. 입력값으로 활용할 수 있는 타입은 비트맵, 파일주소, Leptonica에서 사용하는 pix, byte[]로 된 이미지 데이터가 있습니다.)

- getUTF8Text() : 인식한 결과값을 String형으로 출력합니다.

- end() : 메모리를 해제합니다.

2. 추가 기능 API

- setRectangle(Rect rect) : 전체 이미지에서 원하는 영역만 지정해서 OCR 인식할 때 사용합니다. x, y, width, height값으로 영역을 지정할 수 있고 동일한 결과를 낼 수 있는 방법으로는 전체 이미지에서 createBitmap으로 원하는 영역의 이미지만 crop해서 setImage 후 getUTF8Text를 실행하는 방법이 있습니다.

- setVariable(String var, String value) : 일반적으로 Whitelist나 Blacklist를 사용할 때 사용합니다. WhiteList는 입력한 값만 출력되도록 하는 것이고 BlackList는 입력한 값을 출력에서 배제하는 것입니다. var에는 API에서 제공하는 속성값을 넣고 value에 값을 넣으시면 됩니다.

*setVariable("VAR_CHAR_WHITELIST", "1234567890") -> 숫자만 출력하고 싶을 때 사용합니다.

*setVariable("VAR_CHAR_BLACKLIST", "1234567890") -> 출력값에서 숫자를 배제하고 싶을 때 사용합니다.

- setPageSegMode(int mode) : 텍스트 이미지를 인식할 때 분할 방법을 결정합니다. 이부분은 OCR의 구동 원리와 가까운 내용이라 자세한 건 나중에 원리에 대해 설명하게 되면 다시 언급하겠습니다. 전체를 인식할 땐 기본 모드를 쓰는 게 낫기 때문에 그대로 두시고, 한줄만 읽고 싶으시다면 PSM_SINGLE_LINE을 사용하시는 것을 추천드립니다.

실제로 쓰이는 건 이정도입니다. 그나마도 setVariable은 전처리가 완벽히 확보된 이미지가 아니라면 안쓰시는 것이 인식결과가 좋기 때문에 실제로 자주 사용되는 것은 필수적인 API를 제외하고는 setRectangle과 setPageSegMode 정도입니다. 다음 Tesseract 관련 포스팅은 Tesseract로 가장 인식률을 높힐 수 있는 방법과 인식률이 떨어지는 사례가 될 것 같습니다.

참고

Android Tesseract Github : https://github.com/rmtheis/tess-two

private class HastTest {
   int value1, value2, value3;
   String key;

   HastTest(String key, int a, int b, int c) {
      this.key = key;
      this.value1 = a;
      this.value2 = b;
      this.value3 = c;
   }
}

public static void main(String args[]) {
   Map mHastTest = new HastMap() {
   HastTest hastTest = new HastTest("testKey", 10, 20, 30);
   
   mHastTest.put("testKey", hastTest);

   for(String key : mHastTest.keySet()) {
      System.out.println("Result : " + key + ", " + mHastTest.get(key).value1 + ", " + mHastTest.get(key).value2 + ", " + mHastTest.get(key).value3);
   }
}

이렇게 Class로 만들어서 value값에 넣어주시면 하나의 key값에 여러 value값을 저장하실 수 있습니다.

코드 자체가 단순하니 어렵지 않게 응용하실 수 있을겁니다.

요즘은 안드로이드에서는 SparseArray를 쓰지만 자바에서는 계속 HashMap을 쓰는 것 같아서 작성해봤습니다.

블로깅을 시작하면서 느낀건 데 공부할 게 너무 많네요..ㅠㅠ

SQLite를 사용하기 때문에 별 생각없이 CursorAdapter로 Listview를 구성하면 DB를 수정, 삭제하거나 Listview의 정렬방식 변경, 검색등과 같이 Listview상의 순서를 기존과 다르게 변경하는 경우 Item position 값이 꼬이는 문제가 생깁니다. 그래서 일반적으로 ArrayAdapter를 사용하는 경우처럼 Listview상의 Item을 터치하여 해당 Item값을 불러오는 Activity를 띄우려고 할 때 setOnItemClickListener에서 제공하는 position값을 그대로 사용하면 엉뚱한 결과값이 출력되거나 아에 죽어버리는 상황을 맞이하게 됩니다.

간단히 DB 삭제의 경우를 예로 들어보겠습니다.

위와 같이, setOnItemClickListener에서 제공하는 position값으로 DB를 삭제해버리는 경우, 겉으로 보기에는 제대로 지워진 것처럼 보이지만 실제로는 ListView의 position값과 DB값은 꼬여버립니다. 만약 position=1에 해당하는 item을 삭제한 후에 position=2에 해당하는 아이템을 터치하면 D에 해당하는 DB값이 출력되는 게 아니라 C에 해당하는 DB값이 출력될겁니다. 물론 position=1에 해당하는 아이템을 다시 터치하게 된다면 index=1이었던 DB값은 삭제된 후이기 때문에 예외처리를 안했다면 죽는 문제가 생기겠죠.

따라서, Listview의 position값을 그대로 사용하는 게 아니라 position에 해당하는 DB의 _id값을 불러와서 제어하는 것이 좋습니다.

listview.setOnItemClickListener(new AdapterView.OnItemClickListener() {
   @Override
   public void onItemClick(AdapterView adapterView, View view, int position, long l) {
      Intent intent = new Intent(MainActivity.this, InfoActivity.class);

      Cursor cursor = (Cursor) cursorAdapter.getItem(position);
      String index = cursor.getString(cursor.getColumnIndex("_id));
      int id = Integer.parseInt(index);

      intent.putExtra("id", id);
      startActivityForResult(intent, 0);
   }
});

먼저 getItem으로 현재 position에 있는 item값을 불러오고, 그 중 getColumnIndex로 _id값을 불러와서 그 id값을 기준으로 불러오시면 정상적으로 원하시는 DB값이 호출되는 것을 보실 수 있습니다.

참고

http://arabiannight.tistory.com/entry/368

안드로이드 개발하면서 절대 빠질 수 없는 것 중 하나가 AsyncTask일겁니다.

그만큼 AsyncTask의 개념이나 사용법에 대한 설명이 매우 많은 데, 중요하지만 자주 언급되지 않는 기능 하나를 소개하겠습니다.

AsyncTask를 사용하게 되면 일반적으로 현재 이 프로그램이 실행되는 지 아닌 지 확인하기 위해 Dialog를 띄웁니다. 문제는 작업량이 많아서 로딩이 길어지는 경우인 데, 로딩 중에 사용자가 무심코 주위를 터치하게 되면 Dialog창이 꺼져버려서 현재 이게 먹통이 된건지, 어느 정도 처리가 된 상태인 지 알 방도가 없습니다. 버튼 이벤트에 대한 처리를 딱히 안했다면 그 상태에서 중복터치를 해서 프로그램이 완전히 꼬여버리는 문제까지 생기기도 합니다. 이를 방지하기 위해 있는 기능이 setCanceledOnTouchOutSide(boolean)입니다.

@Override
protected void onProgressUpdate(Void... values) {
   dialog.setCanceledOnTouchOutside(false);
}

@Override
protected void onPostExecute() {
   dialog.setCanceledOnTouchOutside(true);
   dialog.dismiss();
}

어렵지 않죠? 하지만 로딩 시간이 1초만 돼도 꼭 필요한 기능입니다.

물론 그 이하도 웬만하면 넣어주시는 게 안정성을 향상시키는 데 있어서 좋다고 생각합니다.

출처 : https://developer.android.com/reference/android/app/Dialog.html#setCanceledOnTouchOutside(boolean)

이번엔 메모리 관리 시 주의해야할 부분에 대해 알아보겠습니다.

안드로이드에서 메모리는 VM Heap과 Native Heap을 사용하는 데, OutofMemoryError의 해결책을 찾기 위해 구글링을 열심히 하다보면 자주 볼 수 있는 내용 중 하나가 "Honeycomb 버전부터는 안드로이드에서 관리되는 비트맵은 모두 VM Heap에서 관리한다." 입니다. (제가 제대로 이해한건지는 모르겠지만;)

실제로 이전 글에 썼던 것과 같이 Recycle을 적절히 활용해주면 중간중간 메모리를 찍어봤을 때 VM Heap에 메모리가 쌓이고 줄어드는 것을 알 수 있습니다. 굳이 찍기 귀찮다 싶으면 안드로이드 스튜디오 상에서 Android Monitor -> Monitors 탭으로 들어가서 정확하진 않아도 가시적으로나마 확인할 수도 있죠.

그런데 로그상에서 메모리 관리가 제대로 되는 걸 확인한 상태임에도 불구하고 수십번을 반복하다보면 어느 순간 에러도 없이 죽어버리는 경우가 있습니다. 저같이 로그와 디버깅만 믿고 살아가는 초보 개발자에겐 정말 멘탈 터지는 상황이 오는거죠. 다른 케이스가 또 있을지는 모르겠으나, 제가 발견한 원인은 Native heap의 메모리 축적이었습니다. 이전 글에서 밝혔다시피, 메모리 문제가 심하게 터졌던 이 프로젝트에는 영상처리가 들어가있었기 때문에 NDK가 적용되어 있는 상태였는 데, Release 함수를 적용한 상태라 신경을 안쓰고 있었는 데, 영상처리 파트에서 메모리 관리를 잘못해서 Native heap이 쌓이고 있었던 겁니다. 그러니 평소에도 내 영역이 아니더라도 내게 영향을 미칠 수 있다면 확인을 하는 습관을 들이는 게 좋을 것 같습니다.

소스도 없고, 그림도 없고, 주저리 주저리 쓸데없는 일기들만 가득찬 글만 있어서 읽기 싫은 분들을 위해 요약해드리자면,

1. 비트맵을 NDK로 넘길 때는 VM Heap이 아니라 Native Heap에서 관리한다. <- 전 이거 몰랐습니다ㅠㅠ

2. 그러므로 NDK를 사용하고 있는 상태라면, Release 함수를 적용하더라도 중간 중간에 Native Heap Size의 로그를 찍어본다.

3. 만약 문제가 있다싶으면 담당자 찾아가서 담당자의 직책에 따라 태세변환하며 메모리 관리 부분을 확인해줄 것을 요청한다.

- 참조 사이트 http://d2.naver.com/helloworld/539525 

                  -> 메모리 관리에 대해 하나부터 열까지 정리되어 있습니다. 정독하면 메모리 관리에 도움이 되실 겁니다.

그동안 하이브리드 앱을 만들다가 작년에 영상처리를 해주는 앱을 만들게 되었는 데, 이때 영상처리 파트 쪽에서 고화질의 이미지를 넘겨주길 원했습니다. 문제는 앱의 프로세스 상 한번에 수십장을 처리해야하는 부분까지 존재했다는 것이었죠. 상황이 이러하다보니 이론이 소홀히 했던 저는 OutofMemoryError를 자주 접했습니다. 따라서 저와같은 상황에 처한 주니어 개발자분들을 위해 제가 극복한 방법을 리마인드겸 모두 적어볼까합니다.

1. Bitmap.recycle의 호출 시점

제가 넘겨주는 이미지의 해상도는 디바이스의 성능 및 지원 해상도에 따라 최소 1920x1080에서 최대 4032x2268 정도였습니다. 당연히 최대 해상도를 가진 이미지의 용량이 어마어마했고 Asynctask로 다섯장만 돌려도 OutofMemoryError가 뜨며 죽는 현상이 일어났죠. 이를 해결하기 위해 열심히 구글링해본결과 onDestroy나 onPostExecute 등 더이상 비트맵을 사용하지 않는 구간에서 bitmap.recycle을 하라는 것이었습니다. 

여러장을 돌리는 저에겐 당연스럽게도 onPostExecute에 들어가기도 전에 죽어버렸고, Bitmap.recycle을 여기저기 들쑤시며 넣어보다가 recycle 후에 bitmap을 사용하려해서 생기는 에러에 맞닥들이게 되었습니다.

@Override
protected void doInBackground(Void... params) {
   Bitmap bitmap = null;
   for (int i = 0; i < imageItems.size(); i++) {
       bitmap = BitmapFactory.decodeFile(imageItems.get(i).getFilePath());
       Bitmap result = jniLib.jniFunction(bitmap);

       bitmapSaveFile(filePath, bitmap, 100);
       
       if (!bitmap.isRecycled()) {
          bitmap.recycle();
       }
   }
}

얼마나 멍청하게 짰는 지 아시는 분은 다 아시겠지만... 학창시절에 이론공부를 소홀히 하고 비전공으로 대학원을 진학하면서 2년을 쉰 저로선 파악이 제대로 안됐었습니다. (이론 공부 열심히 합시다;;)

무엇이 문제인지 제대로 파악이 안되는 저와 같은 처지의(?) 주니어 개발자분들을 위해 설명해드리자면, 어느 변수든 마찬가지지만 초기화를 해주지 않으면 새로운 변수값이 계속 들어간다고 해도 주소값은 계속 남아있습니다. 

따라서 Bitmap 선언을 for문 밖에서 해버리면 처음 프로세스가 진행될 때 recycle을 해버린 상태에서 다시 bitmap을 사용하려고 해서 위와 같은 에러와 함께 앱이 죽어버리죠. 일반적인 변수들은 모두 용량이 적기 때문에 잘 모르고 지나칠 수도 있지만 bitmap은 워낙 용량이 크기 때문에 제대로 초기화를 안해주면 Recycle의 여부를 떠나서 메모리가 쌓이므로 결국 죽어버립니다. 

이를 고려하여 수정한 코드는 아래와 같습니다.

@Override
protected void doInBackground(Void... params) {
   for (int i = 0; i < imageItems.size(); i++) {
       Bitmap bitmap;
       bitmap = BitmapFactory.decodeFile(imageItems.get(i).getFilePath());
       Bitmap result = jniLib.jniFunction(bitmap);

       bitmapSaveFile(filePath, bitmap, 100);
       
       if (!bitmap.isRecycled()) {
          bitmap.recycle();
       }
   }
}

.. 참 쉽죠? Bitmap 선언만 for문 안으로 내렸습니다. 이렇게 하면 한 번 돌릴 때마다 recycle을 실행하더라도 bitmap을 초기화 하기 때문에 다시 recycle을 실행해도 기존 bitmap을 재사용하지 않습니다. 따라서 메모리가 쌓이는 일은 더이상 발생하지 않기 때문에 이제는 bitmap 크기 따위 신경 안쓰고 마음껏 돌리셔도 됩니다!

하나 추가하자면, 모든 bitmap 관련 프로세스들은 외장메모리에 파일로 저장 후 주소값만 넘겨서 다시 불러오는 방식으로 작업해야합니다. bitmap을 그대로 넘겨버리면 아주 쉽게 OutofMemoryError를 접하실 수 있을겁니다. 에러가 안뜨더라도 디바이스가 무거워지니 이왕이면 파일주소로 주고받아서 관리해주시는 게 좋습니다.

다음엔 Heap으로 인해 발생했던 메모리 이슈와 그 원인에 대해 알아보겠습니다.

- 저도 주니어 개발자이고 경험을 통해 작성하는 것이기 때문에 틀린 부분이 있을 수 있습니다. 만약 다른 의견이 있으시거나 틀린 부분이 있으면 댓글로 남겨주시면 감사하겠습니다.

- 오늘도 주니어 개발자분들 가시는 길에 에러가 없길 빕니다.