MAI-Image 이미지 생성 (doggy8088/imagegen-mai)

Microsoft Foundry MAI-Image용 이미지 생성 스킬

현재 프로젝트(예: 웹사이트 에셋, 게임 에셋, UI 목업, 제품 목업, 와이어프레임, 로고 디자인, 포토리얼리스틱 이미지, 인포그래픽)를 위해 MAI-Image 배포를 사용하여 이미지를 생성하거나 편집합니다.

이 파일에서 <skill-dir>은 이 SKILL.md가 포함된 디렉터리를 의미합니다.

실행 모드 및 규칙

이 스킬은 <skill-dir>/scripts/image_gen.js에 번들된 CLI를 사용합니다. 에이전트 호스트는 이 워크플로우에 내장된 이미지 생성 또는 이미지 보기 도구를 제공하지 않으므로, 존재하지 않는 내장 도구를 참조하거나 사용하려고 시도하지 마세요.

CLI는 세 가지 하위 명령어를 제공합니다:

• generate
• edit
• generate-batch

규칙:

• 일반 이미지 생성 및 편집 요청에는 scripts/image_gen.js를 사용하세요.
• CLI는 MAI-Image 시리즈 모델만 지원합니다. GPT Image, DALL-E 또는 다른 모델을 이 CLI로 라우팅하지 마세요.
• 기본 배포는 IMAGEGEN_MAI_IMAGE_DEPLOYMENT이며, 설정되지 않은 경우 MAI-Image-2.6-Flash입니다. 사용자가 명시적으로 해당 모델을 요청하지 않는 한, 다른 배포로 자동 전환하지 마세요. 먼저 사용자에게 물어보세요.
• MAI 이미지 모델은 항상 불투명 PNG를 반환합니다. 투명 이미지가 필요한 경우 아래 크로마키 워크플로우를 사용하고 컷아웃이 로컬에서 수행되었음을 사용자에게 알리세요.
• batch라는 단어만으로 generate-batch가 필요한 것은 아닙니다. 다중 에셋 요청이 자연스럽게 JSONL 배치로 표현될 때 generate-batch를 사용하고, 그렇지 않으면 개별 CLI 명령어를 실행하세요.
• 실시간 API 호출에는 MAI 자격 증명과 네트워크 액세스가 필요합니다.
• 번들된 scripts/image_gen.js 워크플로우를 사용하세요. 일회성 SDK 실행기를 만들지 마세요.
• scripts/image_gen.js를 수정하지 마세요. 누락된 사항이 있으면 다른 작업을 하기 전에 사용자에게 문의하세요.

출력 정책:

• 생성된 에셋은 요청된 경로에 직접 쓰거나, 사용자가 경로를 지정하지 않은 경우 output/imagegen/에 씁니다.
• 이미지가 현재 프로젝트용인 경우, 작업을 마치기 전에 최종 선택된 이미지를 워크스페이스에 저장하세요.
• 사용자가 명시적으로 교체를 요청하지 않는 한 기존 에셋을 덮어쓰지 마세요. 대신 hero-v2.png 또는 item-icon-edited.png와 같은 버전 번호가 포함된 파일 이름을 만드세요.

공유 프롬프트 가이드라인은 references/prompting.md 및 references/sample-prompts.md에 있습니다.

CLI 문서/리소스:

• references/cli.md
• references/image-api.md
• references/codex-network.md
• scripts/image_gen.js

로컬 후처리 도우미:

• <skill-dir>/scripts/remove_chroma_key.js: 생성된 이미지에서 단색 크로마키 배경을 제거하고 알파 채널이 있는 PNG를 씁니다. 안티앨리어싱된 가장자리를 위해 자동 키 샘플링, 소프트 매트, 디스필을 선호합니다.

사용 시기

• 새 이미지 생성(컨셉 아트, 제품 사진, 커버, 웹사이트 히어로, 포스터)
• 현재 실제 정보에 의존하는 새 이미지 생성(--web-grounding 사용)
• 기존 이미지 편집(개체 제거 또는 교체, 속성 변경, 인페인팅, 텍스트 업데이트, 조명 또는 날씨 변경, 아티팩트 정리)
• 최대 5개의 참조 이미지를 하나의 결과로 결합(제품, 캐릭터 또는 브랜드 에셋 일관성)
• 하나의 작업에 대해 많은 에셋 또는 변형 생성

사용하지 말아야 할 시기

