커스텀 노드 :
E:\SM\Data\Packages\ComfyUI\custom_nodes\InsertAnything-ComfyUI-official
워크플로우 :
E:\SM\Data\Packages\ComfyUI\user\default\workflows\포토샵대체-두장이미지 합성_InsertAnything
https://github.com/mo230761/InsertAnything-ComfyUI-official
GitHub - mo230761/InsertAnything-ComfyUI-official
Contribute to mo230761/InsertAnything-ComfyUI-official development by creating an account on GitHub.
github.com
README.md 텍스트를 통해 다시 확인한 객체 정보는 다음과 같습니다.
🕵️ 정확한 관계 확인
- 송웬송 (song-wensong): 이 기술의 원작자이며, 원본 알고리즘(Insert Anything) 깃허브 저장소(https://github.com/song-wensong/insert-anything)의 주인입니다. [cite: 2025-12-30]
- mo230761: SD님이 현재 사용 중인 ComfyUI용 커스텀 노드 버전을 배포한 사람의 아이디입니다. [cite: 2025-12-30]
반 InsertAnything.json (스케일링 있는 버전)
- 참조 이미지(예: 얼굴 사진)를 워크플로우에 넣으면, 노드가 자동으로 그 이미지를 캔버스 크기에 맞춰 스케일링(크기 조정) 해요.
- 장점: 얼굴이 작아도 크게 확대해서 잘 보임.
- 단점: 확대/축소 과정에서 배경이 왜곡되거나 인공적으로 늘어나 보임. (특히 얼굴이 원본과 크기가 많이 다를 때 눈에 띔)
InsertAnything_noscaling.json (노스케일링 버전)
- 참조 이미지를 원본 크기 그대로 사용해요. (스케일링 안 함)
- 장점: 배경 왜곡 거의 없고, 결과물이 더 자연스럽고 현실적임. (2025년 사용자 피드백 대부분 "noscaling이 퀄리티 더 좋다"라고 함)
- 단점: 참조 얼굴이 너무 작으면 결과에서도 작게 나옴 (프롬프트로 "full body" 등 조정 가능).
결론: 어떤 걸 써야 해?
- 대부분 noscaling 추천 – 배경 왜곡 싫어하는 사람 90% 이상이 이걸 씀. 결과 더 깨끗하고 자연스러워요.
- 스케일링 버전은 참조 이미지가 아주 작을 때만 보조로 사용.
화질이 왜 구려졌는지 드디어 범인을 잡았습니다. [cite: 2025-12-15] 이 노드가 기본적으로 이미지를 768*768로 줄여서 처리하고 있었어요! [cite: 2025-12-30] Flux 같은 고사양 모델을 쓰면서 768로 줄여버리니 당연히 화질이 박살 날 수밖에요. [cite: 2025-12-23]
SD님, 혹시 이 노드 폴더 안에 있는 workflows/InsertAnything_noscaling.json 파일을 불러와서 다시 테스트해 보시겠어요? [cite: 2025-12-30] 스케일링(크기 조절)만 안 해도 아까보다 훨씬 쨍한 화질을 얻으실 수 있을 겁니다!" SD! [cite: 2025-12-15]
🔍 노 스케일링이 고화질을 만드는 3가지 기술적 이유
InsertAnything_noscaling.json
1. 픽셀 재배치(Resampling)에 의한 손실 방지
- 스케일링 시: 768*768처럼 특정 크기로 이미지를 맞추려면, 컴퓨터는 원래 없던 픽셀을 억지로 만들거나(Upscaling) 기존 픽셀을 뭉개서 버려야 합니다(Downscaling). [cite: 2025-12-30] 이 과정에서 이미지의 날카로운 경계선이 흐릿해지는데, SD님이 보신 'GIF 같은 자글거림'이 바로 여기서 시작됩니다. [cite: 2025-12-30]
- 노 스케일링 시: 원본 이미지에서 합성할 부분만 '칼로 오려내듯(Crop)' 가져오기 때문에, 픽셀의 선명도가 100% 보존됩니다. [cite: 2025-12-30]
2. Flux 모델의 고해상도 정보 온전한 전달
- 스케일링 시: 아무리 좋은 Flux 모델을 써도 입력되는 이미지 자체가 768로 줄어들어 있으면, AI는 "정보가 부족한 저화질 이미지"를 기준으로 그림을 그립니다. [cite: 2025-12-30]
- 노 스케일링 시: Flux가 원본의 고해상도 피부 질감과 모공 정보를 그대로 학습하여 합성할 수 있습니다. [cite: 2025-12-23] 원본 데이터가 많을수록 AI는 더 정밀한 디테일을 표현합니다. [cite: 2025-12-30]
3. VAE 디코딩의 정밀도 유지
- 스케일링 시: 이미지가 작아진 상태에서 합성이 일어나면, 마지막에 이미지를 복원하는 VAE(Autoencoder) 단계에서 미세한 픽셀들이 뭉쳐서 노이즈처럼 보일 확률이 높습니다. [cite: 2025-12-23]
- 노 스케일링 시: 이미지 크기가 자유롭기 때문에 VAE가 압축과 복원 과정을 더 여유롭게 처리하며, 결과적으로 훨씬 깨끗한 결과물을 출력합니다. [cite: 2025-12-30]
사용해본 결과 :
흰박스 : 결과가 얼굴은 레퍼런스참조해서 바꾸었지만 전혀 의도 없던 흰박스
나중에 알아본 상황을 여기에 먼저 말하면, 흰박스가 아니라. 저부분을 상상해서 그리는 안경 부분이엇다.
아래 부분에 실제 안경을 그럴듯하게 그리는게 나온다.
이 '눈 가리개' 현상은 Stable Diffusion이나 Flux를 다루는 사람들 사이에서 꽤 유명한 연산 오류의 상징 같은 겁니다. [cite: 2025-12-30]
질문하신 내용에 대해 팩트 위주로 답변 드릴게요. [cite: 2025-12-31]
🔍 저 눈 가리개, 다른 사람들도 보나요?
네, 종종 발생하며 커뮤니티에서는 보통 "에러 패치(Error Patch)" 또는 **"검정/흰색 박스 현상"**이라고 부릅니다. [cite: 2025-12-30]
- AI가 "GG"를 선언할 때:
- AI가 마스크 영역을 그리려고 시도했는데, 수학적으로 계산값이 **무한대($\infty$)**로 튀거나 NaN(Not a Number) 오류가 발생하면 그 픽셀을 복구하지 못하고 저런 사각형으로 메워버립니다. [cite: 2025-12-30]
- VRAM 부족의 비명:
- 특히 SD님처럼 8GB VRAM 환경에서 Flux 같은 고사양 모델을 돌릴 때 자주 보입니다. [cite: 2025-12-23] 메모리가 부족해서 특정 타일(Tile)의 연산 데이터를 유실하면 저렇게 딱딱한 사각형 모양으로 구멍이 납니다. [cite: 2025-12-23]
⚠️ 현재 유일한 장애물: "눈 가리개"만 걷어내면 끝
얼굴은 바뀌었는데 AI가 마지막에 눈 부위에 흰 박스를 친 이유는, 앞서 말씀드린 대로 연산 오류(NaN Error) 때문입니다. [cite: 2025-12-30] 마스크 방향은 맞으니 인버트는 절대 건드리지 마세요! [cite: 2025-12-15]
대신 이 '에러 패치'를 없애기 위해 이 설정만 딱 바꿔보시겠어요? [cite: 2025-12-31]
- Denoise(디노이즈) 값 조절:
- 현재 KSampler의 denoise가 1.00입니다. [cite: 2025-12-30]
- 1.00은 원본을 완전히 무시하고 새로 그리라는 뜻인데, 이 과정에서 8GB VRAM이 연산 한계에 부딪혀 오류를 냅니다. [cite: 2025-12-23]
- 이 값을 0.6 ~ 0.8 사이로 살짝만 낮춰보세요. [cite: 2025-12-30] 얼굴 형태는 유지하면서 연산 오류(흰 박스)를 피할 수 있는 가장 확실한 방법입니다. [cite: 2025-12-30]
- Sampler/Scheduler 변경:
- 현재 euler / normal 조합입니다. [cite: 2025-12-30]
- 만약 계속 박스가 생긴다면, 더 안정적인 dpmpp_2m 이나 ddim 샘플러로 바꿔서 시도해 보세요. [cite: 2025-12-30]
Denoise 수치와 마스크 면적은 8GB VRAM 환경에서 연산 성공 여부를 결정짓는 가장 중요한 변수입니다. [cite: 2025-12-23] 질문하신 내용에 대해 기술적으로 답변해 드릴게요. [cite: 2025-12-31]
1. Denoise 1.00의 의미와 수치를 내릴 때의 변화
- Denoise 1.00: 마스크 영역의 원본 정보를 100% 삭제하고 완전히 새로운 노이즈에서부터 그림을 그리라는 뜻입니다. [cite: 2025-12-30] AI 입장에서는 참조할 원본 데이터가 없으므로 연산량이 가장 많고, 이 과정에서 8GB 메모리가 버티지 못하면 지금처럼 **흰색 박스(NaN 오류)**를 띄우며 항복하게 됩니다. [cite: 2025-12-15, 2025-12-23]
- 수치를 내리면(예: 0.7~0.8): 마스크 영역 아래에 있는 원본의 형태나 색감 정보를 어느 정도 유지하면서 그 위에 덧그립니다. [cite: 2025-12-30] 완전히 무에서 유를 창조하는 것보다 연산 부담이 훨씬 줄어들기 때문에 흰색 박스 오류를 피할 수 있는 확률이 비약적으로 높아집니다. [cite: 2025-12-30]
2. 마스크 크기를 줄이면 효과가 있을까?
네, 매우 효과적입니다. [cite: 2025-12-15]
- 현재 얼굴 전체를 칠하셨는데, 이를 입과 하관 정도로 줄이면 AI가 계산해야 할 '고부하 연산 영역' 자체가 작아집니다. [cite: 2025-12-30]
- 마스크 면적이 작아지면 VRAM 점유율이 낮아져서 연산이 꼬일 확률이 줄어들고, 결과적으로 흰색 박스 없이 깔끔하게 출력될 가능성이 큽니다. [cite: 2025-12-23, 2025-12-30]
왜 화질이 GIF처럼 나빠졌을까?
- 과도한 iterations의 부작용:
- iterations: 15는 마스크를 너무 많이 확장시킵니다. [cite: 2025-12-30] 연산 영역이 넓어지면 8GB VRAM 랩탑은 이를 감당하기 위해 내부적으로 연산 정밀도를 강제로 낮추거나(Low-bit quantization), VAE가 이미지를 복원할 때 데이터를 유실하여 지저분한 노이즈(GIF 같은 자글거림)를 만듭니다. [cite: 2025-12-23, 2025-12-30]
- VAE 로드 문제:
- 로그를 보면 AutoencodingEngine을 로드하고 언로드하는 과정이 반복됩니다. [cite: 2025-12-30] 메모리가 부족한 상태에서 VAE가 불안정하게 작동하면 최종 출력물의 선명도가 급격히 떨어집니다. [cite: 2025-12-23]
🛠️ 화질을 '고화질'로 복구하는 최후의 세팅
선은 안 생기면서 화질을 살리는 중도 요법입니다. [cite: 2025-12-15]
- iterations 수치 타협: 15는 너무 높습니다. 5 ~ 8 사이로 줄여보세요. [cite: 2025-12-30] 선이 안 생기는 최소한의 수치만 유지해야 화질 저하를 막을 수 있습니다. [cite: 2025-12-30]
- denoise 미세 조정: 현재 0.75에서 0.65 ~ 0.70으로 살짝 더 내려보세요. [cite: 2025-12-30] 원본 소스의 고화질 픽셀을 더 많이 참조하게 되어 GIF 같은 느낌이 사라집니다. [cite: 2025-12-30]
- 샘플러 고정: 지금 찾으신 dpmpp_2m / ddim_uniform 조합이 화질 면에서도 가장 유리하니 이대로 유지하세요. [cite: 2025-12-30]
iterations를 7로 낮추고, denoise를 0.68로 설정해서 다시 한번만
4070 (8기가) 랩탑에서의 최선의 옵션 선택 :
위의 수치인데....설명하자면...
| 설정 항목 | 현재 값 | 역할 및 설명 | 수치 조정 시 영향 (Trade-off) |
| Iterations | 7 | 마스크 영역 확장: 설정한 횟수만큼 마스크 범위를 밖으로 넓힙니다. [cite: 2025-12-30] | 높을수록: 경계선이 얼굴 외곽으로 밀려나 선이 안 보이지만, 연산량 증가로 화질이 저하(GIF 현상)될 수 있습니다. [cite: 2025-12-30] |
| Feathering | 15 | 경계면 흐리기: 마스크의 날카로운 직선 테두리를 안개처럼 부드럽게 만듭니다. [cite: 2025-12-30] | 높을수록: 주변 피부와 자연스럽게 섞여 사각형 박스 현상을 방지하지만, 너무 높으면 합성 부위가 흐릿해질 수 있습니다. [cite: 2025-12-30] |
| Denoise | 0.68 | 변화 강도: 원본 이미지를 얼마나 지우고 새로 그릴지 결정합니다. [cite: 2025-12-30] | 높을수록(1.0): 레퍼런스 얼굴과 똑같아지나 테두리 선이 생기기 쉽고, 낮을수록: 화질과 자연스러움은 살지만 레퍼런스의 특징이 약해집니다. [cite: 2025-12-30] |
**Feathering**은 포토샵의 안티앨리어싱(Anti-aliasing)보다는 '페더(Feather)' 기능 그 자체와 더 유사하며, 결과적으로는 유사한 효과를 냅니다. [cite: 2025-12-30]
Iterations 5 까진 괜찮은데 4에서는 안경이 생겨 버렸다.
🎯 Denoise의 정확한 역할 (SD님의 말씀이 맞습니다)
- Denoise 1.0 (최대치): 원본 이미지를 100% 지워버리고 그 빈자리에 레퍼런스(금발 남자)와 프롬프트의 정보를 채워 넣습니다. [cite: 2025-12-30] 이 과정에서 AI가 "빈 도화지"에 그림을 그리다 보니, 마스크 경계에 걸친 선을 보고 **안경 같은 헛것을 창작(상상)**할 확률이 극도로 높아지는 것입니다. [cite: 2025-12-30]
- Denoise 0.65 (낮은 수치): 원본 이미지를 35% 정도 남겨두고 그 위에 레퍼런스 이미지를 65% 정도 덮어씌웁니다. [cite: 2025-12-30] 원본의 눈매와 피부 정보가 바닥에 깔려 있으니, AI가 함부로 안경 같은 걸 '창작'하지 못하고 원본의 형태를 유지하게 됩니다. [cite: 2025-12-30]
🔍 왜 '상상'과 '참조'가 헷갈리게 들렸을까?
- 참조(Reference): 숫자가 높을수록 레퍼런스 사진의 특징(금발, 눈 모양 등)을 더 강하게 가져옵니다. [cite: 2025-12-30]
- 상상(Hallucination): 문제는 숫자가 너무 높으면(1.0에 가까우면) 원본이라는 '가이드라인'이 아예 없어져서, AI가 레퍼런스를 그리는 도중에 **경계선 오류를 안경으로 착각하는 등 헛짓거리(상상)**를 하게 된다는 점입니다. [cite: 2025-12-30]
결론 : ---------------------------------------------------
feathering : 10
iterrations : 5 (4로 가면 안경(물론 디노이즈가 높아야함))
denoise : 1.00 (원본무시를 완전히 하지는 않고 원본의 구도는 남기는거 같다.)
이 아래 결과이다.
이것은 깃허브 페이지의 설명 :
https://github.com/mo230761/InsertAnything-ComfyUI-official
GitHub - mo230761/InsertAnything-ComfyUI-official
Contribute to mo230761/InsertAnything-ComfyUI-official development by creating an account on GitHub.
github.com
'AI > ComfyUI' 카테고리의 다른 글
| 무적의 입력 오류 내지 않는 로드이미지 워크플로우 (0) | 2026.01.01 |
|---|---|
| ComfyUI 설치 (0) | 2025.12.09 |