Jump to content

  • Log In with Google      Sign In   
  • Create Account

BGBTech: The Status Update



DXTn + AC & Deflate

Posted by , 20 June 2013 - - - - - - · 720 views

well, I was working more on the DXTn based "BTIC" images.


ultimately, the downfall of the AC codec seems to be, once again, that its raw performance is a bit weak, and isn't really "generally better" enough than other options (such as Deflate) to really make the performance impact worthwhile.

granted, yes, it has demonstrated an ability to squeeze down JPEG images slightly in my tests, which could be worthwhile, but seems to be less effective with Deflate (which seems to get comparable compression to AC for the BTIC images, but with higher performance). note that Deflate does not work effectively with JPEG images in my tests.

granted, with some fiddling I have gotten BTIC within comparable output size ranges to JPEG, albeit the image quality with photographic images is worse (BTIC results in more obvious blocking and patches).


note: some of the size/quality tradeoff does have to do with the block-reduction filtering, which I was fiddling with (basically, trying to improve the algorithm for matching and reducing the number of unique blocks used). further tweaking involved adding explicit support for "patch" images (more relevant to video), which will try (when possible) to match against the blocks used by the prior I-Frame, and try to create new blocks sparingly.

I am left wondering some if it could be possible to "precondition" DXTn blocks to compress better with Deflate, but this would introduce additional decoding complexity (the need to convert the blocks back into the format the GPU expects).


included are image comparisons between BTIC images at the current 50% quality, vs similarly-sized JPEG images.

the match-up at 50% in both cases is mostly coincidence (the pony image was previously closer to 25%, but altering the "choice" algorithm to go back to choosing DXT5 in this case seems to have made the BTIC image a bit larger, and thus, closer to the 50% quality JPEG, well, either that or a few tweaks made to the block-reduction algorithm).


on a related note:
got around to adding engine (video texture) support for both BTIC and Motion-PNG video.
unlike BTJ and BTIC video, M-PNG does not currently support extended components or layers, but does support lossless RGBA video.

note that BTIC is inherently lossy in its current form (unlike PNG, and BTJ supports both lossy and lossless modes).

or such...

Attached Thumbnails

  • Attached Image
  • Attached Image
  • Attached Image
  • Attached Image








PARTNERS