Jump to content

  • Log In with Google      Sign In   
  • Create Account

#Actualcr88192

Posted 20 February 2013 - 12:31 PM

You give some file size comparisons, but how was the image quality with those sizes? It would be interesting to see the L1 or L2 norms of the different compression techniques, but then again I strongly doubt that you are going to do better than wavelet-based coding techniques like JPEG2000, except for special cases maybe. But perhaps I am wrong and you can surprise me ;)

 

side notes:

the algorithm is LZ77 based, and beyond the initial (lossy) conversion into DXTn, there shouldn't be any additional loss in quality (apart from potential encoder bugs).

typically, a person will compare the source data with the output decompressed data, and make sure that they match.

 

it is basically analogous to Deflate, but works in larger 8-byte units, and lacks any entropy coding (such as Huffman), and uses a larger window.

 

basically, each coded block consists of a tag-byte, followed by any operand bytes, and possibly followed by raw 8-byte blocks (the "literal block cases").

if a particular raw block has been seen previously, it is reused by index. if a span of blocks is seen, it will also be encoded (this includes copying runs from the window, or potentially encoding an RLE run of matching blocks).

 

for DXT5, which uses 16-byte blocks, the image is split into two planes of 8-byte blocks, which are encoded as two passes.

 

granted, comparing this against Deflate could also make sense, I have yet to test/compare them.

 

 

granted, there is some possible variation in compression based on how "good" the DXTn encoder is, which in my case, it is more optimized for speed than quality.

 

I was actually surprised that such a naive strategy was managing to do better (compression-wise) than the JPEG images, but there is a possible explanation:

DXTn itself is a bit more lossy than JPEG.

(it was mostly intended for "quick and dirty" compression, but did better than expected).

 

IOW: you probably wont want to be using DXTn for your photos, but it works well enough for game textures.

( so, it isn't really in the same camp as JPEG, JPEG-2K, or JPEG-XR ).

 

 

here is a link for the encoder being used for the DXT5 part:

http://pastebin.com/8rq3z5F5

 

and, for other information:

http://en.wikipedia.org/wiki/DXTn

http://en.wikipedia.org/wiki/LZ77

 

 

other possibilities are possible, but this is all for now.


#1cr88192

Posted 20 February 2013 - 12:05 PM

You give some file size comparisons, but how was the image quality with those sizes? It would be interesting to see the L1 or L2 norms of the different compression techniques, but then again I strongly doubt that you are going to do better than wavelet-based coding techniques like JPEG2000, except for special cases maybe. But perhaps I am wrong and you can surprise me ;)

 

side notes:

the algorithm is LZ77 based, and beyond the initial (lossy) conversion into DXTn, there shouldn't be any additional loss in quality (apart from potential encoder bugs).

typically, a person will compare the source data with the output decompressed data, and make sure that they match.

 

it is basically analogous to Deflate, but works in larger 8-byte units, and lacks any entropy coding (such as Huffman), and uses a larger window.

 

basically, each block consists of a tag-byte, followed by any operand bytes, and possibly followed by raw 8-byte blocks (the "literal block cases").

if a particular block has been seen previously, it is reused by index. if a span of blocks is seen, it will also be encoded (this includes copying runs from the window, or potentially encoding an RLE run of matching blocks).

 

granted, comparing this against Deflate could also make sense, I have yet to test/compare them.

 

 

granted, there is some possible variation in compression based on how "good" the DXTn encoder is, which in my case, it is more optimized for speed than quality.

 

I was actually surprised that such a naive strategy was managing to do better (compression-wise) than the JPEG images, but there is a possible explanation:

DXTn itself is a bit more lossy than JPEG.

 

IOW: you probably wont want to be using DXTn for your photos, but it works well enough for game textures.

( so, it isn't really in the same camp as either JPEG-2K or JPEG-XR ).

 

 

here is a link for the encoder being used for the DXT5 part:

http://pastebin.com/8rq3z5F5

 

and, for other information:

http://en.wikipedia.org/wiki/DXTn

http://en.wikipedia.org/wiki/LZ77


PARTNERS