Googles appar
Huvudmeny

Post a Comment On: cbloom rants

"07-07-09 - Small Image Compression Notes , Part 2"

7 Comments -

1 – 7 of 7
Blogger won3d said...

So Sean's idea of using the midpoint of quantization regions, and the papers' constraint of staying within the quantization regions, during decompression seem to be motivated to stay within what could be considered an up-to-spec JPEG decompressor. It doesn't really look like Unblock does that.

How desirable is it to stay within the quantization regions? It seems like you have to for quantitatively accurate reconstruction. Perhaps it is possible to try to match block boundaries with block center statistics by manipulating the AC coefficients instead of the post-decoded colors.

Also, I would suppose that knowing about the deblocking filter in advance would help compression somewhat, a la h.263/4's in-look deblocking. Of course, I have no idea how such things actually would work.

July 9, 2009 at 9:32 AM

Blogger cbloom said...

"It doesn't really look like Unblock does that."

Yeah, Unblock is just a spatial filter in the end so it doesn't know about maintaining the AC coefficients. (of course you could use Unblock and then DCT the result and do POCS to iteratively enforce that constraint)

"How desirable is it to stay within the quantization regions?"

Obviously it's theoretically appealing because it gives you an output image that actually compresses to the same stream you decoded. In practice that aspect is not actually important - we just want something that looks good.

The crucial thing that it does is ensure that you aren't doing much harm.

"Also, I would suppose that knowing about the deblocking filter in advance would help compression somewhat,"

Yes, actually my encoder implicitly does this because my Lagrange search finds the optimal lambda including deblocking.

July 9, 2009 at 10:29 AM

Blogger won3d said...

"Yes, actually my encoder implicitly does this because my Lagrange search finds the optimal lambda including deblocking."

For your custom image format, or for JPEG?

July 10, 2009 at 8:05 AM

Blogger cbloom said...

Custom, but you could easily enough do the same thing for JPEG.

I've been thinking you could make a pretty damn good format using the JPEG bitstream and an optimizing encoder, but you would need a custom decoder to get the full benefit so there's not really a lot of point to using the JPEG bitstream. (you need a custom decoder to do your deblocking as well better dequantization)

July 10, 2009 at 8:52 AM

Blogger won3d said...

"I've been thinking you could make a pretty damn good format using the JPEG bitstream and an optimizing encoder, but you would need a custom decoder to get the full benefit so there's not really a lot of point to using the JPEG bitstream."

Except you get backwards compatibility with all those JPEG decoders out there (like the one I'm typing in now)? I wonder how bad the naive/legacy decoder would be for something that presumed deblocking and a special quantizer?

July 10, 2009 at 12:15 PM

Blogger astrange said...

I really recommend not reading papers and reading the x264 source instead. It's much more practical.

You'd also find out the real reason H.264 is so good for intra - it's not really because of DCT, since it doesn't even use DCT but just a cheap approximation, but more because of the large set of predictors, DC hadamard, and especially the use of CABAC over VLC coding. And x264's major use of adaptive quantization helps too.

August 8, 2009 at 10:20 AM

Blogger cbloom said...

"but more because of the large set of predictors"

There are only 9 right, and they're just block gradient predictors. It is somewhat interesting and surprising how much that does seem to help. I did some experiments with doing more advanced versions of that.

"DC hadamard"

That's only for sets of four 4x4 blocks right?

"and especially the use of CABAC over VLC coding"

Well, that's silly, compared to what? CABAC is obviously very poor compared to a real coder like ECECOW. I keep finding papers that say how great CABAC is compared to VLC, but it's hard for me to tell if it's actually good compared to a real arithmetic coder.

"And x264's major use of adaptive quantization helps too."

This is something I'm very interested in. I wonder how much adaptive quantization and trellis-truncation helps.

August 8, 2009 at 10:36 AM

You can use some HTML tags, such as <b>, <i>, <a>

This blog does not allow anonymous comments.

Comment moderation has been enabled. All comments must be approved by the blog author.

You will be asked to sign in after submitting your comment.