[피어세션] 2021-05-25

[jun9choi]

피어세션 요약

• 데이터 전처리
  이미지 크기는 신경쓰지 않아도 된다. 배경을 깔끔하게 전처리 하는 게 중요!!

1. DE-GAN 논문 (2020) : 배경을 없애주는 모델로 Unet과 비슷한 구조를 가진다. (Deblur)
   https://github.com/dali92002/DE-GAN
2. 전통적인 방법 : Adaptive threshold, Median blur, Closing
   이미지마다 적절한 hyperparameter를 찾아줘야 한다.

• 내일 베이스라인 이해한 내용 공유 및 취합하기.

• SATRN : 아마 이번 대회 메인 모델

• 전처리. 후처리에 대한 모델도 고민해보기 ex) 후처리 - 괄호 개수 안 맞으면 자동 추가
  지난 DST, MRC 대회 1등 솔루션 보면 후처리 모델도 따로 만들어줬다.

• 외부 데이터 활용 방안
  Unpretrained 모델로 캐글 데이터(10GB) 학습 → 우리 문제 pretrained weight로 쓰기
  준철: convert latex to jpg 사이트를 이용하면 gt로 깔끔한 이미지 생성 가능.

• Swin transformer 활용해서 모델 만들기
  backbone : CNN과 달리 attention 구조로 feature를 뽑는다.
  neck : embedding vector로 가져오니까 decoder(transformer)로 보낼 수 있으면
  end-to-end transformer 모델을 만들 수 있을 것 같다.

---

서베이 논문 Text Recognition in the Wild: A Survey (2020)

• OCR vs STR(Scene Text Recognition)
  OCR은 정해진 형식이 있는 경우가 많으므로 (명함, 문서 등) 우리 문제는 STR에 더 가깝다.

• Background Removal : GAN을 사용하면 전처리 성능 크게 향상 (preprocessor로 활용)
• Text Image Super-Resolution : resolution을 낮게 학습시킬 필요는 없다.
• 2D prediction problems : 최근에는 sequential model의 decoder가 transformer이다.

---

강의에서 소개된 논문 ASTER

• 서로 다른 image size 해결방법
  CNN을 거쳐 나온 activation map은 w, h는 제각각이지만, 채널 수는 동일하다.
• (w,h,c) 3차원 텐서 → (w*h, C) 2차원으로 reshape
  각 column이 하나의 데이터 (c차원)
  즉, 이미지 별로 input 개수(row 수)만 서로 다르다.
• 모든 sequence를 linear combination하여 fixed length sequence로 만들어 GRU에 입력.

alpha_i : attentional weights
h_i : encoder output

---

모델 탐색

• Irregular text dataset에 대해 좋은 성능을 보인 논문을 찾아보면 좋다.
• SATRN https://github.com/clovaai/SATRN
  Day8에 제공될 베이스라인. 네이버에서 만든 모델.
  성능이 뛰어난 것으로 보아 아마 이번 대회 메인 모델이 될 것 같다.
• RobustScanner https://arxiv.org/pdf/2007.07542v2.pdf
• SAR https://arxiv.org/pdf/1811.00751.pdf
  regular text에 대해서 좋은 성능
• 손글씨 수식 데이터
  encoder : VGG 등 (binary image로 전처리 하기 때문에 가벼워도 될 듯)
  decoder : attention 구조

---

토론 게시글 올리기 - 누리

• sentence accuracy 100% 맞추는 게 중요!
  \rightarrow 와 \to 는 출력되는 기호가 똑같은데 정답은 어떻게 처리되는지??

---

🍖Github Cookbook

v1.0(2021.05.25 수정)

가장 간단한 방법들로 구성했고, 같은 기능 구현을 위한 방법은 많으니, 혹시나 다른 방법이 궁금하다면 찾아보고 공유부탁드립니다^^

Background

• origin: 현재 내 로컬 환경이 리모트하는 저장소의 별칭. Fork해 작업한다는 가정 하에 각자의 원격저장소를 의미
• upstream: 현재 내 로컬 환경이 리모트하는 원격저장소의 upstream 저장소의 별칭. Fork해 작업한다는 가정 하에 bcaitech의 원격저장소를 의미

