생성 파이프라인 · 후처리 기록

무엇을 했고, 무엇을 되돌렸는가

FLUX.2 로 이미지를 만들고 학습 데이터로 만드는 전 과정입니다. 시도했다가 측정 결과로 폐기한 후처리도 그대로 남겼습니다 — 실패한 시도가 왜 실패했는지가 설계의 근거이기 때문입니다.

전체 흐름

1. 프롬프트 조립 — 클래스명에 카메라·맥락·조명·구도·화질 5개 축을 무작위 조합. 시드가 고정돼 있어 같은 목록을 언제든 재현하고, 클래스를 번갈아 돌아 중간에 멈춰도 클래스 균형이 유지됩니다.
2. 생성 — FLUX.2-dev(32B) + 텍스트 인코더 Mistral-24B(fp8 양자화), 1024×1024 / 20스텝 / guidance 4.0, 배치 2.
3. 후처리 — LANCZOS 로 256×256 축소 후 JPEG q95 저장. 1024px 원본 PNG 를 함께 보존해 후처리 방식을 바꿔도 재생성 없이 재처리 가능.
4. 학습 시 처리 — real 과 완전히 같은 경로: 정사각 중앙 크롭 → 256px → q95 → RAM 상주 → GPU 에서 RandomResizedCrop+flip. 해상도·압축·증강이 조건 간 동일해야 성능 격차를 데이터 탓으로 돌릴 수 있습니다.

현재 후처리는 축소와 저장뿐입니다. 아래는 그렇게 정착한 이유입니다.

해상도 후처리를 건드린 이유 — 두 파이프라인의 축소 배율이 다르다

학습에 쓰는 이미지는 real·합성 모두 256×256 JPEG q95 입니다. 겉보기 규격은 같지만 거기까지 오는 경로가 전혀 다릅니다.

1단계 — real 의 처리 이력을 실측 (추측 금지)

맞추려면 먼저 재야 합니다. ImageNet 원본 3,000장의 헤더와 파일 크기를 직접 읽었습니다 (scripts/17_measure_real.py).

해상도 분포

짧은 변 히스토그램(경계 200·256·320·375·400·450·500·600·800):

375~400 구간에 몰려 있습니다. ImageNet 이 수집 당시 리사이즈를 거친 흔적으로 보이며, 256px 학습 이미지의 실질 해상도 상한이 대략 372px이라는 뜻입니다.

압축 강도

2단계 — JPEG 품질을 역추정하려다 실패

합성에 같은 압축을 걸려면 real 의 품질값(q)을 알아야 합니다. JPEG 헤더의 양자화 테이블을 표준 테이블(품질 50 기준)과 나눠 배율을 구하고, IJG 공식으로 q 를 되돌리는 방법을 썼습니다:

ratio = median(qtable / STD_LUM) → s = ratio × 100 → q = (100 − s/2) if s > 100 else 5000/s

3,000장에 돌린 결과가 중앙값 100, p05 도 100 이었습니다. 전부 최고 품질이라는 건 말이 안 되니, 알려진 품질로 다시 인코딩해 추정기를 검증했습니다.

3단계 — bpp 목표 방식도 실패 (내용 의존성)

품질을 못 알아내니, 대신 파일 크기를 맞추기로 했습니다. real 에서 뽑은 목표 bpp 에 도달할 때까지 q 를 이진 탐색하는 방식입니다 (_encode_to_bpp, 탐색 범위 q 30–100, 6회 반복).

첫 시험에서 바로 깨졌습니다. 뽑힌 목표가 target_bpp = 0.0738 이었는데, 탐색은 하한 q = 30 까지 내려가서도 0.1298 에 멈췄습니다 — 목표의 1.76배입니다. 그런데도 이미지는 이미 q30 수준으로 뭉개졌습니다.

4단계 — 추정을 포기하고 양자화 테이블을 통째로 이식

q 를 알아낼 수 없다면 알아낼 필요 없게 만들면 됩니다. JPEG 인코더의 동작은 사실상 양자화 테이블이 결정하므로, real 파일에서 테이블을 읽어 합성 이미지를 인코딩할 때 그 테이블을 그대로 넣었습니다. PIL 의 save(qtables=...) 가 이를 지원합니다.

수집한 풀 (real 4,000장)

서브샘플링까지 옮긴 이유: 4:2:0 은 색차를 절반으로 줄여 색 경계에 특유의 번짐을 남깁니다. 이것도 탐지 가능한 흔적이라 함께 이식했습니다.

적용 절차 (한 장에 대해)

