HOG란? AI에서 밝기 변화의 방향을 모아 이미지의 형태를 표현하는 방법

TL;DR

HOG는 이미지의 작은 구역마다 밝기가 변하는 방향과 세기를 모으고, 이웃 구역으로 정규화해 형태를 숫자로 표현하는 특징 추출 방법입니다. 사진의 원래 색이나 픽셀값을 그대로 비교하는 대신 윤곽과 질감의 분포를 사용합니다. HOG 자체가 사람·상품의 이름이나 위치를 판정하는 모델은 아닙니다. 분류기와 탐색 창을 따로 결합하며 셀·블록·방향 구간과 입력 크기가 같아야 특징을 일관되게 비교합니다.

핵심 3줄 요약

• 핵심 1
  밝기 변화의 방향을 셉니다. 작은 셀에서 기울기 방향을 구간으로 나누고 변화의 세기를 반영해 히스토그램을 만듭니다.
• 핵심 2
  이웃 셀을 함께 정규화합니다. 겹치는 블록마다 상대적인 크기를 맞춰 일부 조명·대비 변화의 영향을 줄입니다.
• 핵심 3
  특징 추출과 판정은 다릅니다. 출력은 숫자 벡터입니다. 라벨이나 탐지 상자는 별도 분류기·탐색·후처리에서 얻습니다.

이 글에서 다룰 내용

HOG를 한 문장으로 정의하면 무엇인가요?

HOG는 규칙적으로 나눈 이미지 영역에서 밝기 기울기의 방향별 분포를 계산하고 이웃 영역의 대비를 정규화해 이어 붙이는 시각 특징 기술자입니다.

영문명은 Histogram of Oriented Gradients이며 방향성 기울기 히스토그램으로 옮깁니다. 여기서 기울기는 손실 함수를 줄이는 학습 방향이 아니라 이미지에서 밝기가 가장 빠르게 달라지는 방향과 변화량입니다. 경계선 자체의 방향과 밝기가 변하는 방향도 구별합니다.

Dalal·Triggs의 원 논문은 촘촘한 셀 격자와 겹치는 블록의 정규화를 결합해 사람 탐지용 형태 표현을 설명합니다. 이 글은 직사각형 셀을 사용하는 기본 흐름을 다루며, 모든 변형의 설정이나 출력 크기가 같다고 가정하지 않습니다.

한 줄 정리: HOG는 이미지의 형태를 비교할 숫자 재료입니다. 재료를 만든 뒤 무엇인지 판정하는 단계는 별도로 남습니다.

쉬운 예시로 이해해 볼까요?

감자나라ai님이 작은 손글씨 숫자 이미지를 0부터 9까지 분류한다고 가정해 보겠습니다. 검은 배경에 흰 획이 있으면 획의 가장자리에서 밝기가 크게 바뀝니다. 아래 예시는 처리 과정을 설명하는 가정이며 실제 분류 성능을 측정한 결과는 아닙니다.

이미지를 작은 네모 칸으로 나눈 뒤 각 칸에서 밝기가 어느 방향으로 바뀌는지 모읍니다. 곧은 획이 많은 부분과 휘어진 획이 많은 부분은 방향 분포가 다릅니다. 같은 모양을 조금 밝게 촬영했다면 픽셀값은 달라져도 정규화한 방향 분포는 덜 달라질 수 있습니다.

칸의 위치도 유지합니다. 위쪽 칸의 분포와 아래쪽 칸의 분포를 따로 이어 붙이므로 사진 전체에서 세로 변화가 몇 번 나왔는지만 세는 방식과 다릅니다. 위치별 패턴을 모은 벡터를 정답 라벨이 있는 분류기에 전달해 숫자를 구분합니다.

OpenCV의 손글씨 SVM 예제도 HOG 계열 특징을 분류기의 입력으로 사용합니다. 다만 이 예제는 네 구역에 각각 16개 방향값을 모으는 간단한 구현입니다. 표준 HOGDescriptor나 scikit-image의 겹치는 블록 설정을 그대로 실행한 예제라고 읽지는 않습니다.

쉬운 예시: 숫자의 색을 외우기보다 어느 위치에서 어느 방향으로 밝기가 바뀌는지 기록한 뒤 그 기록을 보고 별도 분류기가 이름표를 고르는 흐름입니다.

왜 AI에서 HOG가 중요한가요?

픽셀값을 형태의 분포로 바꿉니다

