감지(Detect), 인페인팅(Inpaint), 스타일 매칭 후 렌더링: 평면 이미지에서 레터링을 편집하는 개발자 모델

평면 이미지는 텍스트 노드를 포함하지 않습니다. 단지 글자처럼 보이는 픽셀들만 포함하고 있을 뿐입니다. 포스터, 메뉴 사진, 라벨, 스크린샷, 광고 내보내기 파일 등: 타이포그래피 레이어는 사라지고, 스타일 정보도 사라지며, 사용 가능한 유일한 API는 래스터(raster) 방식뿐입니다. 만약 누군가 대체할 문자를 입력하도록 하거나, 그 픽셀들이 붙여넣은 것처럼 보이지 않게 다른 글자로 변한다고 기대하는 기능을 선택하거나 구축한다면, 당신은 하나의 모델을 호출하는 것이 아닙니다. 여러 단계로 이루어진 스택(stack)을 실행하고 있는 것이며, 이 스택은 가장 취약한 단계에서 실패합니다.

마케팅 문구는 항상 같습니다. 사진을 업로드하고, 변경할 내용을 입력하면 소프트웨어가 기존 단어를 지우고 자연스럽게 어울리는 새로운 단어를 그려냅니다. 그 문구 속에는 여러 단계 간의 계약이 숨겨져 있습니다. 감지(Detection) 단계에서는 잘못된 획을 박스 처리할 수 있습니다. 빈 공간은 해당되지 않는 질감으로 채워질 수 있습니다. 스타일 읽기(Style read) 단계는 렌더러가 가지고 있지 않은 계열을 추측할 수 있습니다. 새로운 글리프(glyph)들은 흐릿하거나, 정렬이 맞지 않거나, 오타일 수 있습니다. 이 중 어느 하나만으로도 인간의 눈에 실패를 안겨줄 수 있으며, 인간의 눈만이 완성된 디자인에 있어 유일한 심사위원입니다.

여기에 그 문제에 대한 개발자 관점 분석을 제시합니다. 마치 인터페이스를 작성하기 전에 스케치하듯이 각 단계를 거쳐봅니다: 각 단계가 무엇을 소비하는지, 무엇을 출력해야 하는지, 그리고 잘못된 출력이 다음 호출을 어떻게 오염시키는지입니다. 그런 다음 제가 계획했지만 공개하지 않은 지표들을 포함하여 비교 검증 장치(comparison harness)를 작성합니다. 그 후 하나 이상의 단계를 주장하는 제품들의 매트릭스를 제시하고, 누가 어떤 기능을 호출해야 하는지 설명합니다. 저는 점수판을 붙이는 것이 아닙니다. 지표가 설계되었지만 계산되지 않은 부분에 대해서는 계획만 밝히고 수치는 비공개로 합니다.

실질적인 격차(practical gap)란 이미 데모를 출시해 본 사람이라면 의심하고 있을 만한 것입니다. 녹화된 데모는 평평한 색상 위에 깨끗한 단어를 골라내고, 교정 작업을 하기 전에 영상을 멈춥니다. 실제 작업은 가격, 날짜, 번역된 요리 이름, 또는 사진 속 슬로건일 수 있습니다. 데모와 실제 작업은 같은 기능이 아닙니다. 이들을 다른 테스트처럼 취급하지 않으면, 당신은 오직 데모 배포 환경에서만 작동하는 파이프라인을 승인하게 될 것입니다.

단계별 스택(The stack, stage by stage)

평면 이미지에서 레터링을 편집하는 것은 단일 작업이 아닙니다. 이 작업을 네 가지 쌓인 작업 — 감지 및 광학 문자 인식(OCR), 인페인팅(Inpaint), 스타일 매칭, 새 텍스트 렌더링 — 으로 취급해야 합니다. 왜냐하면 전체 결과물은 가장 약한 작업의 품질에 좌우되기 때문입니다. 제가 화이트보드에 그리고 싶은 데이터 흐름은 구현하기에 충분히 짧습니다:

입력 이미지 → 텍스트 감지 및 OCR → 글꼴 및 스타일 분석과 편집 마스크 → AI 콘텐츠 채우기(인페인팅) → 스타일을 유지하며 새 텍스트 렌더링 → 합성 → 편집된 이미지.

대부분의 주류 제품들은 인식, 채우기, 그리고 텍스트 업데이트를 하나의 형태로 엮어냅니다. 각 모듈의 성숙도와 그들이 각각 새로운 마스크나 문자열을 발명하는 대신 공유하는지가, 이 편집이 사람이 읽을 수 있는 사람과 접촉했을 때 살아남을지 결정합니다. 자신의 입력을 명명할 수 없는 단계는 단계가 아닙니다. 그것은 희망이 붙은 프롬프트일 뿐입니다.

