git 友好的图像格式？答案

【问题标题】：git-friendly image format?git 友好的图像格式？
【发布时间】：2022-01-26 18:59:35
【问题描述】：

对于repositories 每天更新数据图（包括略微变化的背景颜色渐变），我问自己是否有一些首选格式（或压缩算法）可以使用，以便 git 可以更有效地存储它们，而不是一直重写其中的 90%。

有没有比其他图像更“对 git 友好”的图像格式？

【问题讨论】：

只要是二进制格式 - 不。它可能更适用于 SVG 文件 - 取决于它们的创建方式
@fredrik 这并不重要，因为 git 无论如何都会将 SVG 文件存储为不同的 blob。
据我了解 git 是如何工作的，它可能会在打包 repo 内部时节省您的本地存储库空间（它似乎在可能的情况下使用 deflate 算法，甚至在可能的情况下使用增量压缩（再次，如果我猜对了）——git-scm.com/docs/pack-format）。所以，如果包文件做了我猜他们真正做的事情，那么你很可能不需要迁移到其他文件格式。
@fluffy 我很确定增量压缩仅适用于文本文件。如果 SVG 文件是全文，那么一旦触发压缩，服务器和本地沙箱上的存储需求就会明显变小。这比 Git 压缩二进制图像文件的最佳压缩率要高得多。
所以他可能会考虑使用像 PNG 这样的未压缩图像类型，因此 git 可以随着时间的推移优化 delta，因为这种格式的两张相对接近的图片将具有接近的二进制表示，这对于压缩不一定相同格式（例如 JPEG）（取决于他的图片及其每天的变化）

标签： git image-formats

【解决方案1】：

理论

“Git 友好”格式将是共享长相同字节序列的格式，无论它们是二进制还是文本。

现在，当您更改背景颜色渐变时，有损二进制格式可能会更改大部分字节，而更具描述性的基于文本的格式可能不会。

使用您自己的文件进行测试

我推荐这个测试来计算你实际用例中不同文件格式的压缩大小。

在开始之前，先使用沙盒或克隆，并积极压缩它，这样我们就知道后续步骤中的进一步压缩不是由于添加了图像：运行 git gc --aggressive 几次，直到 du .git 产生相同的结果回答两次。

现在，对于您要测试的每种文件格式，将该沙箱复制到一个新目录并执行以下步骤：

添加一组图像并通过多次运行 git gc --aggressive 再次积极压缩 repo，直到 du .git 两次产生相同的答案。
写下du .git 告诉你的内容：这是你的基线尺寸。
添加并提交一组新文件，与您在问题中描述的方式略有不同。
现在du .git 告诉您仅将这些文件添加到存储库中的大小。在提交时，Git 不会（通常）尝试应用增量压缩或打包，它只是为每个提交的文件添加一个新的 blob，除非已经存在相同的 blob。
再次运行git gc --aggressive，直到大小稳定。
现在du .git 告诉您 Git 能够通过何种方式压缩这些文件，可能是增量压缩。这里的大小减去第 2 步的大小就是添加一组新文件的空间成本。

通过针对图像的不同文件格式运行上述过程，您将获得特定于您的用例的答案。

Git LFS 可能是你的朋友

PS：话虽如此，我支持@Nicolas Voron 的回答：除非上面的大小成本对于您最终选择的文件格式而言实际上很小，否则请使用 Git LFS 以避免将来在您的 repo 获取太多时产生问题大到克隆。

【讨论】：

【解决方案2】：

由于 git 不是为（尽管它可以）处理二进制文件而设计的，所以我向您推荐优秀的 git-lfs extension（最初由 github 支持）：

因为有了 git，问题不在于你在做什么版本，而在于你是怎么做的。随着时间的推移，每日更新的数据图会产生大量数据，这在几年后将成为克隆和获取的问题。

如何使用：

下载并安装 Git 命令行扩展。下载后并安装，通过运行为您的用户帐户设置 Git LFS：

git lfs install每个用户帐户只需运行一次。

在您要使用 Git LFS 的每个 Git 存储库中，选择文件您希望 Git LFS 管理的类型（或直接编辑您的 .git 属性）。您可以在以下位置配置其他文件扩展名随时。

git lfs track "*.psd" 现在确保 .gitattributes 被跟踪：

git add .gitattributes 注意定义文件类型 Git LFS should track 本身不会将任何预先存在的文件转换为 Git LFS，例如其他分支上或您之前提交中的文件历史。为此，请使用 git lfs migrate1 命令，该命令具有旨在适应各种潜在用例的一系列选项。

没有第三步。像往常一样提交并推送到 GitHub 将;例如，如果你当前的分支被命名为 main:

git add file.psd git

commit -m "Add design file"

git push origin main

它的作用：

Git LFS 在 git repo 中存储一个指针文件来代替真实的大文件。结帐时指针被替换为真实文件（使用涂抹和清洁）。污迹和清洁过滤器是核心 Git，旨在允许在结帐时更改文件（涂抹）和提交（干净）。 Git LFS 使用这些技术将指针文件替换为正在使用的实际大文件。

编辑

正如我在您的问题下评论的那样，您可能会考虑使用 PNG 等未压缩的图像类型，因此 git 可以随着时间的推移优化增量，因为这种格式的两张相对接近的图片将具有接近的二进制表示，这对于压缩格式（例如 JPEG ）（这取决于您的图片及其每天的可变性，但由于这是一个情节，因此 png 绝对可以解决问题）。

另一个建议是在子模块中处理图片（除非它是专用的仅图像存储库），因此版本化图像的超重不会影响克隆和获取的整个存储库。

【讨论】：

这基本上意味着将文件移出 git。在我了解该过程的情况下，我真的会对哪种文件格式可能最适合 git 中的文件感兴趣。
@Jaleks 我编辑了我的答案
是的，也许未压缩的 PNG 是一种选择。也许PNG过滤器类型“Sub”可能很有希望，因为它至少应该为类似的背景梯度产生类似的数据行？仍然未压缩的 PNG 在网络上显示它们会更糟糕，就像提到的 repo 所做的那样。
老实说，存储绘图图像对我来说毫无意义（尤其是如果软件是基于网络的）。存储数据和生成图形前端是最好的选择恕我直言（chart.js、plotly 等）。
没有。所有那些 JS 的东西都是没有选择的。这不是游乐场。它应该在任何地方都有效。在这种方法中，页面应该固定在这里，并且应该立即存储站点的整个状态。还生成例如 50 个图，每个图有 4 个图 + 背景梯度 + 期望值，至少 2 年的每日数据点需要很长时间。它们应该在一页上。已经加载所有数据以在表格中显示它们需要很长时间。并且 JS 生成的数据甚至不会正确地缓存在浏览器中。预生成/存储非常有意义，JS 不像大多数情况下那样。

【解决方案3】：

好的，所以似乎没有普遍的答案，SOF社区的答案似乎是：

盲目尝试
不要像您想存储的那样存储图像

……没关系，如果能遇到一个对压缩类型有非常好的专业知识的人一起玩，那真是太幸运了。不过还是感谢您的尝试。

【讨论】：