• 리포지토리 내 기존 SVG/벡터 아이콘 세트, 로고 시스템 또는 일러스트레이션 라이브러리 확장 또는 일치
• SVG, HTML/CSS 또는 캔버스로 직접 생성하는 것이 더 나은 단순한 도형, 다이어그램, 와이어프레임 또는 아이콘 생성
• 소스 파일이 이미 편집 가능한 네이티브 형식으로 존재하는 소규모 프로젝트 로컬 에셋 편집
• 사용자가 생성된 비트맵 대신 결정론적 코드 네이티브 출력을 명확히 원하는 모든 작업
• 약 1.5K보다 큰 출력(MAI-Image-2.6의 한도는 2,359,296픽셀, 예: 1536x1536); 자동 업스케일링 대신 사용자에게 한도를 알리세요.

결정 트리

두 가지 별개의 질문을 고려하세요:

1. 의도: 새 이미지인가요, 기존 이미지 편집인가요?
2. 실행 전략: 하나의 에셋인가요, 여러 에셋/변형인가요?

의도:

• 사용자가 기존 이미지의 일부를 유지하면서 수정하려는 경우 요청을 edit으로 처리하세요.
• 사용자가 스타일, 구성, 분위기 또는 주제에 대한 참조로 이미지를 제공하고 결과에 반영되기를 원하는 경우, 해당 이미지를 참조로 사용하여 edit을 사용하세요(MAI 생성 API는 이미지를 허용하지 않습니다).
• 사용자가 이미지를 제공하지 않으면 요청을 generate로 처리하세요.

편집 의미 체계:

• CLI 편집 모드는 반복되는 --image 플래그를 통해 하나에서 다섯 개의 로컬 PNG 또는 JPEG 파일을 허용합니다.
• 사용자가 대화에서 첨부 이미지 또는 참조를 제공하는 경우, 환경이 지원하면 먼저 로컬에 저장하고, 그렇지 않으면 사용자에게 로컬 파일 경로를 요청하세요.
• 이미지 순서는 중요하므로 각 이미지를 프롬프트에서 인덱스와 역할로 레이블 지정하세요.
• 편집의 경우 불변 항목을 적극적으로 보존하고 기본적으로 비파괴적으로 저장하세요.
• 편집은 MAI-Image-2 및 MAI-Image-2e에 대해 문서화되어 있지 않으며 CLI에서 차단합니다. 편집에는 MAI-Image-2.5 또는 MAI-Image-2.6 배포를 사용하세요.

실행 전략:

• JSONL 배치가 가장 명확한 워크플로우인 경우 많은 프롬프트/에셋에 대해 CLI generate-batch 하위 명령어를 사용하세요.
• MAI API는 요청당 하나의 이미지를 반환하며 n 매개변수가 없습니다. 변형의 경우 별도의 명령어 또는 별도의 배치 작업을 고유한 out 이름으로 실행하세요.
• 속도 제한은 낮습니다(예: Tier 1에서 MAI-Image-2.6-Flash의 경우 분당 6개 요청). 사용자가 할당량을 알지 않는 한 --concurrency를 기본값 2로 유지하세요.

사용자가 명확하게 기존 항목을 변경하도록 요청하지 않는 한 새 이미지를 원한다고 가정하세요.

워크플로우

1. CLI 하위 명령어 결정: generate, edit 또는 generate-batch.
2. 출력이 미리보기 전용인지 아니면 현재 프로젝트에서 사용할 것인지 결정합니다.
3. 실행 전략 결정: 단일 에셋, 반복 CLI 명령어 또는 CLI generate-batch.
4. 입력을 사전에 수집: 프롬프트, 정확한 텍스트(그대로), 제약 사항/회피 목록, 대상 크기 또는 종횡비, 모든 입력 이미지.
5. 모든 입력 이미지에 대해 해당 역할을 명시적으로 레이블 지정:
   • 참조 이미지
   • 편집 대상
   • 지원 삽입/스타일/합성 입력
6. 사용자가 사진, 일러스트레이션, 스프라이트, 제품 이미지, 배너 또는 기타 명시적으로 래스터 스타일의 에셋을 요청한 경우 SVG/HTML/CSS 자리 표시자를 대체하지 말고 이 스킬을 사용하세요. 요청이 기존 리포지토리 네이티브 SVG/벡터/코드 에셋과 일치해야 하는 아이콘, 로고 또는 UI 그래픽인 경우 대신 해당 에셋을 직접 편집하는 것을 선호하세요.
7. 특이성에 따라 프롬프트 강화:
   • 사용자의 프롬프트가 이미 구체적이고 상세한 경우, 크리에이티브 요구 사항을 추가하지 않고 명확한 사양으로 정규화합니다.
   • 사용자의 프롬프트가 일반적인 경우, 출력 품질을 실질적으로 향상시킬 때에만 취향에 맞는 강화를 추가합니다.
