13

While studying this document on the Evolution of JPEG, i came across "The law of the eight" in Section 7.3 of the above document.

Despite the introduction of other block sizes from 1 to 16 with the SmartScale extension, beyond the fixed size 8 in the original JPEG standard, the fact remains that the block size of 8 will still be the default value, and that all other-size DCTs are scaled in reference to the standard 8x8 DCT.

The “Law of the Eight” explains, why the size 8 is the right default and reference value for the DCT size.

My question is

What exactly is this "law of the eight" ?

  • Historically, was a study performed that evaluated numerous images from a sample to arrive at the conclusion that 8x8 image block contains enough redundant data to support compression techniques using DCT? With very large image sizes like 8M(4Kx4K) fast becoming the norm in most digital images/videos, is this assumption still valid?

  • Another historic reason to limit the macro-block to 8x8 would have been the computationally prohibitive image-data size for larger macro-blocks. With modern super-scalar architectures (eg. CUDA) that restriction no longer applies.

Earlier similar questions exist - 1, 2 and 3. But none of them bother about any details/links/references to this mysterious fundamental "law of the eight".


1. References/excerpts/details of the original study will be highly appreciated as i would like to repeat it with a modern data-set with very large sized images to test the validity of 8x8 macro blocks being optimal.

2. In case a similar study has been recently carried-out, references to it are welcome too.

3. I do understand that SmartScale is controversial. Without any clear potential benefits 1, at best it is comparable with other backward-compliant extensions of the jpeg standard 2. My goal is to understand whether the original reasons behind choosing 8x8 as the DCT block-size (in jpeg image compression standard) are still relevant, hence i need to know what the law of the eight is.

Community
  • 1
  • 1
TheCodeArtist
  • 21,479
  • 4
  • 69
  • 130
  • Asking whether it is still relevant is clearly a question of opinion. –  Aug 16 '13 at 21:45
  • @woodchips i do NOT mean to ask if anyone thinks it is relevant. Rather i am interested in learning the **law of the eight** so that i can decide for myself whether it is still relevant. I have simply mentioned my motivation behind asking the question. All the same i have modified the footnote. I hope the question no longer warrants a close-vote. – TheCodeArtist Aug 16 '13 at 23:28
  • ..and nor a down-vote either (i hope) :-) – TheCodeArtist Aug 16 '13 at 23:38
  • Interesting question, wish someone could answer it ;) voted leave open. – Antti Haapala -- Слава Україні Aug 17 '13 at 07:16
  • 1
    I read it as "JPEG started with 8x8 DCTs, everything is defined in terms of 8x8, and any other block size must be scalable to 8x8". That is, section 7.3 *is* the Law of the Eight. But eh. – cHao Aug 19 '13 at 21:24

1 Answers1

2

My understanding is, the Law of the Eight is simply a humorous reference to the fact that the Baseline JPEG algorithm prescribed 8x8 as its only block size.

P.S. In other words, "the Law of the Eight" is a way to explain why "all other-size DCTs are scaled in reference to 8x8 DCT" by bringing in the historical perspective -- the lack of support for any other size in the original standard and its defacto implementations.

The next question to ask: why Eight? (Note that despite being a valid question, this is not the subject of the present discussion, which would still be relevant even if another value was picked historically, e.g. "Law of the Ten" or "Law of the Thirty Two".) The answer to that one is: because computational complexity of the problem grows as O(N^2) (unless FCT-class algorithms are employed, which grow slower as O(N log N) but are harder to implement on primitive hardware of embedded platforms, hence limited applicability), so larger block sizes quickly become impractical. Which is why 8x8 was chosen, as small enough to be practical on wide range of platforms but large enough to allow for not-too-coarse control of quantization levels for different frequencies.

Since the standard has clearly scratched an itch, a whole ecosphere soon grew around it, including implementations optimized for 8x8 as their sole supported block size. Once the ecosphere was in place, it became impossible to change the block size without breaking existing implementations. As that was highly undesirable, any tweaks to DCT/quantization parameters had to remain compatible with 8x8-only decoders. I believe this consideration must be what's referred to as the "Law of the Eight".

While not being an expert, I don't see how larger block sizes can help. First, dynamic range of values in one block will increase on average, requiring more bits to represent them. Second, relative quantization of frequencies ranging from "all" (represented by the block) to "pixel" has to stay the same (it is dictated by human perception bias after all), the quantization will get a bit smoother, that's all, and for the same compression level the potential quality increase will likely be unnoticeable.

Andriy Volkov
  • 18,653
  • 9
  • 68
  • 83
  • @Shadow Wizard, edited to say "My understanding is" -- is this better? in my 4.5 years on this web site I never knew StackOverflow disallowed non-authoritative answers, am I wrong? If this is so then all the answers but the right one must be comments, correct? – Andriy Volkov Aug 19 '13 at 21:13
  • Nothing is "disallowed", just better fit as comment unless there is some more content. – Shadow The GPT Wizard Aug 19 '13 at 21:31
  • But I believe this _is_ the right answer -- the fact that the answer is concise does not make it "better fit as comment". Comments are for meta-information (discussing the questions and answers), not for "short answers" or "unverified answers" or "disappointing answers". – Andriy Volkov Aug 19 '13 at 21:34
  • OK, in general I still think answer shouldn't be based on a guess or hunch, or start with "I guess" or "I suppose". This specific case might be in the gray zone, personally not familiar with the subject so can't really vote. (not my downvote) - hopefully the OP here will be kind enough to share his opinion as well. – Shadow The GPT Wizard Aug 19 '13 at 21:40
  • So far, it seems to be the general consensus that there is no specific study which resulted in the "law of the eight". However as i initially mentioned in the question, my motivation behind this question is to experiment with larger block-sizes on HUGE images. In the absence of a prior authoritative method that was used to identify that the quality/compression is fair enough at 8x8, what can be used as a qualitative measure to evaluate the resulting images using larger macro-blocks (compared to the images generated using current 8x8 implementation) ? – TheCodeArtist Aug 20 '13 at 01:51
  • your libjpeg-turbo.org link explains their method well, they try smaller block sizes but same approach could be used to compare larger sizes. Here, I added another paragraph to my answer above explaining why I believe larger block sizes won't improve anything much. – Andriy Volkov Aug 21 '13 at 13:51
  • @zvolkov Regarding the dynamic range of values in a block, my thought process was that - The dynamic range of an 8x8 block in a photo captured at 2M will be the same as that of a 16x16 block in a photo of the same scene captured at 8M. Am i missing something here?... – TheCodeArtist Aug 21 '13 at 17:35
  • and since one of the primary means of compression in JPEG is rounding-off the co-efficient of higher frequencies in the DCT, i.e. essentially zero-ing the high-freq. co-effs. to generate longer stream of zeroes, better compressed with RLE. IOW, larger blocks = longer streams of zeroes, ergo better compression. Hmmm?... – TheCodeArtist Aug 21 '13 at 17:48
  • idk, you may have a point. Only one way to know for sure, go ahead and try :) Let's say you were in luck and obtained 25% smaller compressed sizes at comparable quality level, while taking 4 times longer to compress, and breaking compatibility with older consumers -- do you think it's worth it? – Andriy Volkov Aug 21 '13 at 20:55
  • Definitely not worth the trouble unless its added to the standard. So looking for the original study/code that was used for analysis of block-size. – TheCodeArtist Aug 26 '13 at 12:37