같은 윤곽도 조명이나 배경 대비에 따라 원본 숫자가 달라집니다. HOG는 국소적인 방향 분포를 모으고 블록 단위로 정규화해 이런 차이를 일부 줄입니다. 색상 자체나 모든 픽셀 위치를 보존하는 표현은 아니므로 작업에 필요한 정보가 남는지 확인합니다.

특징 추출과 모델 학습을 분리합니다

셀 크기와 방향 구간을 정하면 HOG 계산 자체에는 정답 라벨이 필요하지 않습니다. 그러나 숫자 분류기나 보행자 분류기의 계수는 라벨로 학습합니다. 특징 계산에 학습이 없다는 사실을 시스템 전체가 학습 없이 사물을 알아본다는 뜻으로 넓히지 않습니다.

기준 모델과 실패 원인을 비교합니다

학습된 이미지 특징과 비교할 전통적 기준선이 필요할 때 검토합니다. 같은 입력에서 형태 표현과 분류기를 나눠 바꾸면 오류가 어디에서 늘었는지 살피기 좋습니다. 딥러닝보다 항상 빠르거나 적은 데이터에서 항상 정확하다는 보장은 없으며 실제 장비에서 품질과 비용을 측정합니다.

핵심 인사이트: HOG의 역할은 의미를 설명하는 문장을 만드는 데 있지 않습니다. 위치별 밝기 변화의 분포를 후속 판정에 쓸 숫자로 만드는 데 있습니다.

HOG는 어떤 순서로 작동하나요?

1. 가로·세로 밝기 변화를 계산합니다

주변 픽셀의 차이로 가로와 세로의 기울기를 구하고 크기와 방향으로 바꿉니다. scikit-image의 컬러 입력은 각 픽셀에서 변화가 가장 큰 채널의 기울기를 사용합니다. 색상 채널별 벡터를 무조건 모두 붙이는 것으로 설명하지 않습니다.

2. 셀마다 방향별 히스토그램을 만듭니다

셀은 이미지를 나눈 작은 공간 구역입니다. 각 픽셀의 방향이 속한 구간에 기울기의 크기를 반영합니다. 대표적인 부호 없는 방향 표현은 반 바퀴 범위를 사용해 반대 방향을 함께 다룹니다. 이는 이미지를 회전해도 같은 표현이 된다는 뜻은 아닙니다.

3. 겹치는 블록에서 상대 크기를 맞춥니다

블록은 여러 셀을 묶어 정규화하는 영역입니다. 같은 셀이 서로 다른 블록에 참여하면 이웃 구성이 달라 각기 다른 정규화 값으로 출력에 포함됩니다. scikit-image의 알고리즘 안내도 이 중복을 의도된 블록별 표현으로 설명합니다.

block_norm="L2-Hys" 는 L2 정규화 뒤 큰 성분을 0.2로 제한하고 다시 L2 정규화합니다. 마지막 재정규화 때문에 최종 성분이 모두 0.2 이하인 것은 아닙니다. 밝기 변화가 거의 없는 영역의 계산에도 작은 안정화 항을 사용합니다.

4. 블록을 정해진 순서로 이어 붙입니다

정규화된 모든 블록의 값을 같은 순서로 모으면 한 입력 영역의 특징 벡터가 됩니다. 이 벡터에는 사람·숫자 같은 정답 이름이 없습니다. 이미지의 크기나 셀·블록 설정을 바꾸면 벡터의 길이와 각 위치의 의미도 달라집니다.

실전 팁: 픽셀 전처리, HOG 설정, 블록의 연결 순서와 분류기 계수를 하나의 묶음으로 보관하세요. 길이가 같다는 것만으로 같은 표현이 되지는 않습니다.

주요 설정과 결과는 어떻게 읽나요?

셀·블록·방향 구간은 서로 다른 크기입니다

orientations=9 는 방향 구간 수입니다. pixels_per_cell=(8, 8) 은 셀의 픽셀 크기이고 cells_per_block=(2, 2) 는 한 블록의 셀 수입니다. 확인한 scikit-image API의 기본 블록은 3×3셀입니다. 설명용 2×2셀 설정을 기본값이라고 부르지 않습니다.

출력 차원은 블록의 개수까지 반영합니다

가로·세로 32픽셀 이미지에 8×8픽셀 셀, 2×2셀 블록, 셀 한 칸씩의 블록 이동, 9개 방향 구간을 사용하면 셀은 4×4개이고 블록은 3×3개입니다. 최종 길이는 3 × 3 × 2 × 2 × 9 = 324 입니다. 픽셀 수나 검출한 사물 수가 아닙니다.

