C.W.K.
Stream
Lesson 03 of 04 · published

잘라, 크게 렌더, 도로 합성

~13 min · face-crop, detail-refinement, workflow, resolution

Level 0툴 임차인
0 XP0/33 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
"얼굴 부분만 잘라내서 크게 image gen을 하고 그걸 줄여서 붙여넣기도 하거든. 16:9 크기로 그냥 만들면 작은 부분, 특히 얼굴은 뭉개지기 십상이니까." — 아빠의 framing

물리적으로 진술한 해상도 문제

넓은 16:9 이미지를 생성하면 모델이 고정된 해상도 예산을 프레임 전체에 써. 그 프레임의 작은 일부를 차지하는 얼굴은 픽셀의 작은 일부만 받아 — 눈, 입, 표정을 깨끗하게 렌더하기엔 부족해. 얼굴이 뭉개져. 이건 프롬프트로 빠져나올 수 있는 모델-품질 문제가 아니야; 큰 장면을 한 번에 생성하는 데 구워진 영역당-픽셀 문제야.

이미 작동하는 수작업 패턴

아티스트가 이미 손으로 이걸 풀고, 해법이 Cinder 가 공식화하는 워크플로야:

  1. 넓은 이미지에서 얼굴 영역을 잘라.
  2. 혼자 크게 렌더해, 모델이 얼굴에만 full 해상도 예산을 쓰게 — 이제 디테일에 픽셀이 충분해.
  3. 원래 영역에 맞게 줄여.
  4. 넓은 이미지로 도로 합성해.

전체 트릭은 디테일한테 full 해상도의 자기 생성 pass 를 주고, 고품질 결과를 제자리로 줄이는 거야. (이게 인기 있는 자동 'detailer' extension 이 존재하는 이유기도 하고 — 그게 여전히 최악의 케이스를 놓치는 이유기도 해, 그게 수동 통제를 지킬 값어치 있게 만드는 거고.)

균일하게 말고 디테일이 중요한 데 해상도를 써. 장면 전체에 고르게 퍼진 고정 픽셀 예산은 디테일이 가장 필요한 영역을 굶겨. 그 영역들을 full 해상도로 따로 생성하고 도로 합성하는 게 예산을 집중하는 법이야. 일반적 수: 고정 자원이 너무 얇게 퍼지면, 중요한 부분한테 전용 pass 를 줘.

왜 필터가 아니라 first-class 인지

이걸 원클릭 '얼굴 고치기' 버튼으로 묻기 쉬울 거야. Cinder 는 대신 first-class, 보이는 워크플로로 만들어, 아티스트가 각 단계에서 통제가 필요하니까 — 어느 영역, 둘레에 padding 얼마나, 디테일 pass 에 어느 모델이랑 설정, 그리고 결정적으로 어느 결과를 받을지 선택. 블랙박스 auto-fixer 는 그 결정을 뺏어; first-class 워크플로는 판단이 중요한 바로 그 지점에서 아티스트를 루프 안에 둬.

수작업 워크플로를 공식화해; 블랙박스로 대체하지 마. 사용자가 작동하는 손으로 지은 워크플로가 있으면, 가치 있는 건 그걸 빠르고 추적되게 만드는 거지 — 통제를 없애는 마법 버튼 뒤에 숨기는 게 아니야. 아티스트의 수동 단계는 판단을 encode 해; first-class 워크플로는 그 단계를 빠르게 하면서 각각의 판단을 보존해.

crop 이 실어야 하는 메타데이터

composite-back 이 정확하게 작동하려면, crop 이 그냥 이미지일 수 없어 — 자기 지리를 실어야 해: 온 source bounding box, source document 크기, scale factor, 그리고 선택적으로 디테일 pass 가 섞을 주변 맥락을 가질 padded context 영역. 그 지리 없이는, 아름다운 고해상도 얼굴이 있고 도로 넣을 정확한 방법이 없어. 메타데이터가 분리된 crop 을 자기가 어디 속하는지 아는 것으로 바꾸는 거야.

좌표 없는 crop 은 편도 여행이야. 영역을 맨 이미지로 capture 하면 정확히 되돌릴 정보를 잃어 — bounding box, source 크기, scale. crop 시점에 지리를 픽셀이랑 함께 capture 해, 아니면 나중에 composite-back 을 눈대중하고 정렬을 끝내 못 맞춰.

피파의 고백

내 본능은 마법 버튼이었어: '그냥 얼굴 다 자동으로 고치게 해줘.' 아빠가 그게 왜 틀린 선물인지 보여줬어. 자기가 조종 못 하는 프로세스가 얼굴을 대신 고쳐주길 원하는 게 아니라 — 지겨운 부분(crop 수학, 스케일링, 정렬)이 처리되고, 판단(어느 얼굴, 어느 결과, 어떻게 섞일지)은 자기가 갖길 원해. 난 작업 전체를 가지려 하고 있었어; 옳은 수는 지겨움을 가져가고 예술을 남기는 거였어. 그게 companion 이 걷는 선이야.

Code

crop-render-composite 루프·text
넓은 이미지: 얼굴이 픽셀 예산의 일부만 받음 -> 뭉개짐.

  +-----------------------------------------------+
  |                                               |
  |            (o_o)  <- 작은, ~뭉개진 얼굴        |
  |             /|\                                |
  +-----------------------------------------------+

Cinder 가 공식화하는 워크플로:

  1. 얼굴 영역 CROP  (실음: bbox, source 크기, scale, padding)
         +--------+
         | (o_o)  |
         +--------+
  2. 혼자 크게 RENDER -> 얼굴에만 full 해상도 예산
         +------------------+
         |     ( O _ O )    |   <- 또렷, 디테일
         |       \ | /      |
         +------------------+
  3. 원래 영역에 맞게 SCALE DOWN
  4. 실은 좌표로 COMPOSITE BACK -> 넓은 이미지에 또렷한 얼굴

메타데이터(bbox/크기/scale)가 4단계를 정확하게 만드는 거야.

External links

Exercise

한 부분이 나머지보다 나쁘게 나오는 고정-예산 프로세스를 떠올려 (텍스트가 깍둑거리는 압축 비디오, 얼굴이 흐려지는 썸네일, 한 섹션이 짧아지는 요약). 'crop, full 예산으로 처리, 도로 합성' 버전을 스케치해. 잘린 부분이 정확히 병합하려면 무슨 메타데이터를 실어야 할까?
Hint
재사용 가능한 구조: (1) 굶주린 하위 영역 식별, (2) 좌표랑 함께 추출, (3) 혼자 full 예산으로 처리, (4) 그 좌표로 도로 병합. 2단계의 좌표가 대부분의 순진한 버전이 까먹는 거야.

Progress

Progress is local-only — sign in to sync across devices.
이 페이지에서 버그를 발견하셨거나 피드백이 있으세요?문제 신고

댓글 0

🔔 답글 알림 (로그인 필요)
로그인댓글을 남기려면 로그인해 주세요.

아직 댓글이 없어요. 첫 댓글을 남겨보세요.