tag:blogger.com,1999:blog-5246987755651065286.post4309492748897332266..comments2024-02-22T16:15:42.388-08:00Comments on cbloom rants: 02-10-09 - Fixed Block Size Embedded DCT Codercbloomhttp://www.blogger.com/profile/10714564834899413045noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-5246987755651065286.post-31214667727218216812009-02-12T17:36:00.000-08:002009-02-12T17:36:00.000-08:00Oh, yeah, right, that makes sense.Oh, yeah, right, that makes sense.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-65625158221184872342009-02-12T14:45:00.000-08:002009-02-12T14:45:00.000-08:00"Do either of the coders actually do this? They se..."Do either of the coders actually do this? They seem not to."<BR/><BR/>No, with RMSE order you pretty much always know that higher bits are more important than lower bits in any other sample. (that might not always be true but you would need very strong predictions) I mentioned it because in the general case its something you would want to explore, but I haven't really done so.<BR/><BR/>"It seems like you could actually just apply the jpeg quantizer tables exactly here and then go in regular bitplane order."<BR/><BR/>You certainly could apply those tables if you want that perceptual scaling (it would hurt RMSE) but you would still need to reorder the samples in order to make the stream decently embedded.<BR/><BR/>"Another unrelated question: It seems weird to me that the DCT coefficients are spatially correlated"<BR/><BR/>Yeah, it's not actually spatial correlation - it's "octave" correlation between the subbands like a wavelet tree.<BR/><BR/>That is, the coefficient for frequency [k,m] is very similar to the coefficient at [2k,2m]<BR/><BR/>see Xiong et.al. ("A DCT-Based Embedded Image Coder")cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-37514806973209335292009-02-12T14:02:00.000-08:002009-02-12T14:02:00.000-08:00though there is the possibility of sending the top...<I>though there is the possibility of sending the top bitplanes of some coefficients before the top bitplanes of other coefficients</I><BR/><BR/>Do either of the coders actually do this? They seem not to.<BR/><BR/>It seems like you could actually just apply the jpeg quantizer tables exactly here and then go in regular bitplane order. In other words, divide by the quantizers but keep fixed point results (or, equivalent, multiply by 1024/quantizer[i] or whatever). This ends up de-emphasizing the bits of the higher frequency coefficients, shifting them down to line up with lower bits of the lower-frequency components. Oh, maybe this is what you meant by "non-uniform DCT scaling". And like you say I guess if you're using RMSE as your metric that stuff wouldn't help.<BR/><BR/>Another unrelated question: It seems weird to me that the DCT coefficients are spatially correlated (which I think you're saying for CodeTree), since I thought one of the things frequency-ish transforms were supposed to do was produce spikier output data?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-29931479684560570442009-02-10T20:05:00.000-08:002009-02-10T20:05:00.000-08:00"Isn't that implicit in how much you have to recon..."Isn't that implicit in how much you have to reconstruct? If you failed to transmit a lot of the bits, the block must be noisy, so use a noisy profile. If you transmitted most of the bits, it's smooth, but any noise you're adding in will be in the highest frequencies, so the block will still be smooth?"<BR/><BR/>Yeah, that's a good thought, that may be an easy way to exploit it. I haven't really looked into it much. Obviously that happens implicitly to some extent.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-9815519191284332782009-02-10T19:55:00.000-08:002009-02-10T19:55:00.000-08:00"Y is usually considered perceptually vastly more ..."Y is usually considered perceptually vastly more important. What if you tried two bits of shift (arbitrary shift?) - could that give even better quality?"<BR/><BR/>I was measuring quality with straight RGB RMSE. Obviously if you believe there is a perceptual difference, then you should scale Y up more, or you could subsample Co or Cg or whatever. Also it may improve perceptual quality to have non-uniform DCT scaling. I didn't want to get into any of that because it makes it hard to compare to other algorithms reliably, but yes in practice you would probably want at least the option of doing those things.cbloomhttps://www.blogger.com/profile/10714564834899413045noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-30227568065706955192009-02-10T19:34:00.000-08:002009-02-10T19:34:00.000-08:00"if you can tell that the block is pretty noisy, t..."if you can tell that the block is pretty noisy, then he grainy random restoration is probably better; if the block looks pretty smooth, then restoring to zero is probably better."<BR/><BR/>Isn't that implicit in how much you have to reconstruct? If you failed to transmit a lot of the bits, the block must be noisy, so use a noisy profile. If you transmitted most of the bits, it's smooth, but any noise you're adding in will be in the highest frequencies, so the block will still be smooth?Tom Forsythhttps://www.blogger.com/profile/01368434932814120414noreply@blogger.comtag:blogger.com,1999:blog-5246987755651065286.post-61154550456089242622009-02-10T19:15:00.000-08:002009-02-10T19:15:00.000-08:00"That shifts the way the bit planes relate to RGB ..."That shifts the way the bit planes relate to RGB errors. We could remember this and step through the planes differently, but it's easier just to shift Y left by one bit."<BR/><BR/>Y is usually considered perceptually vastly more important. What if you tried two bits of shift (arbitrary shift?) - could that give even better quality?Tom Forsythhttps://www.blogger.com/profile/01368434932814120414noreply@blogger.com