같은 셀·블록·방향 조건으로 세로 128·가로 64픽셀 창을 계산하면 3,780개 값입니다. 블록만 3×3셀로 바꾸면 6,804개입니다. 이 수치는 Python·NumPy로 고정 설정의 산술을 확인한 것이며, OpenCV나 HOG 함수를 실행해 특징을 추출한 측정값은 아닙니다.

반환 벡터와 시각화 이미지를 나눠 봅니다

feature_vector=True 는 블록 배열을 일차원으로 펼칩니다. visualize=True 일 때 추가로 받는 이미지는 방향별 반응을 보는 그림입니다. 원본 복원이나 분류기가 중요하게 본 위치의 증명이 아닙니다. RGB 배열에서는 channel_axis=-1 처럼 채널 축도 명시합니다.

현재 hog API의 함수 서명과 버전을 고정한 0.25.2 구현은 기본 정규화를 L2-Hys로 둡니다. 문서 Notes의 L1 설명과 충돌하므로 기본값은 서명과 실제 정규화 호출 경로로 확인했습니다. 제곱근 보정인 transform_sqrt=True 는 별도 선택이며 음수 입력에는 사용하지 않습니다.

HOG와 헷갈리는 용어는 무엇이 다른가요?

SIFT와의 차이

SIFT는 여러 스케일에서 특징점을 찾고 각 점의 주방향에 맞춰 국소 기술자를 만듭니다. 이 글의 HOG는 일정한 격자에서 위치별 형태를 조합하며 주방향 정렬을 기본으로 하지 않습니다. 사진 사이 점 대응과 창 안의 형태 표현은 별도 검색 의도입니다.

CNN·이미지 임베딩과의 차이

CNN은 필터 가중치를 학습해 유용한 특징을 찾습니다. HOG는 정한 계산 규칙으로 기울기 분포를 구합니다. 둘 다 숫자 표현을 만들지만 HOG가 언어와 연결된 의미 임베딩이거나 모든 이미지 의미를 보존하는 벡터인 것은 아닙니다.

객체 탐지·SVM과의 차이

객체 탐지는 무엇이 어디에 있는지 찾는 과제이고 SVM은 학습한 경계로 판정하는 모델입니다. HOG는 그 모델에 들어갈 특징입니다. 탐지 시스템에는 창의 이동·다중 크기 탐색·중복 후보 처리도 필요합니다.

비교 정리: HOG는 규칙 기반 형태 표현, CNN은 특징을 학습하는 신경망 구조, SVM은 분류 모델, 객체 탐지는 위치까지 찾는 작업입니다.

실전에서는 어디에 쓰이나요?

보행자 탐지의 전통적인 구성을 이해합니다

OpenCV HOGDescriptor는 특징 계산과 탐지 메서드를 따로 제공합니다. 학습한 사람 분류기와 여러 위치·크기의 탐색을 결합하면 후보 상자를 얻습니다. 기본 사람 검출기의 계수를 다른 종류의 물체 분류기로 그대로 취급하거나 상자 점수를 보정된 정답 확률로 읽지 않습니다.

작은 이미지 분류의 비교 후보로 씁니다

정해진 크기로 맞춘 손글씨나 형태 중심 이미지에서 HOG와 별도 분류기의 조합을 시험합니다. OpenCV 손글씨 예제처럼 기울기 보정과 구역 분할을 함께 바꾸면 전처리의 영향도 포함됩니다. 예제의 성능 수치를 새 업무의 보장치로 옮기지 않고 독립 자료에서 다시 평가합니다.

HOG를 적용할 때 어떤 순서로 확인하나요?

1. 입력 영역과 전처리를 고정합니다

이미지 전체를 분류할지 잘라낸 창을 비교할지 먼저 정합니다. 크기·종횡비·색상·픽셀 범위와 밝기 보정 규칙을 저장합니다. 비율을 무시한 강제 확대는 형태를 바꾸므로 학습 자료와 새 자료의 처리 경로를 맞춥니다.

2. 라이브러리별 설정과 길이를 점검합니다

scikit-image의 크기 튜플은 행·열 순서로 읽고 OpenCV의 Size는 너비·높이로 확인합니다. 셀·블록의 단위와 이동 간격도 대조합니다. OpenCV의 사전 학습된 검출기는 그 계수가 기대하는 설정과 연결하며, 서로 다른 라이브러리의 벡터를 길이만 보고 교환하지 않습니다.

3. 분류기 학습과 최종 평가를 분리합니다

