lwa190212 发表于 2020-5-3 20:16
网点通常用来模拟特定的灰度，换成灰度也不会造成观感上的差异
然后网点会在扫描的时候因为采样率问题出 ...
哈哈哈 咱俩看法不太一样, 我是绝对不能忍受网点丢失的. 要是网点丢失了就会觉得 "啊, 我在看被压缩过的漫画了" 贼难受.
不过你说的这个想法 我第一时间想到是做一个高斯模糊, Imagemagick 有进行高斯模糊的参数 你可以顺着这个关键词找找看
冰箱研会长 发表于 2020-5-3 20:44
哈哈哈 咱俩看法不太一样, 我是绝对不能忍受网点丢失的. 要是网点丢失了就会觉得 "啊, 我在看被压缩过的 ...
常见的卷积相关的算法我都试过了，频率域的处理也试过一些，结果上说都不理想
网点小的话在屏幕上看，遇到没有摩尔纹处理的缩放算法就直接没法看了，用了去摩尔纹的滤镜都会糊一些
自己处理网点可以做到画面清晰锐利，应该是不会有常见的jpg高压过的图片的那种感觉的，不过精力代价是不可接受的了
扫描出来的图
黑白漫画的网点属于正常的网点，一般要保留。
彩色·图片的网点属于墨点，一般要模糊处理吧。
可能不太会用PowerShell，我配完运行啥错都没报，但就是没反应。
自己敲命令试了一下，-crf 11的时候比webp还大，30的时候确实只有30%大小，但是画质已经肉眼可见的明显劣化了。
能否提供一些漫画对比的例子。
太复杂了。。。作为渣渣只能等一个傻瓜化工具到手，再慢慢整理，然后老习惯打包成ZIP了。。。
冰箱研会长 发表于 2020-5-3 09:55
你看眼我刚更新的 这里用的不是视频编码的帧对比技术 是同帧内的分块压缩 ...
我看了一下不过完全不懂，这里的预测是指图像相邻的像素之间有很大的可能颜色相同吗？
这倒提醒了我，是不是可以考虑将大量图片视为一个视频的不同帧进行进一步的压缩？这样还可以进一步利用多张图片之间的连续性。
楼主牛逼
如果主要是日式黑白漫画的话就没必要这么复杂……
综合效率和兼容性最好的压缩方法是16级灰度的PNG格式。黑白漫画里灰度过渡一般是由网点构成的，所以从256级灰度减少到16级对画面的影响非常小，变成4位色后对于PNG压缩也变得更加有利。这样既能够完美保留所以的网点和线条等高频细节，而且也不会像其它有损压缩那样引入量化造成的噪音
以eh的本子为例，3000高度的扫图漫画，一页在1MB左右，1500高度的电子版漫画，一页300KB左右
虽然看不明白但是感觉可以学一下
—— 来自 HUAWEI LYA-AL00, Android 10上的 S1Next-鹅版 v2.1.0-play
毕竟上次折腾已经隔了很久了，刚又去搜索了下关于这个网点的算法，发现已经有机器学习的方法了
Inverse Halftoning Through Structure-Aware Deep Convolutional Neural Networks
而且很早以前也有非机器学习的传统算法，不知道为何以前没有找到，明明搜的关键词都是halftone inverse
http://www.cse.cuhk.edu.hk/~leojia/projects/rollguidance/results_dehalftone.html
不过我觉得ls用低bit保留网点的思路也很不错，学习了
但是HEIC兼容性不如WEBP吧，除了苹果自家软硬件强行不支持webp，heic基本就苹果还在主导，大多数web漫画格式本身都是webp了。
楼主的对比两者都是基于有损压缩算法吗？如果使用无损算法HEVC对比VP8L的情况会如何。
不过现在都是TB级存储，漫画这点空间还是无损优先吧。
echoIII 发表于 2020-5-3 22:33
可能不太会用PowerShell，我配完运行啥错都没报，但就是没反应。
自己敲命令试了一下，-crf 11的时候比webp ...
没反应 不应该啊 函数一共四个参数 一个路径 加双引号 \一个质量 0到1 \ 一个原格式 webp或者其他什么东西 不加点\一个目标格式 heic或者其他什么东西 也不加点
对比图我待会找找
SkywalkerJi 发表于 2020-5-4 01:51
但是HEIC兼容性不如WEBP吧，除了苹果自家软硬件强行不支持webp，heic基本就苹果还在主导，大多数web漫画格 ...
兼容性问题也就那样吧 关于对比我待会统一搞个对比出来
lwa190212 发表于 2020-5-3 20:51
常见的卷积相关的算法我都试过了，频率域的处理也试过一些，结果上说都不理想
网点小的话在屏幕上看，遇 ...
我记得我以前处理扫描时的摩尔纹是在gimp上fft以后抹平四周的高频spike再fft回来
但是网格第一不是全图的纹理，其次不是方的，最后在频域上可能兼有高频和低频信号，而且最后要追求的是把区域换成网格区域的平均灰度，感觉选取网格区直接计算灰度总和再平均是不是比较合适
所以问题其实是如何检测并分类一张图的网格区域，一个想法是检测每个像素是否可能是某个网格的中心，然后再floodfill，不过感觉效率有点低
echoIII 发表于 2020-5-3 22:33
可能不太会用PowerShell，我配完运行啥错都没报，但就是没反应。
自己敲命令试了一下，-crf 11的时候比webp ...
我放了一组对比 我处理200张异世界叔叔扫图 crf0的时候就有5%左右的压缩 10的时候已经只有一半大了 这时候我在2000%放大模式下很难找到劣化. crt20的时候压缩到了1/4 低频区丢失了一些信息 然而高频纹理都得到了保留 crf30的时候已经只有十分之一大小了. 与其同时webp无损到85%都要比原图还大 45%的时候和crf20体积差不多 效果也差不多.
SkywalkerJi 发表于 2020-5-4 01:51
但是HEIC兼容性不如WEBP吧，除了苹果自家软硬件强行不支持webp，heic基本就苹果还在主导，大多数web漫画格 ...
我放了对比图 无损hevc体积减少5% vp8反而上升了10%左右...
plusSharp 发表于 2020-5-3 23:05
我看了一下不过完全不懂，这里的预测是指图像相邻的像素之间有很大的可能颜色相同吗？ ...
是的 因为图片本身不是色块很多吗 这里就先预设几组公式 用周围的像素来计算压缩区域的像素.
然后我们就不需要记载像素的具体信息 只需要记载 "用什么样的公式能计算出效果最好的像素"就可以了
YoumuChan 发表于 2020-5-4 09:27
我记得我以前处理扫描时的摩尔纹是在gimp上fft以后抹平四周的高频spike再fft回来
但是网格第一不是全图的 ...
网格的fft特征还挺明显的，就下面图中除了中央以外的那几个亮点显然都是，毕竟一般的图片很少会在这种地方有这么高的能量
https://p.sda1.dev/0/c75069250b7520becd31a0fb079b49a4/chrome_2020-05-04_09-46-08.jpg
不过我对频域上如何做到平滑地抹去这些能量没有经验，粗暴地抹除虽然能去掉大部分的网点，但也会增加不少其他的劣化，以及ifft回去后数值变化了好几个数量级，那还得量化到256级和修正对比度到与原图没有视觉上的偏差就很麻烦
不过见我51L，其实还有一些现成的算法可以用，我等有精力折腾的时候再试试了
冰箱研会长 发表于 2020-5-4 09:53
是的 因为图片本身不是色块很多吗 这里就先预设几组公式 用周围的像素来计算压缩区域的像素.
然后我们就 ...
我今天又查了一下png相关资料，其中提到png使用lz77压缩，我不明白为什么不使用Huffman 编码，因为一般来说图片中不同颜色出现的频率相差很大，很适合用Huffman
lwa190212 发表于 2020-5-4 09:55
网格的fft特征还挺明显的，就下面图中除了中央以外的那几个亮点显然都是，毕竟一般的图片很少会在这种地 ...
主要是我觉得网纹in general是比漫画要难很多的...所以在考虑一些没那么general的传统算法
本帖最后由 echoIII 于 2020-5-4 16:21 编辑
冰箱研会长 发表于 2020-5-4 09:50
我放了一组对比 我处理200张异世界叔叔扫图 crf0的时候就有5%左右的压缩 10的时候已经只有一半大了 这时 ...
我是拿日站DL版来测试的。
正版的扫图本身已经处理得很小，一本1200纵的大概在40MB左右，可以说它是优化容量，也可以说它是劣化质量（相比之下，个人扫图一般要大一倍以上），但是目前最容易获得的就是DL版（买了电子书DeDRM即可，钱空网盘里现在大量的都是DL版）。
漫画现在也是TB数量级，减小容量是有必要的，jpeg这种上古格式确实该丢到垃圾堆里。新格式里webp目前大致已普及，所以我之前的都压成webp了，webp（有损）质量值100的情况下体积大概是jpeg的60%，这时候来回切换比较，肉眼看不到区别。heic毕竟吃亏在支持软件少，如果没有显著优于webp的质量体积比还是没有洗的动力。
另外heic在win10下可以用传家宝MangaMeeya，安装SusiePlugin
https://github.com/gameclamp/MangaMeeyaAssociations
能调用WindowsCodecs.dll来解码，然后安装了首帖上说的heic的两个解码器就能看了。
MM虽然死了n年，但作为漫画阅读软件，还是远胜单纯的看图软件。
iOS我给Comicshare写信提要求了，大家可以也去提，Comicshare更新勤快还是挺有可能支持的，毕竟很早就支持webp，这点比comicglass强。
echoIII 发表于 2020-5-4 16:18
我是拿日站DL版来测试的。
正版的扫图本身已经处理得很小，一本1200纵的大概在40MB左右，可以说它是优化容 ...
我给好多ios开发者发过邮件...除非我夸他们 不然他们都不回复我....
dl版啊 说起来我之前买了三本"剑世界2.5" 看都没看就转成heic了 现在也许可以拿来对比一试.
本帖最后由 yguygyu 于 2020-5-4 18:29 编辑
我心想你一个 -pix_fmt yuv420p，uv 平面都半采样了，谈什么无损压缩啊。
无损怎么说也至少 yuv444 搞上啊。
视频压制组不用 yuv444 是因为拿到的片源就是 yuv420，本身就是半采样之后的，而很多时候在做预处理的时，都没有做必须保留 uv 平面拉伸后的分辨率的处理。
但是你漫画的图源如果是扫图或者是 png，bmp 的话，很有可能依旧保有原有的 uv 信息。
在这里用 yuv420 的话，就把 uv 平面的信息丢掉 3/4 了。
本帖最后由 冰箱研会长 于 2020-5-4 19:26 编辑
yguygyu 发表于 2020-5-4 18:12
我心想你一个 -pix_fmt yuv420p，uv 平面都半采样了，谈什么无损压缩啊。
无损怎么说也至少 yuv444 搞上啊 ...
啊啊啊啊啊啊啊啊啊啊
这里是我的锅
一路420用过来了 这里没注意到 我待会设置好参数之后换成444写到主楼里
草 试了一下 我手头唯一能越读全YUV采样的heic的只有IOS.....
事实上就连10bit的420我都仅仅找到xnview这一家支持的...
在编码heic这件事上, 可以用444, 但问题就是兼容性爆炸
不过反正是黑白图片 没关系的
(md 想把三楼回复合并到一楼里 才想起来s1不能删自己的楼...)
本帖最后由 冰箱研会长 于 2020-5-4 19:26 编辑
yguygyu 发表于 2020-5-4 18:12
我心想你一个 -pix_fmt yuv420p，uv 平面都半采样了，谈什么无损压缩啊。
无损怎么说也至少 yuv444 搞上啊 ...%合并到了上个回复%
本帖最后由 冰箱研会长 于 2020-5-4 19:26 编辑
yguygyu 发表于 2020-5-4 18:12
我心想你一个 -pix_fmt yuv420p，uv 平面都半采样了，谈什么无损压缩啊。
无损怎么说也至少 yuv444 搞上啊 ...
%合并到了上上个回复%
草 444采样现在windows现在还有这么多兼容性问题么，另一个人是mac全家桶，但是我自己主要用windows还有onedrive，难受了
冰箱研会长 发表于 2020-5-4 09:51
我放了对比图 无损hevc体积减少5% vp8反而上升了10%左右...
感谢测试。
你是用JPG原图再压缩WEBP的吗？
用扫描仪直出的TIFF、bmp压缩会有区别么。这一次压缩感觉比PNG/jpg二压更重要。
冰箱研会长 发表于 2020-5-4 07:55
没反应 不应该啊 函数一共四个参数 一个路径 加双引号 \一个质量 0到1 \ 一个原格式 webp或者其他什么东 ...
你改一下帖子里的“用法如下
在powershell中输入
imgconv "图片所在的目标文件夹" .原图格式 .目标格式”
丢了个参数。。
难怪我运行了没反应
我找了本漫画测了一下
37M origin（jpeg 90%）
27M jpeg（jpeg 80%）
22M webp（80%）
32M heic_crf10
18M heic_crf20
8.5M heic_crf30
91M png（拿jpeg转的，仅作为体积的参考）
用氪金狗眼比对了一下
heic_crf20跟webp80%大致持平，
在400%下相比原始看不到明显劣化
应该说相比原始图片像素点都有变化，但是黑白漫画区别很小，一些像素点的变化甚至不好说是好是坏，总体感觉没有明显劣化
在彩页封面上，heic_crf20优于webp80%
即便是heic_crf30，在100%下都看不出明显劣化，但是200%就能明显看出
总的来说heic优于webp大概没问题，但我觉得差距在20~30%左右。
另外heic会有1个像素的偏移，可能会逼死强迫症
真要用来压制漫画的话，黑白漫画可以用更激进的参数，但是考虑到一般都是黑白彩色混杂懒得去判别，所以综合考虑的话crf20左右较为适合
SkywalkerJi 发表于 2020-5-5 00:09
感谢测试。
你是用JPG原图再压缩WEBP的吗？
用扫描仪直出的TIFF、bmp压缩会有区别么。这一次压缩感觉比PN ...
实不相瞒 我现在手头一份tiff都没有了... 最多从jpg转出tiff 你要是有直接出的tiff 可以提供一份
echoIII 发表于 2020-5-5 00:28
你改一下帖子里的“用法如下
在powershell中输入
嗯 感谢debug....
顺便这个一个像素偏移主要是因为采用了420采样, yuv空间的采样除了444以外都是隔行进行的. 我甚至怀疑yuv444在逻辑上也是隔行的, 虽然在数据上是1对1采样, 但是实际操作中估计还是不允许输入奇数大小的图像.
遇到奇数大小只能剪裁或者铺一层像素
这里用的两个函数 imgconv fimgconv 前者用其他软件增加一个像素后者直接在原图上去掉一列像素.
前者对大小的修改是预处理 后者则是流式的 所以fimgconv快很多. 漫画这种一边都有页边距, 直接删一列像素就可了.
你webp用什么编码的? 我用的Imagemagick 85%体积都会增加....
国区Microsoft Store是有HEVC插件的，只是搜索不到，通常会在安装驱动程序后自动安装
https://www.microsoft.com/zh-cn/p/hevc-video-extensions-from-device-manufacturer/9n4wgh0z6vhq
冰箱研会长 发表于 2020-5-4 18:35
啊啊啊啊啊啊啊啊啊啊
这里是我的锅
一路420用过来了 这里没注意到 我待会设置好参数之后换成444写到主楼 ...
黑白图片的话理论上可以直接舍弃掉 uv 信息直接编码个 Y800 出来，HEVC 编码也是支持的
只存了 luminance 信息，体积更小
ffmpeg 的选项应该是 -pix_fmt gray
只不过估计兼容性也是爆炸，没几个软件能解码
本帖最后由 SmterC 于 2021-1-15 11:25 编辑
试了一下，安卓上用的本地漫画软件comic screen支持webp但不支持heic。毕竟webp是谷歌亲儿子吧，大部分安卓应用下webp都没有兼容问题。
喜大普奔，把后缀名从heic改成webp后就能看了，看来是系统已经支持了，只是漫画软件没做适配
不知道有没有支持heic的漫画软件推荐……我这里也提供一下我之前写的一个Python小脚本，用来批量转换漫画到webp格式的，也算是安卓用户暂时的替代方案吧。毕竟是自用的，代码水平臭还请轻拍。
import subprocess, multiprocessing, time, locale, time, os.path, os, re
from PIL import Image
def get_filename(path):
name = []
filetypes = ['jpg', 'png', 'JPG', 'PNG', 'jpeg', 'JPEG']
for root, dirs, files in os.walk(path):
for file in files:
if True in :
wholePath = os.path.join(root, file)
name.append(wholePath)
print('找到%d个可以转换的图片' % len(name))
return name
def ruuun(kksk):
p = subprocess.Popen(kksk)
p.wait()
# print(kksk)
if __name__ == '__main__':
print(' _ __ __ ___ _____ ')
print(' | | /| / /___/ / / _ \/|//___ _ ______ _ ___ _')
print(' | |/ |/ // -_)/ _ \ / ___/ / /|_/ // _ `// _ \/ _ `// _ `/')
print(' |__/|__/ \__//_.__//_/ /_//_/ \_,_//_//_/\_, / \_,_/ ')
print(' /___/ \t ver 2.0')
path = input('输入想要遍历的文件夹:(默认空)')
# filetype = input('想要转换的图片格式(png、jpg,默认jpg):')
loss = input('是否无损压缩？\n\t输入任意值无损\t默认有损:')
q = input('转换质量(0~100，默认85):')
pre = input('输入图片类型\n\t漫画为0，照片为1，人像为2，默认为漫画:')
limit = input('有无希望图片压缩达到的大小限制？以kb为单位:')
resize = input('图片的尺寸限制?:')
# wait = input('每4个任务后的等待时间:')
startFlag = input('开始执行(y/n):')
if path.strip() == '':
path = './'
# if filetype.strip() == '':
# filetype = 'jpg'
if q.strip() == '':
q = '85'
q = '-q ' + q
if loss.strip() != '':
loss = '-lossless'
q = ''
# wait = 5
if pre.strip() == '':
preset = 'drawing'
if pre.strip() == '0':
preset = 'drawing'
if pre.strip() == '1':
preset = 'photo'
if pre.strip() == '2':
preset = 'picture'
if limit.strip():
li = eval(limit) * 1000
limit = '-size %d -pass 10' % li
if limit.strip() == '':
limit = ''
if resize.strip() == '':
resize = False
else:
resize = True
# if wait.strip() == '':
# wait = '4'
if not startFlag.lower() == 'y':
print('执行终止')
exit()
files = get_filename(path)
# slc = 0
pool = multiprocessing.Pool(8)
for file in files:
pos = file.rfind("\\")
os.makedirs(os.path.join('./result/', file[:pos]), exist_ok=True)
resultpath = file.replace(re.findall('\.+', file)[-1], '.webp')
existVerify = os.path.exists('./result/' + resultpath)
if existVerify:
zerobitVerif = os.path.getsize('./result/' + resultpath)
if zerobitVerif != 0:
continue
resize_config = ''
if resize:
img = Image.open(file)
img_size = img.size
if (img_size > 1080 and img_size > 1920) or (img_size > 1080 and img_size > 1920):
beishu = max(round(img_size / 1080), round(img_size / 1920))
resize_config = "-resize %s %s" % (img_size / beishu, img_size / beishu)
kksk = 'cwebp -preset %s %s %s \"%s\" -m 6 %s -sharp_yuv -metadata all %s -short -af -mt -o \"./result/%s\"' % (
preset, loss, q, file, limit, resize_config, resultpath)
# print(kksk)
pool.apply_async(func=ruuun, args=(kksk,))
# slc = slc + 1
# if slc == 4:
# time.sleep(int(wait))
# slc = 0
pool.close()
pool.join()
print('全部完成,一共转换了%d张图片' % len(files))
exit = input('ds')
这段代码本质就是调用环境变量里的cwebp编码器来转换遍历文件到result文件夹，所以需要先从Google开发者官网下载个webptools放环境变量里。
因为之前用Honeyview自带的格式转换转换到webp，发现结果和官方提供的最新编码器还是有点差距的，所以还是建议去下个最新的编码器来压缩比较好。
代码写的烂，所以只能遍历这个py文件同级或以下的目录，建议放到漫画根目录。
有口皆悲 发表于 2020-5-5 20:46
安装前还要先把系统设置里的区域切换成美国。。
不需要吧，我这边就可以直接装
https://i.loli.net/2020/05/05/iJtADCvU7NGMxgy.png
有口皆悲 发表于 2020-5-5 21:59
可能你之前已经购买过了吧。我不改区域点按钮没反应。
多点几次试试，巨硬商店就是这样的，经常抽风
另外这个是装了DCH版核显驱动后自动下载，直接加进账户里的，没有手动下载过
—— 来自 HUAWEI NXT-TL00, Android 8.0.0上的 S1Next-鹅版 v2.2.2
本帖最后由 lwa190212 于 2020-5-6 03:36 编辑
冰箱研会长 发表于 2020-5-5 07:00
嗯 感谢debug....
顺便这个一个像素偏移主要是因为采用了420采样, yuv空间的采样除了444以外都是隔行进行 ...
yuv444可以奇数输入：
ffmpeg -i "R:\_\0.bmp" -y -c libx265 -x265-params lossless=1 -pix_fmt yuv444p -f hevc "R:\_\0.hvc"
Input #0, bmp_pipe, from 'R:\_\0.bmp':
Duration: N/A, bitrate: N/A
Stream #0:0: Video: bmp, bgr24, 799x501, 25 tbr, 25 tbn, 25 tbc
Stream mapping:
Stream #0:0 -> #0:0 (bmp (native) -> hevc (libx265))
Press to stop, [?] for help
x265 : HEVC encoder version 3.2+6-f46aa2bc1c34
x265 : build info 8bit+10bit
x265 : using cpu capabilities: MMX2 SSE2Fast LZCNT SSSE3 SSE4.2 AVX FMA3 BMI2 AVX2
x265 : halving the quality when psy-rd is enabled for 444 input. Setting cbQpOffset = 6 and crQpOffset = 6
x265 : Main 4:4:4 profile, Level-8.5 (Main tier)
x265 : Thread pool created using 12 threads
x265 : Slices : 1
x265 : frame threads / pool features : 3 / wpp(8 rows)
x265 : Source height < 720p; disabling lookahead-slices
x265 : Coding QT: max CU size, min CU size : 64 / 8
x265 : Residual QT: max TU size, max depth : 32 / 1 inter / 1 intra
x265 : ME / range / subpel / merge : hex / 57 / 2 / 3
x265 : Keyframe min / max / scenecut / bias: 25 / 250 / 40 / 5.00
x265 : Cb/Cr QP Offset : 6 / 6
x265 : Lookahead / bframes / badapt : 20 / 4 / 2
x265 : b-pyramid / weightp / weightb : 1 / 1 / 0
x265 : References / ref-limitcu / depth: 3 / off / on
x265 : Rate Control : Lossless
x265 : tools: rd=3 psy-rd=2.00 early-skip rskip signhide tmvp b-intra
x265 : tools: strong-intra-smoothing deblock sao
Output #0, hevc, to 'R:\_\0.hvc':
Metadata:
encoder : Lavf58.34.101
Stream #0:0: Video: hevc (libx265), yuv444p, 799x501, q=2-31, 25 fps, 25 tbn, 25 tbc
Metadata:
encoder : Lavc58.60.100 libx265
Side data:
cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: N/A
frame= 1 fps=0.0 q=-0.0 Lsize= 88kB time=00:00:00.04 bitrate=17930.0kbits/s speed=0.271x
video:88kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.000000%
x265 : frame I: 1, Avg QP:4.00kb/s: 17516.60
x265 : consecutive B-frames: 100.0% 0.0% 0.0% 0.0% 0.0%
x265 : lossless compression ratio 4.57::1
yuv444其实对grayscale图像不会比yuv420增加多少容量，毕竟是hevc帧间编码处理全0数据而已，但是win的解码不支持yuv444
pix_fmt还可选gray，当然win的解码也不会支持的
