Everything You Need to Know About JPEG - Episode 4 Part 1: Huffman Decoding

[@armaganvideos]

Better explained than any Prof. Dr. Dr. at my university, well done!

[@danielharding3688]

What a compliment! Thanks!

[@ДашаКузьмина-и3ж]

Thank you so much for the really useful video. However, if we use this method to make a tree, then we get a sequence of lengths: 1 - 0; 2 - 2; 3 - 2;4 - 4; 5 - 0...16 - 0. And the sequence of values: t s i e h o m x; If you decode these sequences using the (23:39) method, you will get 00 - t; 01 - s; 100 - i; 101 - e; 1100 - h; 1101 - o; 1110 -m; 1111- x; However, this does not coincide with the tree, which turned out. How is it more correct to make a tree so that the JPEG decoder can reproduce it from the Huffman table in the future? I will be very grateful for the answer!

[@danielharding3688]

Good question! I sort of answer this at 19:17 - 20:28, but I can elaborate more. However there is one problem with your understanding. You claim that using the (23:39) method, you were able to assign a code to every symbol (t, s, i, e, etc) but this is not possible! The (23:39) method only tells you what the sequence of codes should be, given how many codes there are of each length. The method itself tells you nothing about the assignment of codes to symbols. The assignment of codes to symbols comes from the ordered list of symbols in the DHT marker. I think this is the missing link that you needed, to be able to see how the decoder can reliably reproduce the same tables used by the encoder. (Refer to 21:15 - 21:42)

[@HHH6666-y3g]

At the end you mention that you can use the lower half of certain length code to represent negative, which does not make sense. In your example, if you use 11 for 3 and 011 for -4, then 11(3) will be prefix of 110(6). Can you explain a little bit more about it. Thank you in advance.

[@danielharding3688]

These positive and negative numbers are the DCT coefficients, not the Huffman codes. So they don't have to have unique prefixes. When it comes time to read a positive/negative DCT coefficient, the Huffman code for that coefficient has already been read. The Huffman code was converted into its symbol, which contains the length of the coefficient. That length from the symbol is used to read exactly that many bits when reading a positive/negative DCT coefficient.

[@HHH6666-y3g]

@@danielharding3688 Thank you for your reply. Do you mean only the symbol is encoded as huffman code. Through decoding it, we get the coefficient length, and the next $lenght bits just represent a normal binary value to represent a component value of one pixel. If so, why is it called Huffman coding bit stream. To make my point clearer, the non-zero value of a component of a pixel is never encoded as huffman code, but just a binary number (the only difference between it and a normal binary number is how to determine if it is negative).

[@danielharding3688]

@@HHH6666-y3g Your explanation is essentially correct, although it's a bit inaccurate to say this represents the value of one pixel. These DCT coefficients influence all 64 pixels in its MCU. There is no pixel component data encoded in the bitstream. re: why is it called Huffman coding bit stream Technically, the bitstream is called an Entropy Coded Segment. Huffman coding is just one kind of entropy coding. But it's called this because the bitstream is made up out of Huffman codes (along with some supplemental data after each code -- the DCT coefficients).

[@farahabid1435]

Looking for restart markers in jpeg encoder

[@DarylNotDead]

👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻👏🏻

[@lakshmibanupraksh5628]

can you please tell me how to run this files in codeblocks apart from prompt.