같은 원본에서 잘라낸 비슷한 창이 훈련과 테스트 양쪽에 섞이지 않도록 나눕니다. 셀 크기·분류기·탐지 임계값은 검증 자료에서 고르고 최종 평가 자료는 남겨 둡니다. 특징의 시각화가 선명한 것과 분류 오류가 적은 것은 별도 결과입니다.

4. 실제 오류와 처리 비용을 함께 남깁니다

촬영 거리·회전·가림·배경별로 놓친 대상과 잘못 찾은 대상을 확인합니다. 탐지라면 위치와 중복 상자도 봅니다. 특징 계산 시간만이 아니라 여러 창 탐색·분류·후처리까지 포함한 지연과 메모리를 측정하고 실패 사례를 기록합니다.

사용할 때 무엇을 주의해야 하나요?

첫째, 회전·크기 불변성을 자동으로 기대하지 않습니다. 기본 격자 HOG는 물체의 회전과 크기가 바뀌면 방향·위치 분포가 달라집니다. 크기 피라미드 탐색이나 전처리를 추가해도 실제 촬영 조건의 검증은 필요합니다.

둘째, 정규화로 모든 조명 문제가 해결된다고 보지 않습니다. 강한 그림자·역광·흐림·낮은 해상도에서는 윤곽 정보가 손상됩니다. 사라진 획을 정규화가 되살려 주지는 않습니다.

셋째, 시각화를 판정 근거 전체로 쓰지 않습니다. 방향 반응 그림은 특징을 점검하는 도구입니다. 최종 분류기의 결정 이유나 사람의 신원을 확인한 결과로 해석하지 않습니다.

넷째, 사람 탐지의 성공을 안전 승인으로 바꾸지 않습니다. 가림과 낯선 환경의 미탐을 확인하고 사람에게 영향을 주는 조치는 추가 근거와 검토를 둡니다. 원본 이미지와 특징의 수집·보관 범위도 함께 관리합니다.

주의: HOG 벡터 생성, 분류 점수, 탐지 상자와 업무의 확정 판정은 서로 다른 결과입니다. 한 단계의 성공만으로 다음 단계의 정확성까지 주장하지 않습니다.

자주 묻는 질문

Q1. HOG는 딥러닝 모델인가요?

아닙니다. HOG 자체는 정한 규칙으로 이미지의 기울기 분포를 만드는 전통적 특징 추출 방법입니다. 뒤에 연결한 분류기는 라벨로 학습할 수 있으므로 전체 시스템의 학습 여부는 따로 확인합니다.

Q2. HOG를 계산하면 사람 상자도 바로 나오나요?

특징 계산만으로 상자가 생기지는 않습니다. 학습된 분류 계수, 위치·크기 탐색과 후보 처리를 결합한 탐지 경로에서 상자를 얻습니다. 같은 클래스의 compute와 detectMultiScale도 역할이 다릅니다.

Q3. orientations는 사물의 방향 개수인가요?

셀에서 밝기 기울기의 방향을 나누는 구간 수입니다. 사진에 있는 물체의 수나 물체가 바라보는 자세 라벨의 수가 아닙니다.

Q4. HOG는 SIFT처럼 회전에도 같은 값인가요?

이 글의 기본 HOG는 격자를 물체의 주방향으로 자동 회전 정렬하지 않습니다. 방향 구간과 공간 배치가 바뀌므로 회전한 입력에서 같은 값이라고 보장하지 않습니다.

Q5. L2-Hys의 모든 최종 값은 0.2 이하인가요?

0.2 제한은 중간 단계입니다. 제한한 뒤 다시 정규화하므로 최종 성분이 그보다 커질 수 있습니다. 이를 확률이나 최종 출력의 고정 상한으로 해석하지 않습니다.

Q6. 벡터 길이가 같으면 다른 구현도 바꿔 써도 되나요?

안 됩니다. 방향 처리·블록 정규화·채널 선택·연결 순서가 다르면 같은 칸의 뜻도 달라집니다. 저장한 전처리·HOG 설정·분류기를 함께 사용하고 교체 시 다시 검증합니다.

출처

마무리

HOG는 이미지의 작은 셀에서 밝기 변화의 방향을 모으고 겹치는 블록으로 정규화한 뒤 연결하는 형태 표현입니다. 특징 벡터와 분류·탐지를 구별하면 전통적인 이미지 AI의 처리 흐름과 설정표를 읽기 쉬워집니다.

감자나라ai님이 HOG를 검토한다면 입력 크기와 셀·블록·방향 구간부터 기록해 보세요. 같은 전처리와 분류기로 독립 자료를 평가하고, 회전·가림·조명별 오류와 전체 처리 시간을 함께 남기는 것이 출발점입니다.