Essentials

• upstream 저장소를 fork해오기 - **fork**

  bcaitech 저장소에 들어가 우측 상단의 Fork 버튼 클릭

  Fork로 upstream 저장소를 가져오면, 브랜치 목록 등 기존 upstream 저장소가 지닌 상태 정보를 모두 가져오게 됩니다

  

• 원격저장소를 로컬에 가져오기 - **clone**

  가져올 레포의 Code 섹션을 클릭하고 HTTPS 링크를 복사합니다

  

  로컬에서 다음의 명령어를 통해 클론합니다

  git clone https://github.com/iloveslowfood/p4-fr-sorry-math-but-love-you.git

• 작업 과정 중 기록에 반영할 파일을 스테이징하기 - **add**

  # 특정 파일만 스테이징할 경우
  git add <YOUR_FILE_NAME>
  
  # 모든 파일을 스테이징할 경우
  git add .

• 스테이징한 파일의 변화를 git에 기록하기 - **commit**

  add를 통해 스테이징한 소스에 대해서'만' 커밋할 수 있으므로 꼭 스테이징 과정을 거쳐주세요!

  커밋 메시지는 필수! 다른 사람도 알아볼 수 있도록 어떤 작업을 진행했는지 간단히 적어줍시다.

  커은 잘게 끊어서 할 수록 좋습니다. 가령, 데이터셋 관련 기능 구현을 위해 (1)데이터를 불러오는 기능을 구현하고 (2)전처리 기능을 구현한다면, 한꺼번에 커밋하는 것보다 두 번으로 나누어 커밋하는 것이 바람직합니다.

  # 예: 데이터를 불러오는 기능 구현에 대한 커밋
  git commit -m "add function for loading dataset: blahblah---"
  
  # 예: 데이터 전처리 기능 구현에 대한 커밋
  git commit -m "add function for preprocessing: blahblah---"

• 커밋한 데이터를 원격 저장소에 반영하기 - **push**

  **commit**을 통해 기록된 파일에 대해서'만' **push**가 가능하므로 꼭 커밋 과정을 거쳐주세요!

  git push # origin 원격저장소에 내용을 전송

• 원격 저장소에서 상태 정보를 가져오기 - **fetch**

  새로운 브랜치 생성, 코드 변화 등 원격 저장소에서 어떤 변화가 발생했는지의 상태 정보를 얻어오기 위한 과정입니다

  데이터를 원격저장소에서 가져오는 **merge**와 달리 데이터를 가져와 병합하는 것은 아닙니다

  # origin 저장소의 상태 정보를 가져올 떄
  git fetch origin
  
  # upstream 저장소의 상태 정보를 가져올 때
  git fetch upstream

• 원격 저장소의 소스를 가져와 현재 로컬 작업 환경에 병합하기 - **merge**

  소스를 원활히 병합해오기 위해서는 변화 내역을 우선적으로 알아야 하기 때문에 **fetch**가 선행되어야 합니다!

  git merge <데이터를 가져올 브랜치명>
  
  # origin 원격저장소의 main 브랜치로부터 데이터를 병합해올 경우
  git fetch origin # fetch 필수!
  git merge origin/main
  
  # origin 원격저장소의 example_branch 브랜치로부터 데이터를 병합해올 경우
  git fetch origin # fetch 필수!
  git merge origin/example_branch
  
  # upstream 원격저장소의 main 브랜치로부터 데이터를 병합애올 경우
  git fetch upstream # fetch 필수!
  git merge upstream/main
  
  # upstream 원격저장소의 example_branch 브랜치로부터 데이터를 병합애올 경우
  git fetch upstream # fetch 필수!
  git merge upstream/example_branch 

• 원격 저장소로부터 소스를 가져오기 - **pull**(=**fetch**+**merge**)

  pull은 기본적으로 **fetch** + **merge**와 같습니다. 상태정보'만' 가져올 필요가 없을 떄(**fetch**) **pull**을 통해 위 두 과정을 수행할 수 있습니다.

  # origin 원격저장소의 master 브랜치로부터 소스를 가져올 경우
  git pull origin master
  
  # upstream 원격저장소의 master 브랜치로부터 소스를 가져올 경우
  git pull upstream master