제가 실제로 코딩할 계약은 다음과 같습니다. 실행 과정을 디버깅하려면 이 필드들 중 어느 것도 선택 사항이 아닙니다.

Box:
  quad
  raw_string
...

operation은 대체(replacement) 또는 삭제(deletion) 둘 중 하나입니다. 삭제는 채우기 후에 멈춥니다. 대체는 렌더러로 계속 진행됩니다. 만약 귀하의 제품이 이 모든 것을 하나의 프롬프트 문자열로 무너뜨린다면, 작업들을 제거한 것이 아닙니다. 단지 유닛 테스트를 불가능하게 만든 것일 뿐입니다.

스키마 옆에는 두 번째 계약이 있습니다: 소스 바이트는 변경할 수 없습니다(immutable). 편집된 래스터 이미지는 새로운 객체로 작성해야 합니다. 나중에 패스가 추측하는 것을 알아내기 위해 박스, 마스크, 그리고 대상 문자열을 사이드카(sidecar)에 보관하십시오.

결과가 잘못되어 보일 때, 어떤 필드가 잘못되었는지 알고 싶습니다. 단 하나의 평면화된 PNG와 어깨를 으쓱하는 것만으로는 알 수 없습니다.

감지 및 OCR

첫 번째 작업은 영역을 찾고 내용을 읽는 것입니다. 현대적인 인식 기술은 딥러닝(deep learning)을 결합하며, 일반적으로 컨볼루션 프런트 엔드(convolutional front end)와 LSTM 시퀀스 모델(LSTM sequence model)로 구성되거나, 비전 특징(vision features)과 문자 순서(character order)를 동일하게 분리하는 후속 모델이 사용됩니다. 깨끗한 배경의 인쇄된 글자는 견고합니다. 하지만 저해상도, 작은 폰트, 필기체, 복잡한 배경에서는 취약합니다. 이것은 각주가 아닙니다. 정확한 감지(detection)가 기반입니다. 박스나 문자열을 잘못 잡으면 모든 다운스트림 작업이 렌더링 버그처럼 보이는 방식으로 실패합니다.

무엇을 저장할지 생각해 보세요. 회전된 간판이나 곡면 병에 있는 단어에는 축 정렬 직사각형(axis-aligned rectangle)이라는 원시 데이터(primitive)가 적절하지 않습니다. 이 직사각형은 배경을 포함하고 글리프 모서리를 놓치기 때문에, 채우기 모델(fill model)이 실행되기 전에 마스크 자체가 오염됩니다. 사각형(quad)이나 스트로크 주변의 더 좁은 폴리곤(polygon)이 정확한 기하학적 형태입니다. 여러 줄 그룹화도 중요합니다. 색상이 같은 헤드라인과 서브라인이 하나의 문자열인 것은 아니며, 둘을 감싸는 단일 박스는 렌더러에게 제목 영역에 문단을 그리라고 요청하게 됩니다.

신뢰도(Confidence)는 장식이 아니라 게이트입니다. 독자가 확신하지 못하면, 인터페이스는 원본 문자열을 보여주고 누군가 인페인팅(inpainting)하기 전에 사람이 수정할 수 있도록 해야 합니다. 여기서 조용한 실패(silent failure)는 비용이 많이 듭니다. 사용자가 모델이 잘못 읽은 단어를 '수정'하면, 채우기가 실제 단어를 지우고, 렌더러가 아름다운 폰트로 틀린 수정을 충실히 그려냅니다. 전용 편집기는 사람이 하나를 선택하여 직접 편집할 수 있도록 영역을 자동 박싱(auto-boxing)하는 것부터 시작합니다. 이것이 올바른 제품 형태입니다. 감지는 제안하고, 인간이 폐기합니다. 확인 단계 없이 완전히 자동화된 박싱은 자신만만하지만 틀린 도구를 출시하는 방법입니다.

저해상도는 작은 폰트와는 다른 종류의 실패입니다. 높은 래스터 해상도에서 작은 폰트는 여전히 충분한 피셀(pixels)을 가질 수 있습니다. 하지만 길 건너편에서 촬영된 후 압축된 일반적인 폰트는 그렇지 못합니다. 복잡한 배경은 작품의 가장자리가 스트로크(strokes)의 가장자리와 경쟁하기 때문에 디텍터(detector)와 리더(reader) 모두를 망가뜨립니다. 필기체는 타이프(type)에 대해 학습된 리더 내부의 언어 모델을 무너뜨립니다. 이 모든 것이 확인 단계(confirm step)를 건너뛸 이유가 될 수는 없습니다. 오히려 이런 것들이 바로 확인 단계가 존재하는 이유입니다.

