用HEVC压缩你的漫画(EP2) - LIBVIPS一行命令就能搞定? -

冰箱研会长

如果你觉得我遗漏了什么重要信息, 或者压根就看不懂我再说什么, 参见第一集

████████████████

距离第一集已经过了将近两个月了, 期间我的collection也从成长到撑爆了1T Onedrive的地步 (虽然后来发现这是因为onedrive回收站也算空间).
在考研复习和考研复习的间隙里, 看了不少图像处理的工具.
因为Netflix选择了AVIF作为下一代图像技术, 我也顺便研究了一下把收藏转换成AVIF的可能性,
具体的操作按下不表(可能会补在后面), 这里还是主要说HEVC.
在这段寻找解决方案的途中, 我发现了诸如 Colorist, Cavif, go-avif等等转换工具,
和像Vantage这样的HDR图像查看器.


一般来讲, 说到图像的综合批量处理工具, 无外乎就是 Image Magick 和 FFmpeg, 其他 "全知全能" 的工具也没有几个.
而HEIC因为HEVC版权的原因, 在诸多流行工具里的实现情况实在是很糟糕,
这种不利直接导致我需要用ffmpeg先成帧再封装的方式来批量转换HEIC, 实在是复杂, 很有在bash里调用各种外部命令处理文字输出的彷徨感.
那个帖子的最终解决方案被坛友们称为天书, 实在是令人羞愧.

不过正像我后来在Powershell里找到了ConvertFrom-CSV一样, 我想我这次找到了一个足够简单的解决方案了.

Libvips
点我访问项目主页

Libvips是一个集成了多种高效算法的图像处理library, 内存消耗, 处理速度快, 而且对图像格式有很好的支持.
然而遗憾的是, 因为Libvips的heic功能需要调用GPL的FFMPEG, 直接发布成品release会导致整个项目的授权发生变化. (只有GPL软件才能使用GPL代码)
开发者告诉我, 想要使用这一功能的话, 需要我自己编译.


于是昨天一天, 我一边做高宇1000题一边在Arch上编译这个项目(感想),
在各种问题解决之后, 我终于编译出了成品, 一个和官方发布版本一模一样, 同样不支持heif的libvips.

心态爆炸的我向开发者询问, 开发者告诉我:
"你干得不错, 但有一个同事早就发布了可用的版本, 你可以下载他的"

他的版本
↑这里下载本文用的软件

