2
$\begingroup$

I have a 3-channel (for colours) a png image that I opened and

  1. I splitted the image into 8x8 blocks
  2. I applied all of the blocks discrete cosine transform
  3. And then applied quantization
  4. I stored the values in an array by zigzag traverse
  5. I do not know what to do to reduce the size in this step

Now I do not really understand what i am supposed to after this steps. How did I compress this image? If I applied inverse of these steps and put the values in a new image, I believe the size will not change at all. I mean I am supposed to save the values in a txt and decode them with my application so that I actually made a JPEG compression?

Improve this question
$\endgroup$

2 Answers 2

Reset to default
0
$\begingroup$
  1. And then applied quantization

That's the lossy part of your compression. You don't quantize all coefficients with the same bit depth, and that's how you save a lot of data.

Typically, higher frequency bins are quantized with fewer bits. Same goes for Chroma components, which are often sub-sampled (i.e. only 1/N as many values considered at all) from the start.

The zigzag pattern only serves the purpose of putting coefficients that are likely to be similar next to each other, so that run-length encoding (RLE) works well.

I actually found wikipedia's article on JPEG compression to be explaining this rather nicely.

I mean I am supposed to save the values in a txt and decode them with my application so that I actually made a JPEG compression?

Um, this is numerical data, not text, so I'm not sure where you're going with a text file (dumping numbers in a text file is almost never a good solution), but: You now have a run-length encoded stream of bytes. Compare the length of that string with the number of bytes your uncompressed image had.

Improve this answer
$\endgroup$
1
  • $\begingroup$ Yes I meant that. Storing them in a file.Now I have implemented a Huffman tree that both encodes and decodes the 1d array which is the result of zigzag traversing. Is the encoded bit string my compressed data? So each block can is represented by a encoded bit string. Does "the number of characters of each strings" multiply by "the number of the blocks" give me the compressed size? $\endgroup$
    – Thunfische
    Dec 15, 2018 at 1:34
1
$\begingroup$

Ok what's left is the last stage; namely Huffman VLC (variable length code) coding of those quantized DCT coefficients. And indeed it's true that the actual bit savings are obtained in this last stage.

As you may recognize, after the zig-zag scanning stage, there should be long chains of zeros among those 64 quantized DCT coefficients. By taking advantage of those chained zeros, you will encode those zig-zag scanned coefficients according to some CAT and SYM codewords, specifically designed and provided by the JPEG standards committee as a Huffman Table.

The procedure is longer than I wish to lay out here, but not very complex. I highly recommend anyone interested in implementing a standard JPEG the following books

  • 1-) Stanard Codecs_GHANBARI
  • 2-) Introduction to Data Compression_SAYOOD.
Improve this answer
$\endgroup$
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.