이 상자 안에는 제품 결정(product decision)도 숨겨져 있습니다. 사용자에게 감지된 부분만 편집하게 할 것인가, 아니면 디텍터가 놓친 추가 영역을 칠할 수 있게 할 것인가? 후자의 경로가 필수적입니다. 디텍터는 역방향의 타이프, 그림자 속의 타이프, 그리고 그 뒤 배경의 그라데이션과 같은 색상의 타이프를 놓칩니다. 수동 상자가 없는 파이프라인은 복구할 수 없는 파이프라인입니다. 오직 수동 상자만 있고 절대로 제안하지 않는 파이프라인은 분할(segmentation) 문제를 모든 사용자에게 떠넘기는 것이며, 이것이 또 다른 실패 모드입니다. 당신은 둘 다를 원합니다: 즉, 제안과 추가하거나 뺄 수 있는 브러시입니다.

사용자에게 보여주는 문자열은 지울 문자열이어야 합니다. 나중에 두 번째의 비밀스러운 인식 패스(recognition pass)를 실행하여 다른 글리프(glyphs) 세트를 지우지 마십시오. 저는 다른 문서 도구에서 그러한 종류의 버그를 본 적이 있습니다: 미리보기는 한 가지를 말하고, 마스크는 다른 가설로 구축되었으며, 두 가설이 문자 하나 차이로 의견 불일치를 보여서 남은 스트로크가 남아 있는 경우입니다. 가설을 고정하십시오(Pin). 이를 영속화시키십시오(Persist). 그리고 그것을 지우십시오.

구멍 인페인팅(Inpaint the hole)

마스크가 존재하면, 글리프(glyphs) 뒤에 있던 픽셀들을 무언가가 만들어내야 합니다. PatchMatch와 같은 구식 인페인팅(inpainting)은 가장 가까운 이웃 검색(nearest-neighbor search)을 통해 주변 패치(patches)를 복사합니다. 이는 빠르고, 주변 환경이 정지 상태일 때—평평한 벽, 단순한 그라디언트, 반복되는 직조 패턴 등—는 괜찮아 보입니다. 하지만 구멍이 크거나, 질감이 정지 상태가 아니거나, 조명 변화(lighting falloff)가 단어를 가로지를 때는 실패합니다. 복사된 패치들이 타일처럼 배열되고, 조명이 깨지며, 여전히 오래된 단어의 형태를 흉터처럼 읽을 수 있습니다.

이러한 예시 기반 방법들(exemplar methods)은 주변 마스크되지 않은 컨텍스트(unmasked context)에 조건화되어 조명과 질감을 연속적으로 유지하려고 시도하는 생성 모델(generative models), 즉 확산 기반(diffusion-based) 또는 GAN 기반 모델로 대체되었습니다. 이는 사진에는 정말 큰 업그레이드입니다. 또한 잘못될 수도 있는 새로운 방식이기도 합니다. 생성 채우기(generative fill)는 원래 없었던 그럴듯한 벽돌 패턴을 만들어내거나, 빛을 굴절시키는 방식으로 구멍 너머의 하이라이트를 이어갈 수 있습니다. 레터링 제거의 경우, '그럴듯함'은 사양이 아닙니다. 사양은 '잉크가 사라진 채 이미 존재했던 표면'입니다.

마스크 두께는 기본적으로 잊어버리는 것이 아니라 엔지니어링 매개변수(engineering parameter)입니다. 너무 타이트하면 후광(halo)이나 부분적인 스트로크가 남습니다. 다음 단계에서는 이 후광을 샘플링하여 스타일의 일부로 취급해야 합니다. 너무 느슨하면 채우기가 로고 가장자리, 얼굴, 규칙선 또는 유지하고자 했던 인접한 단어를 먹어버립니다. 의도적으로 팽창(dilate) 및 부드럽게 처리(feather)하고 사용한 커널(kernel)을 기록하세요. 제거 데모는 종종 이 단계를 주변 환경을 읽고 글리프 뒤에 놓여 있던 모든 것을 재구축하는 것으로 설명합니다. 이러한 설명은 구현이 패치 복사라기보다는 잠재 채우기(latent fill)일지라도 올바른 정신적 모델입니다. 결과물을 구멍이 '창의적인지' 여부가 아니라, 사람이 이전 기준선(baseline)을 찾을 수 있는지로 판단해야 합니다.

조명 그라디언트와 질감은 이 단계가 빛을 발하거나 포기하는 지점입니다. 주름진 천 위의 단어든, 잎사귀 위의 단어든, 크롬 가장자리의 단어든: 조건부 모델(conditional model)은 글자 모양의 구멍을 통해 반복되지 않는 신호를 이어가야 합니다. 글자 모양의 구멍은 적대적입니다. 얇고, 고주파 경계(high-frequency boundaries)를 가지며, 당신이 관찰했기를 바랐던 바로 그 신호 위에 놓여 있습니다. 자국(scars)을 예상해야 합니다. 평평하게 인쇄된 종이는 이러한 영웅적인 작업을 요구하지 않기 때문에 많은 데모가 이를 선택합니다.