好的, 不论结果如何, 至少我拿到了我想要的东西, 还发现用docker编译软件真是天才的想法, 我以后也这么干(.

我们得到了这样一个软件包:


bin目录下面的vips.exe就是这次要使用的工具.


找个喜欢的目录把软件包扔进去, 然后把bin目录添加到环境变量里.



随便打开一个powershell窗口, 输入vips, 如果出现下图所示的输出就算可以了.


vips将图片转换成heic的命令是

1. 
   
2. vips heifsave <输入文件> <输出文件> --Q <质量因数 1倒100 默认50>

复制代码

如果忘记了, 可以直接输入

1. vips heifsave

复制代码

来查看参数帮助.

让我随便找两个图来对比测试一下:
默认的50质量因数, 漫画的网点保存的也不错.


彩图则是有轻微的色彩失真, 其实也很难看出来.



总的来说, 虽然不如我ffmpeg版本那么精确, 但可以接受.

因为VIPS.exe是一款命令行工具, 所我们可以很轻松的使用powershell来进行目录批处理,
即在想要处理的目录下运行:

1. Get-Childitem | %{vips heifsave $_.Name "$($_.Basename).heic"}

复制代码

即可批量处理当前目录下所有文件为heic.
如果想递归的处理文件夹下面的所有内容, 可以在根目录下运行

1. Get-ChildItem -Recurse | %{vips heifsave $_.FullName "$($_.Directory.Fullname)\$($_.Basename).heic"}

复制代码

如果只想处理某一种格式的图像文件, 可以:

1. Get-ChildItem -Recurse *.png| %{vips heifsave $_.FullName "$($_.Directory.Fullname)\$($_.Basename).heic"}
   
2. Get-ChildItem -Recurse *.jpeg| %{vips heifsave $_.FullName "$($_.Directory.Fullname)\$($_.Basename).heic"}

复制代码

注:路径包含中文名的情况下请做如图设置, 让电脑使用utf-8编码



只需要一行命令就可以转换图像为HEIC, 同时唯一需要用户设置的只有环境变量, 比起ffmpeg的方案要简化了不少.
好的, 关于HEVC的内容就说这么多, 干货基本说完了.
吃完饭回来补充一些AVIF, VVC, EVC, LCEVC的闲谈.

来自我的不明所以的吐槽

现在这些图片压缩, 本质上就是用那些压缩率超高的视频压缩算法, 把图片压成一帧然后封装一个容器.
HEIC是这样, WEBP是这样, AVIF也是这样.

HEIC是我这段时间实践下来综合性能最好的, windows可以看, llinux可以看, 苹果们可以看, 安卓至少小米可以看.
编码速度也很快, 读写性能也不错.
然而HEIC有一个最大的缺点, 那就是HEVC的存在本身,
HEVC是MEGA动态专家组(ISO组织JTC1的SC29旗下的WG11)开发的新一代视频标准, 诸位熟知的AVC H264就是这个组织开发的.
然而和广为流行的H264不同, HEVC虽然不能说是举步维艰, 但也算是被钳制了发展, 完全找到不进一步发展的潜力.
这也同时导致了脱胎于HEVC的HEIC发展同样糟糕.

HEVC的专利是三个主要专利池外加一堆独立专利组成的, 这种混乱直接导致的结果就是授权(发布, 改善, 管理)的难产和高昂的授权费用.


高效图像格式的战场, 正如webp的名字暗示的一样, 在互联网上.
如果一个图像格式无法被主流浏览器识别显示的话, 那它永远都称不上流行.
在Firefox的讨论串里, "Mozilla不会支付版权费来使用HEVC技术" 已经成为了半个共识,
同时各位也可以思考一下, 如果看HEVC视频的唯一方式是win10商店里6元钱的HEVC插件的话, VCB-S一类的压制组还会选用H265吗?

H265的这种现状, 已经决定了它, 如果不改善专利池, 将永远是一个应用在工业领域的视频标准, 不可能广泛传播.


也许是觉得这是一个很好的切入点, AOM横空出世.
发布了无专利费用(存疑, 不过至少现在给出的授权都很open)的AV1视频标准.
并获得了广泛的支持.


然而, 即便AV1克服了HEVC的最大缺点, 其衍生的AVIF图像格式也得到了FIREFOX和CHROME的支持,
AV1本身编码速度之慢也仍是个无法忽略的问题.
同样的图片, 编码一张AVIF的时间, 说100张HEIC可能有些扯淡了, 编码50张同样质量的HEIC应该是没什么问题的.
各位感兴趣的可以使用ffmpeg对比一下.

另外, AVIF即使前景开阔, 目前的支持状况属实不是很好.
在我个人的实验中, 出现了不同工具生成的AVIF兼容性差别极大的情况.
按照AVIF主页所说, 对AV1视频关键帧进行封装的AVIF无论使用Firefox还是win10自身解码器都无法解码.
反而是第三方工具Vantage可以正确显示图像.
如果使用Colorist编码AVIF, 偶数宽高的图像会显示一列/行紫色像素, 在firefox中则没有这个问题.
CAVIF的问题则是难以控制质量, 产出的图片几乎就是像素块.
这些问题并不是AV1的问题, 而是朴素的, 时间的问题, 时间带来这些问题, 时间也会解决这些问题.

毕竟AOM才是个成立两年不到的组织, 而对面已经寿终正寝的MPEG享年31岁.

是的, MPEG已经寿终正寝了.



在今年的六月份, ISO对MPEG相关的组织结构进行了调整:
将原来工作组11(MEPG)旗下的诸多小组统统提升为了工作组, 直辖于SC29.
并且开除了原**Leonardo Chiariglione(老头现在天天在这里骂ISO, 骂的特别狠), 目前, 来自微软 (AOM的有力支持者) 的Sullivan直辖SC29.
真是让人担心SC29的未来啊.



不过另一方面, 今年刚刚发布的VVC(HEVC的后继者)早在2020之前就已经基本结束开发,
这次重组对其性能的影响估计是微乎其微的.

然而, 正如前MPEG的前**透露的一样, VVC的专利池远比HEVC庞大, 复杂.
就算可以在工业领域取得一席之地, 也不会具备像AV1(或者AV2)那种明朗的前景.

但从已知的信息可以发现, 前MPEG并没有忽视AOM的威胁.
今年预定发布的, 除了VVC以外还有EVC和LCEVC.
前者是目标无专利费用的编码格式(对线AV1), 后者则是目标实现可高速软件的低复杂度视频编码.
两者的专利池都十分清晰, 如果这两者也发布的话, 可以反向逼迫VVC改善自身专利结构也说不定.
总之, 在这些标准发布之后, 才是判断SC29能否继承MEPG辉煌的时候.

希望先进的技术能惠及所有人

冰箱研会长

inflation 发表于 2020-8-18 09:13
这几天陆陆续续又看了一些关于图片编码上的文章，现在越发觉得Web上下一代图片标准会是JPEG XL而不是任何一 ...

今天build了一下win10下可以用的二进制
链接: https://pan.baidu.com/s/1RmvLym23qpWq1B-mN-bWjg 提取码: h3sz



效果还是挺可观的

1. #编码 (支持jpeg png webp输入, 好像还有其他的 编译的时候没仔细看)
   
2. #100是无损 0是全损
   
3. cjpegxl <输入文件> <输出文件> -q <0-100>
   
4. #解码
   
5. djpegxl <输入> 输出

复制代码

PNG无损编码JXL可以接近65%的压缩率(用例是动画截图和一些画稿).
因为已经发了二进制 我这里就不额外补充测试材料了, 简单说一下我看到的结果.

比JPEG强是一定的, 我和HEVC做了一下对比

中间是原图 左右分别是jxl和hevc, 这三张图片都是270kb左右的.(JXL因为解码兼容性目前约等于0所以用的是解码出来的PNG)
JXL的参数是-q 85, heic的参数是 crf=13
(右边有色差是image glass的锅....)
从边缘上来看我是倾向于jxl比heic要好的...

yguygyu

原来楼主也是用云
这样吧，我给楼主推荐一个不需要压缩的办法
去和几个人搭伙搞个 google drive for business，能以 12 USD 的月费换取号称无限但实际 2 PB 的云空间
美国的价格是 12 USD，不过其他有些国家地区会稍微便宜一点，换算下来是 10 USD 左右
1 PB = 1024 TB
不用愁了

冰箱研会长

yguygyu 发表于 2020-7-25 10:52
原来楼主也是用云
这样吧，我给楼主推荐一个不需要压缩的办法
去和几个人搭伙搞个 google drive for busine ...

哇, 可以的, 不过我是学生邮箱的1TB onedrive, 姑且算是白嫖.
你的方案我码了, 以后需要的时候用.

xy2401

压缩写真的话。参数要改吗？

冰箱研会长

xy2401 发表于 2020-7-25 11:33
压缩写真的话。参数要改吗？

不需要, 要注**图的话会有一些轻微的色彩改变.
程度参见主楼的彩图例子.

第一集里给的方法会准确转换色彩, 不过要比这个麻烦很多.

冰箱研会长

彩色是tm的敏感词?

Aeroblast

环境变量对一般人还是难度太高了，写个批处理怎么样，然后告诉一般用户把需要转换的图片文件夹拖到.bat上

不过查了一下现在各种浏览器还不支持……有点寸步难行的感觉，特别是通用看图软件看日漫
最近尝试打包带元数据的漫画，发现各种格式没有浏览器支持真是寸步难行，最后还是选了webp

冰箱研会长

Aeroblast 发表于 2020-7-25 12:39
环境变量对一般人还是难度太高了，写个批处理怎么样，然后告诉一般用户把需要转换的图片文件夹拖到.bat上

...

是哦 我研究一下

哎, 是这样的, 图像格式这种东西就是这么回事啊

upyzl

那个……其实用xnview就行了吧，能批量压缩，也能预览
支持avif和heic

冰箱研会长

upyzl 发表于 2020-7-25 17:13
那个……其实用xnview就行了吧，能批量压缩，也能预览
支持avif和heic

欸? Xnview我用的时候感觉相当不好用...
Heic的色彩配置好像也有那么点问题

scottrun

楼主你给的递归命令行有错吧。确定能运行？

冰箱研会长

scottrun 发表于 2020-7-25 18:44
楼主你给的递归命令行有错吧。确定能运行？

改了 不知道为啥少复制了一堆花括号 顺便优化了一下(

gdsdjcb

马克一下
用默认参数压了张彩图，好像用windows自带的照片打开彩图色差会比较大，用imageglass就好一点
不知道还有没有什么比较先进的相对于原图无损或者视觉无损的压缩方法？

inflation

任何一种codec从公开到encoder成熟至少需要5年时间，而且AV1复杂度是VP9的10x往上，再优化也是有极限的。

ffmpeg用的是libaom，也就是AOM的reference encoder，优化几乎是不存在的，因此编码速度慢可以理解，换SVT-AV1或者rav1e可以大幅提升速度，大概是HEVC编码的2x。Tiger Lake据说要增加AV1硬件支持了，LG的OLED电视已经支持硬件解码，移动设备支持很可能就在未来1～2年。

冰箱研会长

gdsdjcb 发表于 2020-8-14 21:26
马克一下
用默认参数压了张彩图，好像用windows自带的照片打开彩图色差会比较大，用imageglass就好一点
不 ...

第一张帖子(FFMPEG)是视觉无损的

冰箱研会长

ohi 发表于 2020-8-14 23:37
楼主说了老半天就是没说压缩效率，用视频编码压缩图片，比起现有的图片压缩，优势有多大？ ...

一言以蔽之, 很大.
一个7MB左右的GIF压成x264已经可以实现1MB以内
而HEVC的压缩率差不多是X264的150%

冰箱研会长

inflation 发表于 2020-8-14 23:15
任何一种codec从公开到encoder成熟至少需要5年时间，而且AV1复杂度是VP9的10x往上，再优化也是有极限的。

...

今年我还是等等LCEVC
完全软件实现的编码升级, 应该年内就会发布.

pluser

积攒了好多小本子，都是下载后自己整理成PNG+ZIP/RAR的包，有办法按LZ的方法搞成HEVC+ZIP/RAR的包么，一个一个整实在太痛苦了~~

冰箱研会长

pluser 发表于 2020-8-15 09:21
积攒了好多小本子，都是下载后自己整理成PNG+ZIP/RAR的包，有办法按LZ的方法搞成HEVC+ZIP/RAR的包么，一个 ...

1. 
   
2. $YourPath = "D:\desktop" #在这里输入你的储存根路径 记得用powershell7.0+ 不然我也不知道能不能跑
   
3. #跑之前先测试
   
4. $YourOldArchFiles = Get-ChildItem -LiteralPath $YourPath -Include *.zip,*.rar,*.7z;
   
5. #递归获取目录下所有主流压缩文件
   
6. $YourOldArchFiles | ForEach-Object {
   
7.     #管道依次传递压缩包
   
8.     $EachPath = "$($_.Directory.FullName)\$($_.Basename)";
   
9.     #获取压缩包不带后缀的名字
   
10.     New-Item -Path $EachPath -ItemType Directory;
    
11.     #创建同名文件夹
    
12.     bandizip x -r -auo -o:"$EachPath" -target:auto $_.FullName;
    
13.     #将压缩包自动提取到同名文件夹内部, 可以加一个-y参数 不然应该会弹出很多框框
    
14.     $ImageFiles = Get-ChildItem -LiteralPath $EachPath -Include *.png,*.jpg,*.jpeg;
    
15.     #获取同名文件夹内图片文件
    
16.     $ImageFiles | ForEach-Object {
    
17.         vips heifsave $_.FullName "$($_.Directory.FullNameName)\$($_.Basename).heic" --Q 50;
    
18.         #调用libvips对图片文件进行处理, 1-100
    
19.     }
    
20. }
    

复制代码

不确定是否能跑, 我假设你的压缩包里面没有压缩包, 务必先小规模测试 需要最新版powershell和bandizip
把里面第一行的目录改成你的储存根目录
把文件拷贝到根目录命名为xxxx.ps1
然后在当前目录打开powershell 7.0

1. ./xxxxxx.ps1

复制代码

试试

顺便把压缩之后的图片打包其实意义不大, 压缩包指对未经压缩过的raw数据起很大作用, 对已经是非常极限压缩的hevc压缩其实效果不大.


████████带重新打包的版本
$YourPath = "D:\desktop" #在这里输入你的储存根路径 记得用powershell7.0+ 不然我也不知道能不能跑
#跑之前先测试
$YourOldArchFiles = Get-ChildItem -LiteralPath $YourPath -Include *.zip,*.rar,*.7z;
#递归获取目录下所有主流压缩文件
$YourOldArchFiles | ForEach-Object {
    #管道依次传递压缩包
    $EachPath = "$($_.Directory.FullName)\$($_.Basename)";
    #获取压缩包不带后缀的名字
    New-Item -Path $EachPath -ItemType Directory;
    #创建同名文件夹
    bandizip x -r -auo -o:"$EachPath" -target:auto $_.FullName;
    #将压缩包自动提取到同名文件夹内部, 可以加一个-y参数 不然应该会弹出很多框框
    $ImageFiles = Get-ChildItem -LiteralPath $EachPath -Include *.png,*.jpg,*.jpeg;
    #获取同名文件夹内图片文件
    $ImageFiles | ForEach-Object {
        vips heifsave $_.FullName "$($_.Directory.FullNameName)\$($_.Basename).heic" --Q 50;
        #调用libvips对图片文件进行处理, 1-100
    }
    bandizip c -y -r -l:0 "$($EachPath)-HEVC.7z" $EachPath;
}

pluser

冰箱研会长 发表于 2020-8-15 10:35
不确定是否能跑 务必先小规模测试 需要最新版powershell和bandizip
把里面第一行的目录改成你的储存根 ...

必须用BANDIZIP么，WINRAR可不可以？？
打包是因为用文件夹形式单个文件实在太多，并不利于磁盘健康，打包后用HONEYVIEW来读取其实也很快，600MB也就几秒钟准备时间而已。
谢谢LZ，晚上回家试试！

冰箱研会长

pluser 发表于 2020-8-15 10:40
必须用BANDIZIP么，WINRAR可不可以？？
打包是因为用文件夹形式单个文件实在太多，并不利于磁盘健康，打 ...

winrar如果有命令行工具的话可以替换 但是我没用过winrar 不熟悉相关工具 也不知道它的命令咋写
另外honeyview能不能读hevc还是未知数 > <

inflation

冰箱研会长 发表于 2020-8-14 19:24
今年我还是等等LCEVC
完全软件实现的编码升级, 应该年内就会发布.

LCEVC太邪道了，靠upsampling永远不可能在质量上和原生分辨率比，这一点做动画的压制组都很清楚的。

用HEVC编码存图片还有一个问题，就是不管源是什么类型，都会做chroma downsampling到4:2:0。这个问题在实景下还不明显，但如果图片中有锐利的边缘，那么会引入chroma aliasing。虽然从编码上讲是可以用YUV 4:4:4的，但解码器普遍不支持。这里的例子很明显了：https://netflixtechblog.com/avif ... -coding-b1d75675fe4

还有真要较真儿的话，所有RGB源的图片到YUV都会损失精度，因为转换并不是一一对应的。

冰箱研会长

inflation 发表于 2020-8-15 11:05
LCEVC太邪道了，靠upsampling永远不可能在质量上和原生分辨率比，这一点做动画的压制组都很清楚的。

用H ...

LCEVC不算是纯upsampling吧, 有点那种双层差分的感觉.

这里有个例子然后用的是非public编码器> < 没法实操
这个作者前两天刚发布了一个LCEVC x264 base的测试报告.

444的兼容性炸裂没得洗, 采样的问题...黑白的没事反正是4, 彩图的话就得掂量掂量了, 漫画问题不大.
目前最好的HEVC图片解码器是IOS444随便上 都能解码

YUV精度损失这也太较真了 这点精度损失无所谓了 (实在不行还可以8bit转10bit 虽然10bit更是兼容性炸裂

gdsdjcb

冰箱研会长 发表于 2020-8-15 08:16
第一张帖子(FFMPEG)是视觉无损的

是用yuv444p吗，设置参数Q有没有帮助？

冰箱研会长

gdsdjcb 发表于 2020-8-15 11:23
是用yuv444p吗，设置参数Q有没有帮助？

420就足够视觉无损了 Q没有帮助 > <

inflation

冰箱研会长 发表于 2020-8-14 22:22
LCEVC不算是纯upsampling吧, 有点那种双层差分的感觉.

这里有个例子然后用的是非public编码器> < 没法实 ...

我们组内压制时凡是涉及到YUV转换、色域转换之类的时候统一16bit操作的
而且HEVC 10bit才是标准吧，8bit很少有人用的。我们成品要做8bit的话还要有dithering和加噪点防色带

Aeroblast

顺手给随便搞的阅读器加了点私货，魔改了一下打包工具，结果意外顺利地能用……
我是不愿意随便压档案的（懒），不过这个源是抓日站Canvas的300+M的PNG，必须压一下于是就动手了

仍然不完善的阅读器&测试用档链接7天提取码: pxk7

inflation

这几天陆陆续续又看了一些关于图片编码上的文章，现在越发觉得Web上下一代图片标准会是JPEG XL而不是任何一种视频帧编码的格式。

因为JPEG XL本质上是三种不同的算法：第一种算法对应现有的JPEG图片，可以不引入二次损失的压缩这些存量数据（其他的有损压缩都需要先解码再压缩）。而且这一步骤是可逆的，可以从压缩后的JPEG XL文件中derive出原始的JPEG文件，原则上不支持JPEG XL格式的用户能把它直接当成JPEG。

第二种无损压缩算法对应PNG格式，来源是FILF，压缩率上比现有的webp无损高20%，这一块不是视频帧编码重视的，因此没什么可比性。
又因为JPEG XL也能存动画帧，即可以替代APNG和一部分GIF的应用（有损压缩动画直接用视频编码，这一块AVIF或HEIF更适合）。

第三种有损压缩算法来源是Google Pik和FULF，相当于更现代的JPEG，优点是编码速度。缺点是低码率下有跟JPEG一样的缺点，不如AVIF或HEIF。

20多年互联网积累下来的图片太多了，JPEG XL可以做到无缝升级这些已有的数据，相比与转向一种全新且没有向后兼容的编码格式，JPEG XL这种更保守的选择可能会更容易被广泛接受。

P.S. JPEG XL编码本身已经进入ISO的FDIS阶段，文件格式在DIS阶段，今年内应该会变成IS标准。
另外专利上，AV1虽然标榜自己是royalty-free，但视频编码历史上有太多submarine patent，很可能会有公司在AV1广泛使用后跳出来宣称自己有专利。AVIF本身也是从HEIF延伸出来的，真要追究Nokia也可能宣称专利，JPEG XL的标准要干净的多。

hanyuwei70

av1这个拉跨的编码性能实在是……另外VCB的正确称呼是VCB-S

Prushka

为啥不提webp和webm，好像用的人很多啊。虽然可能qq不怎么支持吧来自: iPhone客户端

yvev

Prushka 发表于 2020-8-18 09:48
为啥不提webp和webm，好像用的人很多啊。虽然可能qq不怎么支持吧

EP1提过了吧

—— 来自 nubia NX523J_V1, Android 5.1.1上的 S1Next-鹅版 v2.1.2

inflation

Prushka 发表于 2020-8-17 20:48
为啥不提webp和webm，好像用的人很多啊。虽然可能qq不怎么支持吧

已经是上个时代的技术了，前几年Google一直在宣传能完全取代JPEG和PNG，结果嘛现在大家都知道了。其实腾讯云早就利用上webp了，QQ不支持属于其他原因。

Apple即将在Safari 14加入webp支持，可想而知为什么之前没人用。只要有一个大平台不支持，那么内容提供商就得继续提供老格式的，这样永远不可能取代这些老东西了。

Prushka

inflation 发表于 2020-8-18 11:05
已经是上个时代的技术了，前几年Google一直在宣传能完全取代JPEG和PNG，结果嘛现在大家都知道了。其实腾 ...

PCQQ的emoji还是图片也是为了给win7做兼容性吧，哎

凤舞夜月

虽然知道很高端看不懂，特别是自己属于小白，就只能支持了。

冰箱研会长

ohi 发表于 2020-8-18 23:18
试了一下好像不支持gif？

https://github.com/libvips/libvips/issues/235

动态的HEVC = HEVC视频
不过你说的对, 包括webp在内, 绝大多数新格式对gif这种动态图片都是 "技术上支持",
实际上不支持, 因为说白了动态的HEVC/VP9/AV1不就是没有声音的相应视频么, 也没有什么人有动力搞.
于是(因果关系存疑)很多GIF的"替代" 都需要用特定的工具制作, webp就是谷歌的cwebp工具包, heic就是苹果摄像机的动态模式...

inflation

冰箱研会长 发表于 2020-8-24 02:47
今天build了一下win10下可以用的二进制
链接: https://pan.baidu.com/s/1RmvLym23qpWq1B-mN-bWjg 提取码:  ...

JPEG XL 有损编码有两种模式，一种是传统的DCT Tree，一种是新的Modular模式，即无损编码的算法。我测试的结果DCT编码速度显著的快，但对于computer generated contents效果不行，低码率下会出现与JPEG类似的artifacts。Modular模式较慢，更适合这类型的图片。

然而AV1的AVIF不仅在质量上甚至速度上都能比Modular模式的JPEG XL表现好（
这个格式的优点还是在于解码和向后兼容性。