8. 크기를 선택합니다. 알려진 대상의 경우 --size WIDTHxHEIGHT를 사용하고, 구도가 결정해야 하는 경우(MAI-Image-2.6 제품군) --auto-aspect-ratio를 사용합니다. 프롬프트가 현재 실제 엔터티, 장소 또는 이벤트에 의존하는 경우(MAI-Image-2.6 제품군) --web-grounding을 추가합니다.
9. 기본 배포로 scripts/image_gen.js를 실행합니다.
10. 투명 출력 요청의 경우 아래 크로마키 워크플로우를 따릅니다.
11. 출력을 검사하고 확인: 주제, 스타일, 구성, 텍스트 정확도, 불변 항목/회피 항목.
12. 단일 대상 변경으로 반복한 다음 다시 확인합니다.
13. 미리보기 전용 작업의 경우 사용자가 다른 위치를 요청하지 않는 한 output/imagegen/에 씁니다.
14. 프로젝트에 바인딩된 작업의 경우 아티팩트를 워크스페이스에 쓰고 해당 소비 코드 또는 참조를 업데이트합니다.
15. 배치 또는 다중 에셋 요청의 경우, 사용자가 명시적으로 출력을 미리보기 전용으로 유지하도록 요청하지 않는 한 모든 요청된 전달물을 워크스페이스에 최종 저장합니다. 폐기된 변형은 요청되지 않는 한 유지할 필요가 없습니다.
16. 배포, 크기, auto_aspect_ratio, web_grounding, 출력 경로 및 네트워크 설정에 대해 CLI 문서를 사용하세요.
17. 작업공간에 바인딩된 모든 에셋의 최종 저장 경로와 최종 프롬프트 또는 프롬프트 세트를 항상 보고하세요.

투명 이미지 요청

MAI 이미지 모델은 항상 불투명 PNG를 반환하며 투명 배경 옵션이 없습니다. 크로마키 소스 이미지와 로컬 제거를 통해 투명 에셋을 만듭니다.

순서:

1. scripts/image_gen.js generate(또는 기존 이미지의 경우 edit)를 사용하여 요청된 주제를 완벽하게 평평한 단색 크로마키 배경에 배치합니다.

2. 주제에 나타날 가능성이 낮은 키 색상을 선택합니다. 기본 #00ff00, 녹색 주제의 경우 #ff00ff를 사용하고 파란색 주제의 경우 #0000ff를 피하세요.

3. 크로마키 소스 이미지를 워크스페이스 또는 tmp/imagegen/에 보관합니다.

4. 번들 도우미를 실행합니다:

   node "<skill-dir>/scripts/remove_chroma_key.js" \
     --input <source> \
     --out <final.png> \
     --auto-key border \
     --soft-matte \
     --transparent-threshold 12 \
     --opaque-threshold 220 \
     --despill
   

5. 출력에 알파 채널, 투명한 모서리, 그럴듯한 주제 범위 및 눈에 띄는 키 색상 프린지가 없는지 확인합니다. 흰색 배경과 어두운 배경 위에 겹쳐서 헤일로가 있는지 확인합니다. 얇은 프린지가 남아 있으면 --edge-contract 1로 한 번 재시도하고, 가장자리가 눈에 띄게 계단식이고 주제가 반짝이거나 반사되지 않는 경우에만 --edge-feather 0.25를 사용하세요.

6. 에셋이 프로젝트에 바인딩된 경우 최종 알파 PNG를 프로젝트에 저장합니다.

다음과 같은 크로마키 요청 프롬프트:

배경 제거를 위해 요청된 주제를 완벽하게 평평한 단색 #00ff00 크로마키 배경에 만듭니다.
배경은 그림자, 그라데이션, 텍스처, 반사, 바닥면 또는 조명 변화 없이 하나의 균일한 색상이어야 합니다.
주제를 선명한 가장자리와 넉넉한 여백으로 배경과 완전히 분리된 상태로 유지합니다.
주제 어디에도 #00ff00을 사용하지 마십시오.
명시적으로 요청되지 않는 한 캐스트 섀도우, 접촉 그림자, 반사, 워터마크 또는 텍스트가 없습니다.

크로마키잉은 머리카락, 털, 깃털, 연기, 유리, 액체, 반투명 재질, 반사 개체 및 부드러운 그림자에 적합하지 않습니다. 해당 주제에 대해 깨끗한 컷아웃을 약속하기 전에 이 한계에 대해 사용자에게 알리세요.

프롬프트 강화

사용자 프롬프트를 구조화된 프로덕션 중심 사양으로 재구성합니다. 사용자의 목표를 더 명확하고 실행 가능하게 만들지만, 맹목적으로 세부 사항을 추가하지는 마세요.

이것을 폐쇄형 스키마가 아닌 프롬프트 셰이핑 가이드라인으로 취급하세요. 도움이 되는 줄만 사용하고, 명확성을 실질적으로 향상시킬 때 짧은 추가 레이블 줄을 추가하세요.

특이성 정책

사용자 프롬프트의 특이성을 사용하여 얼마나 많은 강화가 적절한지 결정합니다:

• 프롬프트가 이미 구체적이고 상세한 경우 해당 특이성을 유지하고 정규화/구조화만 합니다.
• 프롬프트가 일반적인 경우, 결과를 실질적으로 향상시킬 때 취향에 맞는 강화를 추가할 수 있습니다.

허용되는 강화:

• 구성 또는 프레이밍 힌트
• 폴리쉬 수준 또는 의도된 사용 힌트
• 실용적인 레이아웃 지침
• 명시된 요청을 지원하는 합리적인 장면 구체성

허용되지 않는 강화:

• 요청에 암시되지 않은 추가 문자 또는 개체
• 암시되지 않은 브랜드 이름, 슬로건, 팔레트 또는 내러티브 비트
• 주변 레이아웃이 지원하지 않는 임의의 측면별 배치

사용 사례 분류(정확한 슬러그)

각 요청을 다음 버킷 중 하나로 분류하고 프롬프트와 참조 전반에 걸쳐 슬러그를 일관되게 유지하세요.

생성:

• photorealistic-natural: 실제 텍스처와 자연 채광이 있는 캐주얼/에디토리얼 라이프스타일 장면.
• product-mockup: 제품/패키징 샷, 카탈로그 이미지, 상품 컨셉.
• ui-mockup: 앱/웹 인터페이스 목업 및 와이어프레임; 원하는 충실도를 지정하세요.
• infographic-diagram: 구조화된 레이아웃과 텍스트가 있는 다이어그램/인포그래픽.
• scientific-educational: 교실 설명자, 과학 다이어그램 및 필수 레이블과 정확성 제약 조건이 있는 학습 시각 자료.
• ads-marketing: 대상, 브랜드 위치, 장면 및 정확한 태그라인/카피가 포함된 캠페인 컨셉 및 광고 크리에이티브.
• productivity-visual: 슬라이드, 차트, 워크플로우 및 데이터 중심 비즈니스 시각 자료.
• logo-brand: 로고/마크 탐색, 벡터 친화적.
• illustration-story: 만화, 아동 도서 아트, 내러티브 장면.
• stylized-concept: 스타일 중심 컨셉 아트, 3D/스타일화된 렌더링.
• historical-scene: 시대에 맞는/세계 지식 장면.

편집:

• text-localization: 이미지 내 텍스트 번역/교체, 레이아웃 유지.
• identity-preserve: 착용해보기, 장면 속 인물; 얼굴/신체/포즈 고정.
• precise-object-edit: 특정 요소 제거/교체(내부 교체 포함).
• lighting-weather: 시간/계절/분위기 변경만.
• background-extraction: 단색 크로마키 배경을 통한 깨끗한 컷아웃과 scripts/remove_chroma_key.js를 사용한 로컬 제거.
• style-transfer: 주제/장면을 변경하면서 참조 스타일 적용.
• compositing: 일치하는 조명/원근감으로 다중 이미지 삽입/병합(최대 5개 이미지).
• sketch-to-render: 드로잉/라인 아트를 포토리얼리스틱 렌더링으로.

공유 프롬프트 스키마

두 최상위 모드 모두에 대해 다음 레이블이 지정된 사양을 공유 프롬프트 골격으로 사용하세요:

사용 사례: <분류 슬러그>
에셋 유형: <에셋이 사용될 위치>
주요 요청: <사용자의 주요 프롬프트>
입력 이미지: <이미지 1: 역할; 이미지 2: 역할> (선택 사항)
장면/배경: <환경>
주제: <주요 주제>
스타일/매체: <사진/일러스트레이션/3D 등>
구성/프레이밍: <와이드/클로즈/탑다운; 배치>
조명/분위기: <조명 + 분위기>
색상 팔레트: <팔레트 노트>
소재/텍스처: <표면 세부 사항>
텍스트(그대로): "<정확한 텍스트>"
제약 사항: <유지해야 할 것/피해야 할 것>
회피: <부정적 제약 사항>

참고:

• 에셋 유형 및 입력 이미지는 프롬프트 골격이며, 전용 CLI 플래그가 아닙니다.
• 장면/배경은 시각적 설정을 나타냅니다.
• 크기, auto_aspect_ratio, web_grounding 및 출력 경로와 같은 실행 노트는 프롬프트 텍스트가 아닌 CLI 경로에 속합니다.

강화 규칙:

• 짧게 유지하세요.
• 프롬프트를 실질적으로 향상시키는 데 필요한 세부 사항만 추가하세요.
• 편집의 경우 불변 항목을 명시적으로 나열하세요(X만 변경, Y는 변경하지 않고 유지).
• 중요한 세부 사항이 누락되어 성공을 방해하는 경우 질문하고, 그렇지 않으면 진행하세요.

시험

…[번역을 위해 잘림]