단순히 삭제만 한다면, 성공적인 채우기(fill) 후에는 끝납니다. 하지만 대체(replace)하는 경우, 그 채우기는 중간 단계일 뿐 최종 결과물이 아닙니다. 렌더러(renderer)가 기반을 삼을 수 있는 표면을 남겨야 합니다. 여전히 유령의 획(ghost strokes)을 포함하고 있는 채우기는 안티앨리어싱된 글리프(glyphs)를 통해 비쳐 보일 것입니다. 국소 노이즈 프로파일(local noise profile)을 변경한 채우기는 폰트가 정확하더라도 새로운 단어를 스티커처럼 보이게 만듭니다. 새 단어를 보기 전에 구멍을 보세요. 최종 합성 결과물만 캡처하는 개발자들은 잘못된 단계를 디버깅합니다.

또 하나의 구현 참고 사항입니다. 재압축된 미리보기(recompressed preview)가 아닌 원본 픽셀에 채우기 작업을 실행하세요. 마스크 경계(mask boundary)를 따라 발생하는 압축 블록은 모델이 신뢰하는 컨텍스트의 일부가 됩니다. 만약 UI에서 작은 프록시(proxy)를 보여주고 서버가 전체 래스터(raster)로 채운다면, 사이드카(sidecar)에 두 크기를 모두 기록하세요. 그렇지 않으면 단지 프록시 아티팩트였던 버그를 '수정'하게 될 것입니다. 클라이언트가 업로드하기 위해 다운스케일링하고 서버가 글자의 기둥(stems)을 전혀 보지 못하는 경우에도 같은 규칙이 적용됩니다. 이미 버린 디테일은 인페인팅할 수 없습니다. 전체 프레임을 무작정 다운스케일링하는 것보다 영역 크롭(crop of the region)과 컨텍스트 링(ring of context)을 선호하고, 합성이 원래 그리드에 놓이도록 크롭 좌표를 유지하세요.

그리기 전에 스타일 일치시키기 (Match style before you draw)

새로운 레터링은 원본의 서체(typeface), 색상, 그림자, 획(stroke), 왜곡(distortion)과 일치해야 합니다. 이것은 채우기(fill)의 부작용이 아니라 별도의 단계입니다. 사용자가 방금 입력한 문자열에 스타일을 적용하기 위해 단어의 내용물과 스타일을 분리하려고 시도하는 것입니다. 만약 이 분리 과정을 건너뛰면, 렌더러는 기본 글꼴을 사용하거나 생성 모델(generative model)에게 글꼴을 기억하도록 요청하게 되는데, 생성 모델은 글꼴을 기억하는 데 취약합니다.

Meta Research의 TextStyleBrush는 단일 예시에서 텍스트 스타일—글꼴, 획 두께, 왜곡—을 추출하여 새로운 콘텐츠에 적용합니다. 이것이 바로 원샷(one-shot) 스타일 변환입니다. 이는 테스트에서의 제품이라기보다는 연구 프로토타입이지만, 내용물은 하나의 벡터로, 외관(appearance)은 다른 벡터로 분리된다는 것이 실제로 가능하다는 것을 보여줍니다. 상용 도구들은 유사한 계열(family), 크기, 색상을 위한 내장 글꼴 일치 기능으로 이 분리를 근사합니다. 예를 들어 Clipfly 같은 서비스는 동일한 글꼴 형식으로 레터링 편집을 광고합니다. '근사'라는 단어가 적절합니다. 라이브러리에 대한 일치는 사용자 정의 로고 윤곽선, 왜곡된 기준선(warped baseline), 또는 손으로 그린 터미널과 같은 것을 재현하는 셰이더(shader)와는 다릅니다.

렌더러가 단순하고 예측 가능하게 작동하도록 하려면, 스타일 단계에서 다음 항목들을 반드시 출력해야 합니다:

• 실제로 래스터화(rasterize)할 수 있는 글꼴에 매핑되는 계열 추측값과, 이 추측값이 약할 때를 알리는 플래그.
• 축 정렬 상자(axis-aligned box)가 높이를 부풀리게 하는 것이 아니라, 사각형(quad) 위에서 측정된 픽셀 크기.
• 글리프(glyph)에서 샘플링한 채우기 색상과 선택적 획. (잊어버린 희미한 테두리(halo)가 아닌).
• 설명 자체가 '없음(none)'일지라도 그림자 또는 돌출(extrusion)에 대한 설명.
• 사라지는 간판 위의 단어가 정면 스티커처럼 보이지 않도록, 사각형에서 매핑된 왜곡 또는 원근법 정보.