实现图片ETC+Alpha分离

目录

ETC纹理压缩格式

ETC1:它是一种为感知质量设计的有损算法,其依据是人眼对亮度改变的反应要高于色度改变,遗憾的是ETC1不支持透明。

ETC2:ETC2是ETC1的扩张,向后兼容ETC1,对RGB的压缩质量更好,并且支持透明通道。

原理

  • 目前ETC2压缩格式在OpenGL ES 3.0和OpenGL 4.3上才要求支持,然而目前很多设备只支持OpenGL ES 2.0,所以为了兼容大部分Android设备,并且实现图片压缩,减少包资源大小,所以采用将ARGB格式Texture分离成RGB Texture和Alpha Texture,并均进行ETC压缩。(边长需要POT,2的幂),通过运行时刻进行合并。

步骤

  • 将Texture丢进TexturePacker中,设置好参数后输出,分别得到tga文件和txt文件。

这里写图片描述

  • 将Tga文件丢进PS中。

    • 选择通道,删除Alpha 1通道,保存命名为后缀_RGB文件,此为RGB Texture。

    • 回滚之前Tga文件,选择‘分离通道’,保存分离后的Alpha通道为后缀_Alpha文件,此为Alpha Texture。

<think>好的,用户的问题是关于Unity图片压缩的,特别是将一张150x226的NPOT(非二次幂)RGBA sRGB图片转换为RGB Crunched ETC格式后,为什么可以减少文件大小,并想了解整个转换过程中的变化。首先,我需要回忆Unity图片压缩的相关知识,尤其是ETC压缩和Crunched压缩的原理。 首先,用户提到的图片尺寸是150x226,属于NPOT,也就是非二次幂的尺寸。虽然现代硬件支持NPOT纹理,但某些压缩格式可能有对齐要求,但ETC格式是否受影响呢?可能需要确认ETC是否支持NPOT,不过Unity在处理时可能会自动填充到合适的尺寸,或者进行压缩优化,这部分需要进一步思考。 接下来,原始格式是RGBA sRGB,每个通道8位,即每个像素占4字节。所以原始大小计算为150*226*4=135,600字节,大约是132.4KB,和用户给出的数据一致。这说明用户可能已经正确计算了原始大小。 转换为RGB Crunched ETC后,文件变小。ETC1通常不支持Alpha通道,ETC2则支持,但用户提到的是RGB Crunched ETC,可能是指ETC1,这样Alpha通道会被剥离或者存储在其他方式。不过需要确认Unity中的具体设置,是否选择了正确的ETC版本。另外,Crunched压缩Unity的一种有损压缩方式,结合了ETC/DXT压缩和Crunch压缩,进一步减小文件大小。 ETC压缩会将RGB数据压缩为4x4的块,每个块占固定的位数。例如ETC1每个4x4块占64位,即每个像素占4位(64位/(4*4)=4位/像素)。因此,RGB ETC1的像素数据量是原始RGBA的1/8(4位 vs 32位)。不过还要考虑是否有Alpha通道的处理,如果原始有Alpha,但转换到RGB ETC可能丢弃Alpha,或者使用其他方式存储,比如分离Alpha通道到另一个纹理,这可能会影响最终大小,但用户这里可能没有保留Alpha。 另外,Crunched压缩是在ETC压缩的基础上使用类似LZMA的压缩算法,对纹理数据进行二次压缩,这可以显著减少文件大小,尤其是在纹理中存在重复模式时。因此,Crunched不仅应用了纹理压缩,还进行了数据压缩,所以整体大小会更小。 整个转换过程可能包括以下步骤: 1. 剥离Alpha通道(如果转换为RGB ETC1)。 2. 将图像填充到适合ETC压缩的尺寸(如果需要,例如调整为4的倍数)。 3. 应用ETC压缩,将每个4x4块压缩为固定位数。 4. 应用Crunch压缩,进一步减少数据大小。 需要注意的是,Crunched压缩在运行时需要解压,可能会增加内存占用和加载时间,但减少的是存储或下载时的文件大小。此外,NPOT的处理可能引入填充像素,但ETC通常支持NPOT,Unity可能会自动处理。 用户可能想知道为什么转换后文件变小,以及每一步的变化。因此,回答时需要分步骤解释原始数据大小、ETC压缩后的数据大小,以及Crunch压缩的影响。同时,需要提到Alpha通道的处理和可能的尺寸调整,以及压缩后的视觉质量变化,如可能出现色带或块状伪影。</think>在Unity中,将150x226(NPOT)的RGBA sRGB图片转换为**RGB Crunched ETC**格式时,文件大小减少的完整技术流程如下: --- ### 1. **原始数据分析** - **尺寸**:150x226(NPOT,非2次幂,但现代GPU支持NPOT纹理) - **格式**:RGBA sRGB - 每个像素占 **4字节**(RGBA各8位) - **原始文件大小**:`150 × 226 × 4 = 135,600字节 ≈ 132.4KB`(与你的数据一致) --- ### 2. **转换为RGB格式(丢弃Alpha通道)** - **操作**:从RGBA变为RGB - 丢弃Alpha通道(若不需要透明) - 每个像素从 **4字节** → **3字节** - **临时大小**:`150 × 226 × 3 = 101,700字节 ≈ 99.3KB` --- ### 3. **ETC压缩(有损纹理压缩)** - **目标格式**:ETC1(默认)或ETC2(支持Alpha,但需OpenGL ES 3.0+) - ETC1将4x4像素块压缩为 **64位**(每个像素 **4位**) - **压缩比率**:`原始RGB的1/6`(3字节=24位 → 4位) - **计算ETC数据量**: ``` 每个块:4x4像素 = 64位 = 8字节 块总数:ceil(150/4) × ceil(226/4) = 38 × 57 = 2,166块 ETC数据量:2,166 × 8 = 17,328字节 ≈ 16.9KB ``` --- ### 4. **Crunched压缩(二次压缩)** - **原理**:对ETC压缩后的数据进行**LZMA/Huffman编码**(类似ZIP) - 消除ETC数据中的冗余模式 - **额外压缩率**:通常减少至ETC数据的 **30-50%** - **最终大小**:`17,328字节 × 0.5 ≈ 8,664字节 ≈ 8.46KB` --- ### 5. **最终结果** - **全程变化**: ``` RGBA 132.4KB → RGB 99.3KB → ETC 16.9KB → Crunched 8.46KB ``` - **总压缩率**:约 **93.6%** 的原始大小被压缩 --- ### 关键原因总结 1. **丢弃Alpha通道**:直接减少25%数据量。 2. **ETC块压缩**:通过固定比特率(4位/像素)大幅降低纹理数据。 3. **Crunched二次压缩**:利用通用压缩算法优化ETC数据的存储效率。 --- ### 注意 - **视觉影响**:ETC压缩可能导致色带、块状伪影(尤其梯度区域)。 - **运行时性能**:Crunched格式需在运行时解压为ETC,增加少量CPU开销。 - **Alpha需求**:若需保留透明通道,需使用ETC2+Alpha分离Alpha通道。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值