IPP Samples 7.0.6.060: jpegdec.cpp: m_jpeg_ncomp and m_dst.nChannels

[kosmas]

Hi.

In IPP Samples 059 and 060 in the UIC CJPEGDecoder in some functions the m_jpeg_ncomp had been replaced with m_dst.nChannels. Are you sure it is correct? These variables can have different values.

I cannot provide a sample code at the moment, but for example if we have a 3 channel JC_YCBCR JS_422 jpeg on input (values from ReadHeader) and SetDestination(...,..., dstChannels = 2, JC_YCBCR, JS_422) then the ReadData() crashes on these IPP Sample versions while it works correctly on 7.0.4.054.

Also, the UMC JpegDecoder does not seem to be updated and still has a bug with a loop counter being used twice, jpegdec.cpp, lines 4634, 4629

[Naveen_G_Intel]

Hi,

I just verified sample code of IPP 7.0 update 5 and update 6 jpegdec.cpp files, no changes in any variable name or functions parameters. Can you send information about line number or functions name?

Regarding loop counter being used twice, jpegdec.cpp, lines 4634, 4629 - yes, loop counter variable c is being used twice. This code might process only part of the data or result in an external loop depending on the loop's boundary values. Intel IPP development team will verify it and if it require, will be fixed in upcoming releases.

[bash]1.	JERRCODE CJPEGDecoder::DecodeScanBaselineNI(void)   
2.	{   
3.	  ...   
4.	  for(c = 0; c < m_scan_ncomps; c++)   
5.	  {   
6.	    block = m_block_buffer +   
7.	     (DCTSIZE2*m_nblock*(j+(i*m_numxMCU)));   
8.	  
9.	    // skip any relevant components   
10.	    for(c = 0; c < m_ccomp[m_curr_comp_no].m_comp_no; c++)   
11.	    {   
12.	      block += (DCTSIZE2*m_ccomp.m_nblocks);   
13.	    }   
14.	    ...   
15.	  }   
16.	  ...   
17.	}  
[/bash]

Regards,

Naveen Gv

[kosmas]

Hi,

For example in function JERRCODE CJPEGDecoder::Init(void)
in 7.0.4.054 - line 2454
in 7.0.5.059 - line 2461

There are more of these substitutions further in code.

And about the loop counter being used twice - I'm just saying the UMC version of jpegdec is not up to date (if compared to UIC version).

[Jeffrey_M_Intel1]

I've entered a request to synchronize the UIC and UMC jpeg implementations. Of course this needs to be prioritized with other work, so no guarantees about when it will happen. Many thanks for bringing this to our attention though.

I'd like to know more abouthow you produced a crash with the 7.0.6 version.If you couldattach a JPEG input fileyou're seeing crashes withthat would help us reproduce the problem here. There is probably no need for reproducer code, but perhaps a bit more description of your setup would be helpful too.

Regards,

Jeff

[kosmas]

Hi.

Thanks for reply.

Here's the jpeg.

After calling

decoder_.SetSource(&input_stream_);

and

decoder_.ReadHeader(&width, &height, &channels, &color, &sampling, &precision);

(which gives me 640, 480, 3, JC_YCBCR, JS_422,8 for attached jpeg) with both returning JPEG_OK I'm trying to do the following:

roi.width = width;
roi.height = height;
dest_step = width * 2;
dest_channels = 2;

decoder_.SetDestination(output->buffer, dest_step, roi, dest_channels, color, JS_422);
// returns JPEG_OK

decoder_.ReadData();
// crashes on versions 059 and 060 but works fine on 054

Am I wrong somewhere or is there something else?

[Jeffrey_M_Intel1]

Thank you for the jpeg and additional info. I have a question about setting dest_channels=2. What is the behavior you saw in 7.0.4?The uic_transcoder_con sample application appears to produce a correct image by using the number of channels from the input image (3). Do you want a different result thanthis?