개선된 H3 Refmods: 더 나은 정확도와 낮은 아이덴티티 블리딩을 적은 이미지로 구현하고, 비디오 편집용 에디트 마스킹 기능 추가

저장소는 여기입니다 - https://github.com/Adudeguyman/ComfyUI-Fantastic-MiniMaxH3-PromptBuilder 다시 돌아왔습니다. RefMods가 좀 더 잘 작동하도록 만들었고, 많은 아이덴티티/블리드 문제를 해결했습니다. 물론 시간과 메모리의 대가를 치르면서 말이죠. 이게 뭐냐면요 - 기존의 일반적인 refmods는 미디어를 .safetensors 파일로 latents 형태로 저장하고, 이 모든 것을 MiniMax H3 DiT에 직접 공급하며, 참조(references)를 사용하지 않고 텍스트 인코더가 이를 볼 일이 없었습니다. 이것은 하나의 refmod로는 잘 작동했습니다. 모델이 그 참조들을 가지고 SOMETHING을 해야 한다는 것을 알았기 때문에 놀라울 정도로 잘 처리했거든요. 하지만 이 방식은 좋은 유사성을 얻기 위해 여러 refmods를 쌓는(stacking) 사람들에게도 문제가 되었습니다. 제 이전 구현 방식은 몇 프레임을 재인코딩하는 비용(4번째마다 2개의 블록으로 비전 모델에 제시됨)을 치르고 그 latents의 일부를 텍스트 인코더에 공급하여, TE가 이를 보도록 했습니다. 이것은 프롬프팅 시 모델에 참조 닻(reference anchors)을 제공하기 위한 것이었습니다 (예: "<Subject 1>은 <Video 1>에 있는 사람이다"와 같이). 이 방식은 해당 프레임들이 TE를 위해 매 생성마다 인코딩되었기 때문에 속도 저하를 일으켰습니다. GitHub의 한 사용자가 이에 대해 불만을 제기하여, 저는 속도 향상과 캐싱 방안을 찾아보았습니다. 그리고 놀랍게도, .safetensors가 mp4나 mkv와 같은 래퍼(wrapper)에 불과하기 때문에, latents 데이터와 함께 여러 유형의 데이터를 저장할 수 있습니다. 그래서 속도 향상은 쉬웠습니다. refmod 이미지를 실제 jpeg 데이터로 저장하여, latents와 동일한 파일 안에 보관하는 것입니다. 마치 비디오 안에 자막이 있는 것과 같다고 생각하세요. 비디오 및 오디오와 함께 다른 유형의 데이터가 감싸져 있는 것이죠. 그래서 실제 jpeg 데이터를 패킹하면, VAE를 거치지 않고 텍스트 인코더에 직접 공급할 수 있으며, TE의 컨디셔닝은 실행 간(between runs) 캐싱될 수 있습니다. 따라서 refmods의 순서나 강도를 변경하지 않는 한, 모든 run-processing이 건너뛰어집니다. 그리고 jpeg 데이터는 모델에 절대 전달되지 않고, 패킹된 latents만 전달되므로, 일반적인 refmod가 작동하는 것과 매우 유사하게 기능합니다.

