한국의 개발자들을 위한 Google for Developers 국문 블로그입니다.
원본에서 더욱 빠른 AMP: AMP + SSR = ⚡
2019년 9월 11일 수요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Webtech GDE)님이 참여해 주셨습니다>
AMP는 현재 AMP 페이지를 훨씬 더 빠르게 로드할 수 있게 AMP 페이지에 적용할 수 있는 서버사이드 렌더링(SSR) 기법을 공식적으로 지원합니다. 우리의 테스트 결과, 유명한
FCP 측정항목
에서 최대 50%라는 엄청난 속도 증가를 보여줍니다. Google AMP Cache는 한동안 이 기법을 활용해왔지만, 이제는 개발자가 자신의 도메인에서도 이 기법을 사용할 수 있습니다! 주요 사이트 환경을 제공하기 위해 AMP를 사용 중이라면, 이 추가적인 최적화 프로그램의 설치가 특히 중요합니다. AMP 페이지와 비 AMP 페이지가 있는 '페어링된 AMP 설정'을 사용 중이라 할지라도, 사용자가 Twitter 앱을 사용하는 것과 같이 AMP Cache가 사용되지 않는 경우에 이 기법으로 사용자를 위한 최적의 성능을 보장할 수 있습니다.
SSR
은 React 또는 Vue.js와 같은 클라이언트측 페이지를 렌더링하는 프레임워크를 위한 FCP(first-contentful-paint) 시간을 개선하기 위한 기법입니다. 클라이언트측 렌더링의 단점은 페이지 렌더링에 필요한 모든 자바스크립트를 먼저 다운로드해야 한다는 점입니다. 그래서 사용자가 페이지의 실제 콘텐츠를 볼 수 있을 때까지의 시간이 지연됩니다. 이 문제를 완화하기 위해, React와 Vue.js는 둘 다 탐색 요청 시 서버에서 DOM을 사전에 렌더링하도록 지원합니다. 그러면 클라이언트측 자바스크립트가 렌더링을 픽업하는데, 이는 (리)하이드레이션이라는 프로세스입니다. 결과적으로 사용자는 콘텐츠를 훨씬 더 빠르게 볼 수 있게 됩니다.
AMP SSR은
AMP 보일러플레이트 코드
를 제거하고 서버에서 페이지 레이아웃을 렌더링하는 방식으로 작동합니다. AMP 보일러플레이트 코드가 존재하는 목적은 페이지 로드 시 콘텐츠 점프를 방지하기 위해서입니다. 이 코드는 AMP 프레임워크가 다운로드되고 페이지 레이아웃이 확정될 때까지 페이지 콘텐츠를 숨깁니다. 따라서 AMP 페이지는 다른 클라이언트측 프레임워크와 똑같은 문제, 즉 자바스크립트를 다운로드할 때까지 렌더링이 차단되는 문제를 겪게 됩니다. 보일러플레이트 코드를 제거하면 AMP SSR의
FCP 시간이 50% 더 빨라집니다
. 다음은 AMP 파일과 그 파일의 SSR 버전이 어떻게 다른지 비교한 내용입니다(자세한 설명을 보려면
공식 가이드
참조).
html 요소에서 변환된 속성을 통해 서버측에서 렌더링된 AMP 페이지를 식별할 수 있습니다.
<html amp transformed="self;v=1">
주: AMP 캐시는 자체 플래그를 설정하는데, 예컨대 Google AMP Cache에서는 다음을 추가합니다.
<html amp transformed="google;v=1">
이 속성이 설정되면 유효성 검사기가 SSR 처리된 AMP를 유효한 AMP로 취급합니다. SSR 처리된 AMP 최적화는 AMP 사양의 규칙을 위반하므로 문서를 무효화하며, 이것이 바로 이 새로운 플래그로 이 사례를 표시해야 하는 이유입니다. 플래그와 최적화가 모두 적용된 문서는 유효한 것으로 간주되어 계속 진행해도 좋습니다.
AMP SSR에 대해 자세히 알아보려면
AMP 채널의 설명 동영상
을 시청하거나
AMP SSR 가이드
를 읽어보세요.
AMP의 SSR 처리 방법은?
SSR 처리된 AMP를 수동으로 작성한다는 건 말이 안 됩니다. 대신에, 컴파일러가 하는 일과 마찬가지로 AMP 파일을 SSR 버전으로 자동으로 변환하는 도구를 사용합니다. 사용자가 문서를 요청하기 전에 미리 이런 변환이 이루어지는 것이 이상적일 것입니다. 하지만 요청 시 변환을 실행할 수도 있습니다(변환 작업을 반복해서 계속 실행하지 않도록 결과를 캐시해야 함).
현재는 AMP SSR을 위해 사용 가능한 도구는 다음 두 가지입니다.
AMP Optimizer
: 최적화된 AMP를 생성하기 위한 NodeJs 라이브러리.
Express
로 사이트를 구동하는 경우
express 미들웨어
에 관심이 있으실 수도 있습니다.
AMP Packager
:
Signed Exchange
제공과 함께 유용한 go 명령줄 도구.
주: 이러한 도구는 SSR을 수행할 뿐 아니라, AMP 프레임워크 미리 로드, 헤드 재정렬 등의
다른 최적화
도 수행합니다.
Next.js 지원
최신 Next.js 9 릴리스
가 별도 구성 없이 AMP SSR을 기본적으로 지원한다는 점이 무척 기대됩니다. Next.js 9은 현재 AMP 우선 페이지와 하이브리드 AMP 페이지에 대해 기본적으로 최적화된 AMP를 렌더링합니다. 따라서 Next.js는 AMP 페이지를 빌드하기 위한 훌륭한 선택입니다.
다음 단계는?
우리는 앞으로 두 가지 큰 추진 과제를 계획해두고 있습니다.
1.
AMP 프레임워크(v0.js)를 자체 호스팅하기 위한 옵션. 예, 맞습니다. 더는 cdn.ampproject.org에서 AMP를 다운로드할 요가 없을 것입니다. 이는 다음과 같은 두 가지 장점을 지니게 될 것입니다.
더 빠른 상호작용:
AMP 프레임워크를 다운로드할 때 cdn.ampproject.org에 대한 HTTPS 연결을 하나 더 설정할 필요가 없어지게 됩니다.
더 쉬운 QA:
새 AMP 릴리스로 전환하고 싶은 시점을 제어할 수 있습니다.
하지만
개인정보 보호상의 이유로
, AMP 캐시는 캐시된 AMP 페이지를 제공할 때 캐시 원본과 일치하도록 AMP 스크립트 URL을 다시 쓴다는 점을 유념하세요.
2.
WordPress 통합: 공식 AMP wordpress 플러그인 v1.3에서는 AMP SSR을 기본적으로 지원합니다.
모든 이를 위한 AMP SSR
AMP 페이지를 게시할 경우 서버측에서 렌더링된 AMP 페이지를 게시해야 합니다. HTML 또는 CSS의 축소와 유사하게,
AMP Optimizer
또는
Go 변환기
의 실행이 빌드/렌더링 체인의 정상적인 한 부분이어야 합니다. 렌더링 성능의 개선으로 FCP 시간에 큰 차이가 생기지만, 더욱 중요한 점은 사용자 환경의 차이입니다.
게시자: Sebastian Benz, Google 디벨로퍼 어드보케이트
기다리는 시간을 더 가치있게 만들기 : 새로운 AMP 로딩 표시기
2019년 9월 9일 월요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 조은(Webtech GDE)님이 참여해 주셨습니다>
게시자: Andrew Watterson, Google AMP Project 제품 디자이너
이 게시물은 AMP 디자인 팀에서 작성한 글입니다.
우리는 AMP 컴포넌트와 전체적인 사용 환경을 유용하고 액세스하기 쉽고 세련되게 만들 책임이 있는 제품 디자이너와 연구자로 구성된 팀입니다. 우리가 어떤 일을 하고 어떤 성과물을 내놓고 있는지 확인하려면
GitHub
또는
Contributor Slack
에서 UI 및 접근성 작업 그룹과 진행하는 다양한 활동을 살펴보세요.
AMP가 웹 사용자의 일상적 사용 환경을 개선하는 가장 중요한 방법 중 하나는 개발자가
빠르게
작동하는 사이트를 만들도록 돕는 일입니다. AMP만 가지고 있는 장점은 한상 무대 뒤에서 개선하고 있다는 점입니다. 우리는 개발자가 따로 어떤 일도 할 필요 없이 AMP를 사용하는 사이트에 속도 개선 사항을 적용할 수 있습니다.
성능 모범 사례는 항상 AMP의 모든 측면에 적용되어있지만,
실제 속도
는 전체 이야기의 절반에 불과합니다. 엔지니어가 기술적인 세부 사항을 계속 열심히 다루는 동안, 우리 디자인팀에서는
인지 속도
를 개선하는 작업에 착수합니다. 기다림이란 늘 우리 인생의 한 부분이겠지만, AMP 엔지니어들이 우리가 제어할 수 없는 부분(예:
Facebook 게시물
또는
YouTube 동영상
) 이거나 그냥 용량이 큰 경우 AMP 페이지 내에서 더 빠르게 만들 수 없습니다. 하지만
많은 증거
를 통해 사용 환경에 따라 기다려야 하는 상황에 대한
느낌
이 달라진다는 점이 분명히 드러납니다. AMP 페이지를 어느정도 사용해보셨다면 2015년부터 AMP가 사용한 로딩 표시기에 익숙할 것입니다.
오늘부터 우리는 새 로딩 표시기를 사용합니다.
우리가 어떻게 여기까지 왔는지 말씀드리겠습니다. 우리는 다음 세 가지 목표를 정하고 시작했습니다.
더 빠르게 로딩되는 느낌이 들게 한다.
무슨 내용이 표시될지 독자가 알도록 한다.
2016년 이후로 AMP 페이지에 표시할 광고에는 다른 로딩 표시기를 사용해왔으므로, 사람들은 광고를 주 콘텐츠와 즉시 구분할 수 있습니다. 우리는 동영상, 트윗, Facebook 게시물 등, 더 많은 유형의 콘텐츠에 이러한 로딩 표시기를 확장하고 싶었습니다. 이는 예컨데 인내심을 가지고 동영상이 로드되기만을 기다렸는데, 결국 동영상을 시청할 수 없는 상황이 벌어지지 않도록 하려는 것이었습니다.
디자인을 현대화한다
. 이 목표에 대해서는 숫자로 정량화할 수 없지만, AMP 팀의 많은 사람이 우리가 쓰던 로더를 시각적으로 더 세련되게 만들 수 있으리라 느꼈습니다.
우리는 디자인을 세련될 뿐 아니라 중립적으로 유지할 필요도 있었습니다. AMP와 함께 제공되는 UI는 어떤 AMP 페이지의 디자인과도 잘 어울려야 합니다. 즉, 극적 표현력을 살린 색이나 너무 튀는 스타일은 지양해야 한다는 뜻입니다.
우리는 일정 시간 후 콘텐츠가 '로드'될 것임을 표시하는 10가지 종류의 로딩 표시기 디자인에 대한 프로토타입을 만들어 2,500명의 웹 사용자를 대상으로 로드 시간이 얼마나 걸릴 것 같은지 예측해 보라는 질문을 던졌습니다. 사람은 무척 짧은 시간을 추정하는 데는 능숙하지 못하므로, 예측의 정확도가 중요한 게 아니라 그 추세가 중요했습니다. 참가자들은 기존의 AMP 로딩 표시기나 기본적인 스피너와 같은 종래의 옵션에 비해 우리가 새로 디자인해서 선보인 몇몇 프로토타입을 보고서는 거의 1초 정도 로딩 시간이 덜 걸릴 것으로 예측했습니다. 우리는 이 데이터와 디자인 과정에서 큰 관심을 끌었던 몇몇 관찰 사항을 바탕으로 한 가지 디자인을 골랐습니다.
우리는 다음 세 가지 원칙에 이르렀습니다.
때로는 로더가 없는 게 더 낫다.
사용자는 자신이 기다리고 있다는 걸 미처 깨닫기 전에 로더를 표시하면 오히려 사용자의 주의를 흩트리면서 사이트의 작동 속도가 느린 것처럼 보이게 만들 수 있습니다.
흥미로움을 유지한다.
이미 백만 번도 넘게 봤을 법한 똑같은 스피너를 반복해서 봐야 하는 상황은 페이지가 로딩되기를 기다리는 사용자에게 도움이 되지 않습니다.
일관성을 유지한다.
한 페이지에 각각 고유한 디자인과 타이밍을 가진 여러 항목을 로드하면 주의가 분산되고 너저분해 보입니다.
우리는 마지막 원칙을 충족시키기 위해 다양한 크기, 콘텐츠형 아이콘, 배경에 맞춰 디자인을 조정할 수 있도록 했습니다. 첫 번째와 두 번째 원칙의 경우, 여러 단계에 걸쳐 로더를 애니메이션으로 제공함으로써 충족시켰습니다. 즉, 처음에는 아무 것도 표시되지 않다가 중간에 애니메이션을 하나 보여준 다음, 마지막으로는 콘텐츠가 로드될 때까지 루프를 이루며 회전하는 스피너를 표시하는 것으로 마무리합니다. 따라서 콘텐츠 로드 시간이 0.5초 미만일 때는 로더가 전혀 표시되지 않고, 로드 시간이 3.5초를 꽉 채우지 않는 한 스피너는 반복하지 않습니다.
우리의 디자인은 세 가지 목표를 모두 만족시켰습니다. 즉, 인지 속도에 관해 고무적인 데이터를 얻었고, 디자인이 더욱 세련되게 바뀌었다고 확신하며, 독자가 무슨 내용이 표시될지 알 수 있도록 개선했습니다.
개발자를 위한 AMP의 유연성 유지를 위해 해결해야 할 몇 가지 추가적인 세부 사항이 있었습니다. 우리는 콘텐츠가 로드되기 전에 새로운 디자인 자리표시자 이미지, 메시지 또는 맞춤 로딩 표시기를 표시하는 AMP의 능력과 충돌하지 않도록 하고 싶었습니다. 단순한 자리표시자 이미지가 있는 콘텐츠의 경우, 우리는 여전히 표시될 내용이 더 있음을 독자에게 알리고 싶으므로 컬러 이미지로 눈에 잘 띄는 특별한 버전의 로딩 표시기를 화면에 띄울 것입니다. 메시지나 맞춤 로딩 표시기처럼, 그보다 더 복잡한 자리표시자의 경우에는 우리의 디자인이 개발자의 디자인과 충돌하지 않도록 기본 로더를 전혀 표시하지 않을 것입니다.
우리는 앞으로 몇 주에 걸쳐 AMP 페이지 중 몇 퍼센트에 대해서만 제한적으로 새로운 로딩 표시기를 제공하는 라이브 실험을 진행하면서, 사이트 성능 통계뿐 아니라
커뮤니티 의견
도 면밀히 주시하여 최종적으로 가다듬는 작업을 수행할 예정입니다. 우리의 목표는 이런 의견을 바탕으로 최종 확정된 새 로더를 모든 AMP 페이지의 모든 구성요소로 전개하는 것입니다.
새로운 디자인이 마음에 드시길 바라고, 한 번에 하나씩 작고 세부적인 사항을 차근차근 개선할 수 있도록 웹의 사용자 환경을 향상하는 데 아낌없는 성원을 보내주시면 고맙겠습니다.
AutoML로 문서 태깅 구현하기
2019년 9월 4일 수요일
<블로그 원문은
이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 김택민(MachineLearning GDE)님이 참여해 주셨습니다>
기업에서 송장 처리, 애플리케이션 검토, 계약 분석 등의 작업을 지원하기 위해서는 사진, 문서, 메모 등 여러 유형의 컨텐츠를 디지털화하는 것이 선행되어야 합니다. Google Cloud에서는 고객이 컨텐츠를 디지털화할 수 있는 여러 방법을 제공합니다. 사전에 훈련된 머신러닝 API 를 사용할 수도 있고 AutoML Suite를 기반으로 Document Understanding AI를 적용할 수도 있습니다.
이번 글에서는 문서 처리를 목적으로 하는 Cloud AutoML 기반의 문서 태깅 (Document Tagging)에 대해서 알아보겠습니다. 문서 태깅은 문서에서 의미를 가지는 응답(혹은 값)이나 고객, 계좌 번호, 총액 등과 같은 필드(또는 태그)를 뽑아내어 키-값의 쌍의 형태로 구성하는 것을 의미합니다. 여기서 ‘태그’란 분석하고자 하는 항목이고 ‘값’은 그 태그에 대응하는 실제 결과입니다. 아래 예제를 통해 AutoML을 사용하여 문서 형태의 이미지에서 서명, 도장, 사각형 영역 등 문서 처리에 필요한 주요 정보를 뽑아보겠습니다.
기존의 솔루션
몇 년 전까지만 하더라도 문서를 디지털화한다는 것은 단순히 문서를 스캔하여 클라우드에 이미지 형태로 저장한다는 의미였습니다. 현재는 더 나은 도구와 기법들 특히, 머신러닝 덕분에 서류 뭉치들을 분석 가능한 구조적 데이터로 변환하고 이로부터 유용한 정보를 얻어낼 수 있습니다.
최근까지는 사전에 정의된 문서에 대해서만 정규 표현식이나 OCR 과 같은 규칙 기반 (rule-based)의 알고리즘을 사용하여 문서를 디지털화할 수 있었습니다. 새로운 형식의 문서에 대해서는 적용하기 어려울 수도 있고 키워드 매칭이나 텍스트 기반 NLP 모델에서 문제가 될 수도 있습니다. 물체 인식 (Object Detection) 및 개체 인식 (Entity Recognition)은 지난 몇 년간 많은 주목을 받았으며 이 분야에서 상당한 개선을 이루었습니다. Cloud AutoML이라고 불리는 AI 서비스 집합은 최소한의 머신러닝 지식만 가지고도 고객에게 고품질의 머신러닝 모델을 제공할 수 있습니다.
GCP 솔루션: 대규모의 AutoML
고유한 비즈니스 문제를 해결하는 모델을 만들기 위한 토대로 삼을 수 있는
폭넓고 다양한
AutoML 서비스가 있습니다. 예를 들어, 문서 디지털화의 경우 아래와 같은 구조를 가집니다.
이런 형태의 구조는 쉽게 이해할 수 있을 뿐만 아니라 프로덕션 환경에 배포하기도 쉽습니다. 모든 구성 요소는 확장 가능하고 서버리스 (serverless) 형태이며, 기존 GCP를 기반으로 프러덕션 환경에서 사용 가능합니다.
태깅된 문서
—이미 주석 처리된 데이터가 없으면
AI Platform Data Labeling Service
를 사용할 수 있습니다.
OCR 및 객체 감지
—
Vision API
와 최근에 AutoML 제품군에 추가된
AutoML Vision Object Detection
으로 이 기능을 수행할 수 있습니다.
병합 및 특징 처리
—간단한 Jupyter 노트북이나 Python을 기반으로 컨테이너화된 솔루션을 사용하는 것처럼, 이 기능을 수행할 수 있는 여러 가지 다른 방법이 있습니다.
개체 인식
—최근에 AutoML 제품군에 추가된
AutoML Natural Language
의 새로운 기능인
개체 추출
을 사용하여 수행할 수 있는 기능입니다.
후처리
—특징 처리와 비슷한 방식으로 수행할 수 있는 기능입니다.
전체 파이프라인은 Cloud Composer를 사용하여 구성하거나 Google Kubernetes Engine(
GKE
)을 사용하여 배포할 수 있습니다. 하지만 일부 비즈니스 제약 조건 (예: GCP에 대한 맞춤설정 내부 데이터화 파이프라인 빌드, 법률 문서에서 규칙 추출, 문서에서 민감한 정보를 수정한 후 파싱 등)에서는 위에 언급한 아키텍처 외에 개발할 수 있는 추가 맞춤설정이 필요합니다. 이와 같은 요구 사항에 관한 자세한 내용과 지원은
판매팀
에 문의하실 수 있습니다.
값 생성
서로 다른 머신러닝 솔루션은 저마다의 비즈니스 혹은 기술적인 장점이 있고, 우리 고객 중 상당수가 이와 같은 솔루션을 사용하여 사용자 경험 개선, 운영 비용 절감, 전체 오류 감소 등의 다양한 목적을 달성해왔습니다. 이 글에서 설명하는 솔루션과 같이 의료, 금융 서비스 및 미디어 등 여러 분야에 적용될 수 있습니다. 예를 들어, 다음과 같은 사례들이 있습니다.
EHR (Electronic Health Records)에서 자동으로 지식 추출.
영수증에서 주요 키-값 쌍 생성.
금융 문서에서 필드 가져오기.
고객 불만 사항에 관한 텍스트 이해.
은행 수표, 전표 및 기타 데이터의 태그 지정.
다음 단계
딥러닝의 시대에는 전이 학습 (Transfer Learning)과 같이 훈련 과정을 간소화하는 방법이 점점 요구되고 있습니다. 이 글에서 소개한 문서 태그 지정도 수천 장의 이미지 없이도 문서를 디지털화할 수 있었으며 테스트를 거쳐 성공적으로 실무 환경에 배포되었습니다. 머신러닝 기반의 솔루션에서는 데이터 가변성은 여전히 중요한 요소이지만 AutoML은 자동적으로 기본적인 문제들을 해결해주고 수천 장 정도의 적은 이미지만 사용해서 모델을 훈련할 수 있습니다.
고객이 문서를 처리하도록 돕은 일은 전 세계의 정보를 정리하고 구성하여 누구든 손쉽게 접근하고 이를 유용하게 활용할 수 있도록 하겠다는 Google 사명에 완벽히 부합하는 일입니다. 이 글을 공유함으로써, 우리는 더 많은 조직에서 클라우드로의 전환을 고려하는 계기가 될 수 있으면 좋겠습니다. Cloud AutoML Vision, Cloud AutoML Natural Language, Cloud Storage와 같은 도구는 데이터셋을 구성하고 사용자 환경을 개선하는 데 도움이 될 수 있습니다.
이 글의 예제인 문서 태그 지정은 특정 문제에 대해 간단하고 대상이 정해진 문제입니다. 좀 더 다양하고 강력한 문서 처리 및 정보 추출 기술에 관해서는 Google의
Document Understanding AI
솔루션을 참고해주세요. AutoML은 파터사를 통해 솝쉽게 배포할 수 있고 별도의 머신러닝 지시기 없더라도 End-to-end Document Unerstanding AI 솔루션의 핵심 요소입니다.
당사
웹사이트
에서 더 자세히 알아보실 수 있습니다.
TensorFlow Lite로 Android에서 실시간으로 사람의 포즈를 추적해보세요
2019년 8월 30일 금요일
<
블로그 원문은 이곳
에서 확인하실 수 있으며 블로그 번역 리뷰는 강재욱(MachineLearning GDE)님이 참여해 주셨습니다>
게시자:
Eileen Mao
와
Tanjin Prity
, 2019년 하계 Google 엔지니어링 실습 인턴
PoseNet 모델
을 사용하여 Android에서 사람의 포즈 추정을 위한
TensorFlow Lite
샘플 애플리케이션을 발표했습니다. PoseNet은 주요 인체 부위의 위치를 감지하여 이미지나 동영상으로 부터 사람의 포즈를 추정하는 비전 모델입니다. 한 예로서, 이 모델은 이미지에서 사람의 팔꿈치 및/또는 무릎 위치를 추정할 수 있습니다. 포즈 추정 모델은 이미지에 나와 있는 사람이 누군지 식별하는 것이 아니라, 주요 인체 부위의 위치만 식별합니다.
TensorFlow Lite는 디바이스의 카메라를 활용하여 사람의 주요 인체 부위를 실시간으로 감지하고 표시하는 Android 샘플 애플리케이션을 제공합니다.
소스 코드
를 확인하세요!
이 모델이 흥미로운 이유는?
그것은 포즈 추정을 통해 수많은 어플리케이션의 가능성이 열리기 때문입니다. 몇 가지만 꼽자면, 개발자가 인체 이미지를 기반으로
현실을 증강
하고,
컴퓨터 그래픽 캐릭터를 애니메이션
으로 표현하고, 스포츠 선수의
특징적인 걸음걸이를 분석
할 수 있습니다. Google I/O’19에서 TensorFlow Lite는 사용자가 PoseNet 모델을 사용하여 춤추는 방법을 배우는 데 도움이 되는 앱인
Dance Like
를 선보인 바 있습니다.
앱 개발자와 머신러닝 전문가는 이 샘플 애플리케이션을 통해 가볍게 작동하는 모바일 모델의 가능성을 더욱 수월하게 탐구할 수 있을 것입니다.
PoseNet 샘플 애플리케이션
자바로 작성된 기존의 Android 예제와는 반대로,
PoseNet 샘플 앱
은 Kotlin으로 개발되었습니다. 이 앱의 개발 목표는 누구든 최소한의 오버헤드로 PoseNet 모델을 쉽게 사용할 수 있도록 하는 것입니다. 이 샘플 앱은 모델의 입출력에 대한 전후 처리를 담당하는 PoseNet 라이브러리를 포함합니다. 아래 다이어그램은 애플리케이션, PoseNet 라이브러리, TensorFlow Lite 라이브러리 간의 워크플로를 나타낸 것입니다.
PoseNet 앱 워크플로
PoseNet 라이브러리
PoseNet 라이브러리는 처리된 카메라 이미지를 선택하고 사람의 주요 인체 부위의 위치에 관한 정보를 반환하는 인터페이스를 제공합니다. 이 기능은 처리된 RGB 비트맵에서 TensorFlow Lite 인터프리터를 실행하고
Person
객체를 반환하는 메서드인
estimateSinglePose()
에 의해 제공됩니다.
이 페이지
에서는 PoseNet의 입력과 출력을 해석하는 방법을 설명합니다.
Person
클래스는 주요 인체 부위의 위치와 그와 관련된 신뢰도 점수를 함께 포함합니다. 어떤 사람의 신뢰도 점수는 각 주요 지점의 신뢰도 점수 평균으로, 이는 그 위치에 주요 지점이 존재할 확률을 나타냅니다.
각각의
KeyPoint
는 특정
BodyPart
의
Position
과 그 주요 지점의 신뢰도 점수에 관한 정보를 가지고 있습니다. 정의된 모든 주요 지점의 목록은
여기
에서 액세스할 수 있습니다.
PoseNet 샘플 앱
PoseNet
샘플 앱
은 카메라에서 프레임을 캡쳐하고 이미지에 주요 지점을 실시간으로 오버레이하는 온디바이스 카메라 앱입니다.
이 애플리케이션은 각각의 수신 카메라 이미지에 대해 다음 단계를 수행합니다.
카메라 미리보기에서 이미지 데이터를 캡처하여 YUV_420_888에서 ARGB_888 형식으로 변환합니다.
RGB 형식의 프레임 데이터에서 픽셀을 보유할 Bitmap 객체를 만듭니다. 모델로 전달할 수 있도록 Bitmap을 모델 입력 크기에 맞게 자르고 크기를 조정합니다.
PoseNet 라이브러리에서 estimateSinglePose() 함수를 호출하여 Person
객체를 가져옵니다.
Bitmap의 크기를 화면 크기에 맞춰 다시 조정합니다. Canvas 객체에 새 Bitmap을 그립니다.
Person 객체에서 얻은 주요 지점의 위치를 사용하여 캔버스에 골격을 그립니다. 기본적으로 0.2로 설정된 임계값 이상의 신뢰도 점수를 가진 주요 지점을 표시합니다.
포즈 렌더링을 카메라 프레임과 동기화하기 위해, 포즈와 카메라에 대해 별도의 View 인스턴스를 사용하는 대신 출력 표시를 위해 단일 SurfaceView를 사용했습니다. SurfaceView는 View 캔버스에서 가져오기, 잠금 및 그리기를 통해 지연 없이 화면에 표면을 배치하는 작업을 처리합니다.
온디바이스 실행
GitHub
에서 소스 코드를 다운로드하고 실행 방법에 관한 안내는
README
를 참조하여 앱을 사용해 보실 것을 권해 드립니다.
로드맵에서
우리는 앞으로 다음을 비롯하여 이 샘플 앱에 대해 더 많은 기능을 탐구해보고자 합니다.
다중 포즈 추정
GPU delegating를 사용한 GPU 가속
NNAPI delegating를 사용한 NNAPI 가속
모델의 훈련 후 양자화로 지연 시간 감소
ResNet PoseNet 모델과 같은 추가 모델 옵션
올 여름 PoseNet 샘플 앱을 개발하는 과정은 정말 즐거운 일이었습니다! 이 앱을 통해 온디바이스 머신러닝에 더욱 쉽게 접근할 수 있기를 바랍니다. 이 앱을 사용하실 경우 #TFLite, #TensorFlow, #PoweredByTF를 사용해 우리와 공유해 주세요.
감사의 말
Tensorflow Lite 소프트웨어 엔지니어로서 우리를 이끌어준
Nupur Garg
와
Pulkit Bhuwalka
, PoseNet 모델을 만든
Tyler Zhu
, 동료 인턴인
Pavel Senchanka
, Pixel Camera 소프트웨어 엔지니어인
Clément Julliard
그리고
TensorFlow Lite
팀에 특별히 감사드립니다.
Contents
ML/Tensorflow
Android
Flutter
Web/Chrome
Cloud
Google Play
Community
Game
Firebase
검색
Tag
인디게임페스티벌
정책 세미나
창구프로그램
AdMob
AI
Android
Android 12
Android 12L
Android 13
Android 14
Android Assistant
Android Auto
Android Games
Android Jetpack
Android Machine Learning
Android Privacy
Android Studio
Android TV
Android Wear
App Bundle
bootcamp
Business
Chrome
Cloud
Community
compose
Firebase
Flutter
Foldables
Game
gdg
GDSC
google
Google Developer Student Clubs
Google I/O
Google Play
Google Play Games
Interview
Jetpack
Jetpack Compose
kotlin
Large Screens
Library
ma
Material Design
Material You
ML/Tensorflow
mobile games
Now in Android
PC
Play Console
Policy
priva
wa
wear
Wearables
Web
Web/Chrome
Weeklyupdates
WorkManager
Archive
2026
8월
7월
6월
5월
4월
3월
2월
1월
2025
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2024
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2023
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2022
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2021
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2020
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2019
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2018
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2017
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2016
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2015
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2014
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2013
12월
11월
10월
9월
8월
7월
6월
5월
4월
3월
2월
1월
2012
12월
11월
10월
9월
8월
7월
6월
5월
3월
2월
1월
2011
12월
11월
Feed