CivitAI Image Meta Data Saving

这个工作流是做什么用的？

当我发布一个工作流时，我通常会聚焦于整个流程的某一个方面——至少这个工作流就是如此。我收到过几条消息，询问“你是怎么在图像中获取LoRA元数据的？”

这促使我创建了这个工作流，展示两种不同类型的工作流：一种使用KSampler节点，另一种使用SamplerCustomAdvance节点。但它们都使用了“Image-Saver”节点——你可以在ComfyUI Manager中搜索（Image Saver）找到它。

虽然这个节点可能不算特别流行，但它非常有效。我测试过几个不同版本，有些是自动化的，但需要特定的LoRA加载器——而当我改用新的LoRA加载器时，这些版本反而破坏了我的工作流。“LoRA Manager”才是真正改变游戏规则的工具，老实说，它本应成为ComfyUI的标准组件之一。

相信我，如果你还没试过这个LoRA Manager，赶紧去看看吧，它会彻底改变你今后处理LoRA的方式。关于LoRA Manager的帖子在这里：https://civitai.com/articles/11795/exciting-new-update-one-click-lora-integration-in-comfyui-lora-manager

以下是两种类型：

左侧是KSampler版本，右侧是SamplerCustomAdvance版本。

我将布局设计得清晰明了，让你可以直观地看到每个采样器节点如何与SaveImage节点配合使用。我这样设计是为了方便你理解和适应自己的偏好工作流。

上方部分是标准节点，虽然不是Image-Saver所必需的，但对图像生成是必需的；下方部分则是Image-Saver用来注入大量CivitAI用于自动链接资源所需元数据的关键部分。

虽然它不像我之前“将LLM添加到工作流”那样简洁直接，但这里尽可能减少了对额外插件的依赖。我自己的版本更复杂，但本次目标不是那样——而是为你提供在发布图像时实现自动资源链接所需的最基本配置。

GGUF与CivitAI的变通方案：

如我在工作流中所指出，CivitAI不允许直接上传GGUF检查点，所有GGUF文件必须先压缩为ZIP格式。但问题在于：当所有图像保存器都将SHA哈希值注入元数据时，它注入的是解压后文件的SHA哈希值。因此，当你将图像上传到CivitAI时，系统会忽略该检查点，因为所用模型的SHA哈希在CivitAI上并不存在。

即使你可以下载GGUF的ZIP文件，CivitAI记录的仍然是ZIP文件的SHA哈希，而非内部的GGUF文件。因此，链接永远无法建立。

这里提供了一个简单而有效的解决方法。对于所有使用GGUF、VRAM有限的朋友们，只需这一招，你的图像就能自动正确地链接到模型！