Support for "ATI2" fourcc format (BC5)
Closed this issue · 7 comments
Many of the textures in this free asset pack are in BC5 format. Trying to load the file yields the following:
System.AggregateException: 'One or more errors occurred. (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.) (FourCC: 843666497 not supported.)'
I'm mainly / only interested in getting at the raw compressed data (and the header info), so if decoding the pixel data is prohibitively complex, then it would be fine if the compressed data was still accessible.
Ok yeah let me take a look. One thing I noticed is that the "Antenna_Metal_0_Normal.dds" has a size of 5.333MiB on disk yet calculating how many bytes the image should take up (2048 x 2048 with 16 bytes per 4 x 4 pixel block) = 4MiB. I need to look a bit more into it.
The images all have mipmaps, so there is more data in the file than just the first mipmap level. E.g. that 2048x2048 image has 11 mipmap levels.
Oh yes that is right. Is it important that the mipmaps are exposed (a TODO)? Else testing locally, the ATI2 decoder worked on the several images tested from the asset pack.
Yes, getting at all of the mipmaps would be needed for completeness. Again, I just need the raw bytes though, no processing or anything necessary.
Ok sounds good, I have an impl that will preserve mipmap data when choosing to skip processing (the mipmap data isn't processed either). This should be what you're looking for, but I'll mull over it until potentially tomorrow.
Mipmap data will be lost if the image is subsequently processed (IImage::Decompress).
Changes committed. If no issues arise, I'll cut a release tonight
Just released 0.5.2