하지만 이것을 보니 문득 궁금해졌습니다. 더 나은 컨디셔닝을 위해 프레임을 텍스트 인코더에 전달하는 방식을 바꿀 수는 없을까? Fantastic H3 RefMod Text Encode 노드의 "stack_pictures" 함수를 사용해 보세요. 기본값인 "every 4th"는 기존처럼 2개 단위로 4프레임마다의 프레임을 보내는 동작을 유지하며, 실행하기 가장 가볍고 1개의 refmod에 적합합니다. "up to 8"은 데이터셋 전체에 걸쳐 최대 8개의 프레임을 샘플링하여 청크가 아닌 개별적으로 공급하며, 8프레임으로 제한하는 것이 전체 대규모 데이터셋을 실행하는 것보다 가볍고 전반적인 디테일을 높여주지만 처리 시간이 더 오래 걸립니다. 그리고 마지막으로 "all"은 모든 프레임을 텍스트 인코더에 보내어 시간을 상당히 늘리지만, 최대의 디테일을 제공하며 예시에서 볼 수 있듯이 캐릭터 블리딩(character bleed)이 거의 없습니다. 제가 알기로는 말이죠. 이 예시는 캐릭터당 6개의 이미지와 각 목소리별로 몇 초 분량의 오디오를 사용했습니다. 데이터셋은 모두가 좋아하는 파일 공유 공간인 스케치한 구글 드라이브 링크에서 찾을 수 있습니다. (명백하게, 제가 찾을 수 있는 모든 출처가 품질이 매우 낮기 때문에 Jackie Chan의 Chun Li는 최악입니다). 기본적으로 저는 refmods를 로드하고 subject_definitions와 retention_analysis 섹션을 작성했습니다(만약 제 RefMod 라이브러리에 세부 정보를 설정하고 프롬프트 빌더에서 "Draft from Refmods"를 사용하면 이 모든 것을 자동으로 로드해 줍니다.). 또한 속도 향상을 위해 comfy-kitchen으로 8단계 하이퍼플로우(hyperflow)를 사용했고, 최종 결과물을 정리하기 위해 오디오 리파이너 스위트(audio refiner suite)를 사용했습니다. 3개의 refmods를 함께 사용하는 것(약 14,900 토큰)은 제 5090에서 0.98mp 기준으로 약 32초/it이었습니다. 목소리가 여전히 이상하거나 때로는 어떤 이유로 사람을 바꾸고 싶어 할 수 있다는 점에 유의하세요. 그리고 주체를 정의할 때는 다른 캐릭터와 비교하여 그들에 대해 더 독특한 내용을 조정하는 것이 좋습니다. 예를 들어, 저는 Callina Liang에게 "계란형 얼굴(oval face)"을, Ming-Na Wen에게는 "더 각진 턱(more squared jaw)"을 갖추고 있다고 설명했습니다. 평소에 사용하지 않는 서술이지만, 다른 사람들과의 차별점으로서 잘 작동했습니다.

H3는 증류된(distilled) 모델이기 때문에 부정문 처리는 하지 않는다는 점을 기억해 주세요. 따라서 '이 사람은 보조개가 없다'와 같은 표현은 아무런 효과가 없을 것이므로, 프롬프트에서 모든 '없다(no)'나 '아니다(not)'라는 단어는 빼주세요. 기존 RefMods에 특별히 필요한 것이 있나요? 아니요, 텍스트 인코더는 이미지 데이터가 safetensors 파일에 저장되어 있는지 감지하며, 그렇지 않은 경우 설정한 동작에 따라 VAE 디코드(decode)를 수행하고, 이 디코드된 이미지를 텍스트 인코더에 공급하여 워크플로우에서 refmods를 변경할 때까지 결과를 캐시합니다. 따라서 기존의 refmods도 문제없이 작동할 것입니다. 하지만 새로운 것을 만들거나 제 refmod 노드를 사용해 재작업하는 경우, 적절한 해상도로 자른 이미지 데이터를 파일에 직접 저장하게 됩니다. 텍스트 인코더로 전송되는 이미지가 더 깨끗하고, 항상 디코드 단계를 건너뛸 수 있습니다. 또한 기본 해상도를 1024 대신 768로 변경했는데, 이는 토큰을 많이 절약할 뿐만 아니라 어차피 H3의 네이티브(native) 해상도이기 때문입니다. 아, 그리고 Media Loader에서 마스킹 기능도 생겼습니다. 이제 비디오를 편집하고 싶을 때, Media Loader에 레이어 마스킹 시스템도 추가했습니다. 오른쪽 클릭하여 디스크립터(descriptors), 캔버스 위의 점(dots), 또는 둘 다를 사용하여 SAM 3.1로 변경하고 싶은 부분을 자동으로 마스킹할 수 있습니다. 또한 움직이는 키프레임 모양(직사각형이나 타원형 등)을 수동으로 추가하여 비디오의 특정 부분을 삽입하거나 변경할 수도 있습니다. 이는 레이어 시스템이므로 마스크의 각 부분을 개별적으로 편집할 수 있지만, 모델에는 하나의 큰 덩어리(blob)로 전송됩니다. 블러(Blur) 및 색상 반전(color inversion) 옵션도 존재합니다. 그런 다음 VAE 디코드와 비디오 저장 노드 사이에 위치한 Fantastic H3 Edit Composite 노드가 마스킹된 생성을 원본 클립 위에 합성할 것입니다. 따라서 배경이 약간 어긋나는 일은 더 이상 없을 것입니다. 제가 테스트해 본 바로는 상당히 매끄럽습니다. 또한, 압축되어 가능한 한 작게 유지되지만 오래된 마스크들이 쌓일 수 있기 때문에 미디어 로더에 '정리(clean up)' 버튼도 있습니다. 다만, 프롬프팅은 여전히 사용자에게 달려있으며, 저는 아직 최적의 사용 사례들을 검토하고 있는 중입니다. 감사합니다.

제출자: u/acedelgado [링크] [댓글]