功能建议

[aigias]

作者好，

我在使用下载功能时候，遇到如下情况：
图片会有下载失败的情况，但图片文件仍然被创建，图片的表现是：图片会有一部分是黑色，一部分是正常的。
这类图片在后续的操作（比如ai训练）中往往会报错: image file is truncated

如果只下载少量的图片，肉眼很容易找到有问题的图片，删除即可。
但当文件数较多时，就不好这么做了。

我在reddit上找到一段代码
https://www.reddit.com/r/StableDiffusion/comments/13mc1dg/kohya_ss_keeps_barfing_during_caching_latents/
代码可输出损坏文件的文件名，之后手动删除即可解决问题。

是否考虑直接把此功能加进来呢？

[WSH032]

好的，收到你的建议。有以下说明：

出现一部分黑，一部分正常的情况，是因为下载强制使用了流式传输；即收到多少数据，就会立马写入到文件里；如果连接不稳定导致中断了，就会出现这种情况。

---

这种情况我们目前有如下解决方法：

• 上一次下载完后，不要改变下载的tags、数量、unit，然后再运行一次脚本；完好的、已存在的图片不会被重复下载，而出错的图片会被再一次尝试下载。

当然，可能会因为网络原因，部分图像仍然下载错误。

---

我的疑问是：

再将这些损坏的图片直接丢入kohya-ss的Lora训练中，会出现类似OSError: image file is truncated (62 bytes not processed)的报错导致整个训练都被终止吗？

因为我印象中，kohya会考虑到这类truncated的图片，并且自动忽略它们（和你把它删了没什么区别），这个报错应该只是提醒你。

但是，如果确实有训练奔溃的情况发生，你提到的这个功能建议是非常有必要的。

当然，即使不会导致训练奔溃，尽可能消除报错也是挺重要的。

---

采纳这个建议。

我可以在输出文件名的同时，直接自动把这些损坏的文件删除，这样就不需要浪费宝贵的人工时间了。

这个方案如何？

你可以留着这个issue，到时我更新后我再将它关闭

[aigias]

关于疑问，我用的是https://github.com/Akegarasu/lora-scripts
结论是会导致训练终止。这也是我第一次遇到这种报错，因为之前的训练集规模较小，都是手动找的，故没有损坏的图片。

对直接删除损坏图片的处理办法没有异议，感谢作者。

[WSH032]

@aigias 我以更新该功能

• 下载时候的使用方法请看run_download_images_coroutine.ps1
• 你也做为单独的工具脚本使用，请看utils/run_check_images.ps1
• API方式

  await Scrape_images(*arg,**kwargs,
  check_images_mode: Union[None, int]=None,  # 新增参数
  )
  # check_images_mode为是否在下载结束后检查图片是否正确
  #   默认为None，不检查
  #   0为检查，但只输出信息不做任何操作
  #   1为尝试修复图片
  #   2为尝试删除图片