Branching

• 현재 로컬 저장소에서 인식되는 브랜치 목록 확인하기

  원격저장소의 브랜치 목록과 로컬 저장소의 브랜치 목록은 다를 수 있음!

  특히, 원격저장소의 브랜치가 로컬 저장소에는 없는 문제가 자주 있는데, 이럴 때는 [원격 저장소에는 있는 브랜치가 내 로컬에서는 안보일 때 추적하기 - **remote**]를 참고!

  git branch --list

• 브랜치 만들기 - 로컬(터미널)에서 만들기 - **branch**, **checkout**

  방법 1 - **branch**: 브랜치를 생성

  git branch <생성할 브랜치명>

  방법 2 - **checkout**: 브랜치 생성과 동시에 해당 브랜치로 이동

  git checkout -b <생성할 브랜치명>

  주의!! 로컬 환경에서만 브랜치를 생성한 것이기 때문에, 원활한 작업을 위해서는 원격저장소에 브랜치를 생성했다는 정보를 꼭 전해줘야 합니다(**push**). 다음과 같이 전달합니다.

  # origin 원격저장소에 로컬에서 생성한 브랜치 정보를 push
  git push -u origin <생성한 브랜치명>

• 브랜치 만들기 - 원격저장소(깃헙)에서 만들기

  자신의 깃허브 원격저장소에서 좌측 상단의 브랜치 버튼을 누른 뒤 입력 란에 만들고자 하는 브랜치명을 입력, Create branch 버튼을 클릭하면 생성 끝!

  

  주의!! 원격저장소에서 브랜치를 만들었기 때문에 로컬에서 새로운 브랜치를 잡아내려면 다음과 같이 fetch가 필요합니다!

  # origin 원격저장소(자신의 원격저장소)로부터 상태 정보를 얻어옴으로써 새로운 브랜치를 인식
  git fetch origin

• 원격 저장소에는 있는 브랜치가 내 로컬에서는 안보일 때 추적하기 - **remote**

  # origin 원격저장소의 new-branch 브랜치를 추적할 브랜치를 생성
  git checkout --track origin/new-branch

깃허브 기본 기능

1. 본인 로컬과 원격 저장소 연결 (repository를 가져오는 것, git clone)

2. 브랜치 생성: 독립적인 작업환경 구축

3. cd git clone한 폴더
   git fetch : 원격 저장소의 새로운 소식 확인 가능

4. git checkout 브랜치명
   git branch —list : 현존하는 브랜치 확인 가능

5. Staging
   git add 파일경로 ( . 이면 변화가 있는 모든 파일을 의미)
   git status : 업로드 된 파일 확인하기
   (vscode → git extension → Staged Changes에 add한 파일 올라와 있다.)
   git commit -m "커밋메시지(컨벤션!!)" : 업로드한 파일을 승인 (.git 폴더에 기록됨)
   git push origin 브랜치명 : staged, commit한 파일을 푸쉬함.

6. Merging : 변화된 작업물을 한 곳에 취합
   본인 브랜치에서 Pull request 버튼을 누르면 다른 브랜치로 작업물을 보낼 수 있음
   충돌 발생하면 빨간색 X 나옴.

   

   

다른 브랜치에서 merge 받을 때는 모든 작업물이 한 번에 받아와진다. 선택불가
소스트리 : merge하는 프로그램?? https://www.sourcetreeapp.com/

7. master 브랜치를 각자 저장소로 fork해서 독립적으로 작업한 후 master로 merge.
   fork 했을 때 부모 레포는 upstream, 내 레포는 origin이라는 별칭이 붙는다.

누군가가 마스터 브랜치로 pull request 하면 변화가 생긴 부분에 대한 코드리뷰를 해서 업데이트 할 수 있다.
git fetch (upstream/master) # 어떤 새로운 소식이 있는지 확인
git merge upstream/master # 어느 브랜치에서 작업물을 가져올지!

GitHub Projects, Issues 활용

Milestones : 진척도를 확인하기 좋다. (progress bar)

Discussions : Notion과 비슷한 기능. 피어세션 기록

---