1. 풀에서 참조 항목 하나를 무작위 추출 → (짧은변 S, 종횡비 r, qtable, sub)
2. 종횡비 크롭: 1024×1024 에서 비율 r 이 되도록 중앙 크롭. 가로형/세로형을 50% 확률로 선택 (real 은 둘 다 있음). 예) r=1.502 → 1024×682 로 크롭
3. 축소: 짧은 변이 S 가 되도록 LANCZOS 축소. 확대는 하지 않음(S 가 현재보다 크면 건너뜀 — 없는 정보를 만들지 않기 위해). 예) S=333 → 500×333
4. 인코딩: 이식한 qtable·서브샘플링으로 JPEG 바이트 생성
5. 재디코딩: 그 바이트를 다시 열어 픽셀로 되돌림 — 이 왕복이 있어야 블록 경계·링잉이 실제로 픽셀에 새겨집니다
6. 이후 real 과 동일한 마지막 단계: 정사각 중앙 크롭 → 256px LANCZOS → q95 저장

실제 적용 로그 (같은 입력, 시드만 다름)

bpp 0.81–0.92 로 real 분포(중앙 0.57, p75 0.79) 상단에 들어왔습니다. 즉 압축 강도 재현 자체는 성공했습니다.

단계별로 실제 무엇이 나오는가

전체 이미지로는 차이가 거의 안 보입니다. 그래서 같은 영역을 4배로 확대하고, 직전 단계와의 차분을 12배 증폭해 무엇이 사라지고 무엇이 새겨지는지 봤습니다.

5단계 — 무엇으로 판정했는가 (지표 정의)

두 지표 모두 내용에 의존합니다(클로즈업이 원경보다 큼). 그래서 비교는 ① 같은 프롬프트·시드의 짝 이미지 ② 클래스당 1장으로 균형을 맞춘 표본 두 방식으로 각각 했습니다. 처음에 real 표본을 앞에서 90장 자르는 실수를 했는데 그게 전부 같은 클래스여서, 클래스 균형 표본으로 다시 측정했습니다.

6단계 — 판정: 매칭은 방향이 반대였다

짝 비교 (같은 프롬프트·시드 90쌍)

클래스 균형 표본 (클래스당 1장, n=100)

7단계 — 최종 후처리 (지금 쓰는 것)

두 번의 실패를 거쳐 후처리는 최소로 정착했습니다.

2번이 핵심 보험입니다. 13만 장 원본은 약 200GB 인데 HDD 에 15TB 가 남아 있어, 후처리 방침을 바꾸고 싶어질 때 31일을 다시 기다리지 않고 재처리할 수 있습니다. 폐기한 이력 매칭 코드도 src/match_real.py 에 남겨 뒀습니다.

학습 단계에서의 처리 (real 과 완전 동일)

1. real: 원본 → 정사각 중앙 크롭 → 256px LANCZOS → JPEG q95 로 미리 캐시 (45,000장, 1.5GB, 28프로세스로 2분 36초)
2. 합성: 위 4단계 산출물이 이미 같은 규격
3. 양쪽 모두 160px 로 RAM 에 uint8 상주 → GPU 에서 affine_grid+grid_sample 로 per-sample RandomResizedCrop(scale 0.35–1.0) + 좌우반전 → 128px 학습 입력

폐기한 후처리 ② — 생성 해상도 낮추기

축소 배율이 문제라면 애초에 작게 생성하면 될 것 같았습니다. 속도도 3~5배 빨라지니 일석이조로 보였습니다. 그래서 512·384 로 실측했습니다.

설정별 고주파 통계 (클래스당 1장, n=100)

프롬프트에서 세 번 실패한 기록

후처리보다 프롬프트가 결과를 훨씬 크게 바꿨습니다. 그리고 실패는 매번 같은 패턴이었습니다 — 모델이 '어떻게 찍혔는가'를 '무엇이 찍혔는가'로 바꿔버립니다.

이 설정은 'ImageNet 프로파일' 이다 (2026-08-20 동결)

위 모든 결정은 ImageNet 을 타깃으로 한 프로파일입니다. 타깃이 바뀌면 프롬프트 원천·화질 방침·후처리가 함께 바뀌므로, 설정을 src/profiles.py 에 이름 붙여 동결했습니다.

전체 기록: docs/09_profiles.md · 기계 판본: results/profiles.json

아직 못 고친 것

현재 생산은 이 문제 때문에 보류 상태입니다. 적용 후 시작할지, 지금 설정으로 갈지 결정을 기다리고 있습니다.