西西河

主题:【原创】JPEG2000在三维图像中的应用 -- 东方射日

共:💬14 🌺13
全看树展主题 · 分页首页 上页
/ 1
下页 末页
家园 【原创】JPEG2000在三维图像中的应用

JPEG2000是基于小波变换(DWT)的图像压缩标准,该标准的制定工作始于1997年3月,作为核心的图像编码系统在2000年12月成为国际标准。国际标准化组织(ISO)发布的JPEG2000标准的文档代码为ISO/IEC15444-1:2000。在2004年更被确立为视频压缩标准,即ISO/IEC 15444-2和ITU-T Rec. T.800。

JPEG2000是未来取代JPEG(基于离散余弦变换,DCT)的下一代图像压缩标准和取代H.264(基于离散余弦变换,DCT)的下一代视频标准。2005年初,DCI宣布采用JPEG 2000作为数字影院的标准格式。

相比较于JPEG,JPEG2000有非常多的优点,比如:

* 更高的压缩比

* 不会产生马赛克失真

* 一个码流里同时支持无损压缩和多级有损压缩

* 局部压缩/解压缩

* 多通道信息传送

上述优点的具体讨论我们就暂时不展开,有机会我在随后的博文中可能进行进一步的探讨。

单就多通道信息传送来讲,我们可以有什么应用呢?

我们知道在JPEG中只支持三个通道即RGB的信号传输,也就是说JPEG只能支持平面的彩色图像。而在BMP格式中,我们有四个通道ARGB,通常我们用alpha通道来存储透明度,这样,同样的图片我们可以有更丰富的显示方式。

到了JPEG2000,我们知道,在标准上,一帧图像最多支持256个通道。那么我们可以利用这些通道来存储那些信息呢?当然ARGB我们可以轻松支持,CMYK模式也没有问题。

不过联系到游戏中使用的图像技术,我突然想到,是否可以利用这些通道来存储纷繁复杂的三维信息呢?

我们知道,在游戏的三维建模中,我们使用各种贴图(map)来存储三维信息,比如法线贴图(normal map);反射贴图(reflection map);颜色贴图(color map);高光贴图(Specula map);AO贴图(又称环境闭塞贴图,Ambient Occlusion map),高亮贴图(Gloss map);辉光贴图(Glow map);视差贴图(Parallax Map)等等。为了达到一个逼真的效果,我们往往在一个物件上需要大量的贴图,而有些贴图自身就需要多个通道,例如,法线贴图需要三个通道来存储三个方向的法线信息,发射贴图也需要三个通道来存储分别对于RGB三种颜色的反射率。林林总总,这导致一些角色或物件的相关文件有很多,体积巨大。

更不幸的是,为了保证效果的逼真,通常我们在游戏中对于这些贴图采用的无损压缩。

如果我们使用jpeg2000来存储这些三维信息,我能想到的好处就有以下几点:

1. 单一文件对单一物件:

jpeg2000的多达256个通道可以轻松存储现有的各种贴图,这样单一物件对应单一文件,在资源管理和组织上带来很大的便利。也许你会说虽然我们有那么多贴图,但是很多情况下,我们并不需要用到它们所有,jpeg2000单一文件结构是否意味着即使我们仅仅需要其中的某一个通道,我们也不得不打开所有通道呢?如果我们熟悉jpeg2000的文件结构,我们知道jpeg2000的每个component都有特定的marker和长度标志,我们可以很轻松跳过不需要通道。所以这点担心是不必要的。

2. 资源文件体积缩小:

我们知道jpeg2000相比于jpeg的一个非常大的优点就是压缩率高30%。对于大量的资源文件,这个30%额外的压缩率将是相当可观的。联系到现在游戏中,主要的瓶颈在于网络传输的速率,文件体积的缩小,对于网络应用意义尤其重大。

3. 同时支持有损和无损模式:

jpeg2000应用多级DWT,可以在一个码流中同时支持无损和有损压缩。这点在游戏中也是很有意义的。在游戏中,尤其在角色拉进的时候,为了显示精细的细节信息,我们要求相关的贴图必须是无损压缩的。可是在绝大多数情况下,角色在场景中可能只有1寸高,可是此时我们在应用贴图时,也不得不应用了无损的贴图信息,这带来了运算和存储的浪费。可是应用jpeg2000,就可以实时根据需要来决定解压缩的精确度。比如采用5级DWT,如果我们显示的角色只是原始尺寸的256分之一或更小,我们只需要解压第一级,此时的尺寸是原始大小1/256,就可以停止而不必进行无益的多余计算。当然如果超过1/256,我们可以进行第二级解压,得到原始尺寸的1/64的贴图。同样第三级,第四级,我们分别得到1/16和1/4的信息,仅仅在需要的时候,我们进行所有5级的解压缩。

4. ROI特性天然支持雾化效果:

经常在游戏中,一个场景或一个角色,我们会需要进行一些雾化处理。例如为了模拟聚焦的效果,在画面中央显示清晰的图像,而在边缘进行雾化。或者为了突出角 色面部,我们给角色面部给出清晰的特写,而角色的其他部分进行雾化。现在的做法通常是先计算清晰的效果,然后根据距离或位置,对相应部分进行雾化。这里, 事实上也浪费了一些额外的运算。在jpeg2000中有一个非常好的特性ROI(Regions of Interest), 即提供一个能让用户控制的、可选择分辨率的影像数据。你可以指定感兴趣区域,在这些区域,你可以在恢复时指定特定的解压缩要求。这是因为小波在空间和频率 域上具有局域性,要完全恢复图像中的某个局部,其他部分并不需要所有编码都被精确解码。这样在进行雾化处理时就可以不需要浪费处理器时间进行额外的运算。还有一个令人惊喜的好处是jpeg2000不同于jpeg,在信息丢失,画面失真时,它不会产生马赛克现象。典型的jpeg2000失真是边缘的虚化,这个特性不正是我们雾化所需要的效果吗?

不过由于jpeg2000是一个很新的技术很复杂的算法,在现有的3D引擎中并没有广泛的应用。不过我相信以上这些优点,应该会让那些3D引擎的厂家考虑在下一代产品中应用jpeg2000。

家园 我尝试过用过JASPER,解压压缩J2K要很长时间.游戏

对时间要求很高,不知J2K能否适应?

家园 所以说是下一代应用啊

j2k的算法太复杂,属于计算密集型的应用

jasper不好,是开源的,甚至没有用到多线程,你可以试试跑个100遍,如果你的电脑是多核的你可以看到只有一个CPU的利用率到80%左右。

据我测试,解压一个1920×1080的高清图像,在4核2.4G的电脑上,jasper要1100ms。

不过算法改进和多线程的应用能够大大提高效率,同样的图用kakadu show在同样电脑上只需要66ms。四个CPU利用率都可以跑到85%。

我现在做的项目是继续优化,现在能做到52ms,四个CPU利用率都可以跑到95%。

这样可以满足大多数对时间不敏感或者对体积比对实时性要求更高的需求,例如文档的内嵌图像,web页面,医疗高清图像等。

不过距离游戏中的实时应用还有很大差距,在CPU处理能力大幅提高前,这还只能是下一代的应用。

家园 1920*1068图象,能优化到55ms很不错了.
家园 同样分辨率的图像编码需要多少时间?
家园 能否解释一下多通道到底什么意思?

有没有一个实例? 谢先!

家园 差不多

我现在做的是解码的优化,不过jpeg2000的编码和解码算法复杂度基本一样,所以可以预见编码的时间应该大致相同。

家园 通道就是图像中记录一种属性的分量的集合

简而言之,通道(channel)就是图像中记录一种属性的分量的集合。

现在的计算机绘图,通常采用三原色合成,即RGB三种颜色。在一副全彩的图像中,RGB分别占据不同的片段或比特位,我们称这些记录RGB信息的集合称为三个通道。至于灰度图像则只记载明暗信息,丢失了各个颜色信息,此时仅需要一个通道。

在32位的位图中,RGB如果分别有256级色彩,即各占据8比特位,那么我们还有富余的8个比特。此时我们可以放弃这8个比特位,这样这幅图像就是三个通道。不过我们也可以利用这8个比特位来存储一些额外的信息,使之成为4通道图像。

例如我们可以用这个通道来记录图像的透明度信息,通常我们称之为alpha通道,这样,这幅图像就是一个ARGB的4通道图像。这种技术在现在已经非常非常普遍了,例如很多弹出窗口的广告,你会发现图像的边缘不是平直的,比如是一个游戏人物的轮廓,这就是利用了alpha通道。我们将无需显示的部分alpha设为0,即完全透明。计算机在显示图像的时候,利用这个透明度来将图像和背景融合,这样就能够出显示不规则边缘的图像。当然要部分半透明也是很容易实现的。

家园 不一定非的用cpu

如果用gpu来解码,就可以显著的提高性能。我最近就在用gpu给video做实时解码,效果很好。

对于这种解码计算,gpu比cpu有更多的优势。

家园 说的对啊

现在做的就是部分用GPU解码,比如DWT,它是并行运算的,很方便移植到GPU上。

不过对于T1,由于有太多的if-else,各个块的分支都不相同,GPU解码的效率还不如CPU

家园 谢谢回答!我想知道jpeg2000里的通道是如何

定义的?它和YCbCr的图像格式有什么关系?

家园 谢。其它问题。

分辨率和解码时间是什么关系?线性,指数?

家园 不太清楚

老实说,这个问题我不太了解,要看标准是否有定义

现在做的基本上是约定的,也就是说各个compoments具体的信息是编解码双方自己约定。

家园 算法复杂度和图像面积线性关系,和分辨率就是平方关系了
全看树展主题 · 分页首页 上页
/ 1
下页 末页


有趣有益,互惠互利;开阔视野,博采众长。
虚拟的网络,真实的人。天南地北客,相逢皆朋友

Copyright © cchere 西西河