0

I am currently developing a dct based jpeg encoder and got stuck on a problem with the luminance channel. The chrominance values seem to be correct.

A few words to the encoding procedure. The picture is based on ycbcr color values. Cb and Cr Channel is subsampled by 2. So SubSampling is 4:2:0. dc and ac coefficients are dct encoded and quantized. Grouped to 8x8 blocks, the dc values are calculated by delta differences and theyre category, ac values are run length encoded. The dc and ac values are written interlaced in yyyycbcr format. All Huffman Codes seem to be correct and tools like jpeg snoop finish decoding procedure without any warning of bad markers or huffman codes. everything seems alright. Picture 1 is the original picture in ppm format.

This picture is read and transformed into a compressed jpeg format. picture 2 demonstrates the output of picture 1 after compression. Picture 3 shows the picture with max luminance values. all y channel values are set to 255 in picture 3. Any idea why the luminance channel is able to generate such a pattern in picture 2 ?

picture

xSmorpheusSx
  • 93
  • 1
  • 6
  • The black areas look like you're not properly clamping the min and max values and instead they're overflowing. – BitBank Jan 19 '15 at 16:28
  • could you please explain clamping the min and max values more precisely. do you mean the min and max luminance values ? – xSmorpheusSx Jan 19 '15 at 19:10
  • When you do the DCT transform on the quantized values and then reverse the process, errors are introduced. Sometimes the errors will cause the values go to beyond 0 and 255. You need to specifically clamp the output to keep them in the 0-255 range. – BitBank Jan 19 '15 at 19:37
  • thank you. i will check this. but i am doing the quantization on my dct transformed values ? is this also valid for encoding? – xSmorpheusSx Jan 19 '15 at 19:43
  • The limitation on min and max values seemed to be one of the problems while encoding. The output can be seen here: http://morpheus.reimis.net/image.jpeg . I know without knowing the concrete implementation its quite hard to guess whats wrong because everything could be wrong. But could you imagine a possible case in which this behaviour exists ? – xSmorpheusSx Jan 19 '15 at 21:44
  • If I had to guess, it looks like the encoding order of the luminance values is wrong such that the upper and lower Y values are swapped. – BitBank Jan 19 '15 at 22:39
  • thank you. i will check the order – xSmorpheusSx Jan 20 '15 at 08:40
  • I know the MPEG folks use 4:2:0 sampling. But, according to the JPEG standard (appendix A), 4:2:0 gives no sampling of the third component. – user3344003 Jan 20 '15 at 15:35

0 Answers0