JPEG encoded images have errors

Here's some additional detail about Peter's problem. Earlier marker FFC0 correctly reports three components...

*** Marker: SOF0 (Baseline DCT) (xFFC0) ***
  OFFSET: 0x000001A6
  Frame header length = 17
  Precision = 8
  Number of Lines = 480
  Samples per Line = 640
  Image Size = 640 x 480
  Raw Image Orientation = Landscape
  Number of Img components = 3
    Component[1]: ID=0x01, Samp Fac=0x22 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
    Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cb)
    Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 2), Quant Tbl Sel=0x01 (Chrom: Cr)

However, Scan reports only 1 component!

*** Marker: SOS (Start of Scan) (xFFDA) ***
  OFFSET: 0x0000023F
  Scan header length = 8
  Number of img components = 1
    Component[1]: selector=0x01, table=0x00
  Spectral selection = 0 .. 63
  Successive approximation = 0x00

Download JPEGsnoop from here.

http://www.impulseadventure.com/photo/jpeg-snoop.html

Strangely, VLC and Firefox both seem to decode images correctly, however two players which expect mjpeg fail to decode the stream.

Geoff (Peter's colleague)

I have some additional information on this issue.  I see the problem outlined above if I specify XDM_YUV_420P as the inputChromaFormat and also as the forceChromaFormat.  If I specify XDM_YUV_422ILE as the inputChromaFormat and XDM_YUV_420P or XDM_YUV_422P as the forceChromaFormat, then there is no error.  The problem with using 422ILE as the input is the encode takes twice a long and I really need the faster encode time.  Is there a workaround for this problem?  If not, could it be fixed?

Thanks,

Peter

Hi Peter,

Please let me know which version of JPEG encoder are you using.

Regards,

Poonima

Hi Poonima,

I'm using version 1.12 which comes with DVSDK version 1.11 for the DM648.  I've seen the same problem with version 2.0 for x64+ running with an unmodified version of the sample application on the DM648 EVM board.

Peter

Hi Peter,

I tested with the JPEG encoder version you have mentioned and I am not seeing any issue.Please share your wrapper code or logs to debug further.

Regards,

Poornima

Hi Poornima, thanks for your support.

When you say that you are not seeing any issue, could you clarify?

Some of the test images in the reference folder of the encoder package contain only one component in the Start Of Scan marker, but three in the Baseline DCT. Isn't this inconsistent?

Are you unable to create images that JPEGsnoop reports with these characteristics?

What are the settings that were used to create the reference image output_420p.jpg? I think we can use this to demonstrate the issue.

We were able to create good images with interleaved input, however, these images take over twice as long to encode. Our application will require us to use 422P input images to meet our performance targets (30fps).

This problem is jeopardizing our product release dates. We appreciate your support.

Geoff

BTW

The reference images are here in the encoder software package: ti/sdo/codecs/jpegenc/app/Client/Test/TestVecs/Reference

Hi Peter,

I tested with the encoder version you had specified on my stand-alone setup by encoding an image and did not see any sort of issue you have been talking about.

And I am not very sure regarding what is the issue about the reference images you are referring to.I shall see through those and let you know further.

Regards,

Poornima

Hi Poornima,

I've verified this problem both in the eval version 1.12 JPEG encoder that comes with the DVSDK version 1.11 and with the production 2.0 version of the JPEG encoder.  Starting with the eval 1.12 version, just go into the C:\dvsdk_1_11_00_00_DM648\codecs_1_10_evmDM648\packages-evaluation\ti\sdo\codecs\jpegenc\app\Client\Test\TestVecs\Reference directory and open the output_420.jpg and output_420p.jpg images in the JPEGsnoop tool (I've also attached the logs: 7457.output.zip).  As you can see there are errors in the output_420p.jpg image while the output_420.jpg image is fine.  While some decoders seem to be able to skip over the errors without problem, the one we depend on fails.

Now, the production 2.0 encoder is a little different since it only seems to come with a single reference jpg image, however, you can generate an image with the error using the sample application on the EVM board without modifying the code.  In the codecs\jpegenc\app\Client\Test\TestVecs\Config directory, change the contents of the Testparams.cfg to match what's in the Testparams_420P.cfg file - specifying XDM_YUV_420P as both the input chroma format and the forced chroma format.  For a valid input, you can copy the 420 YUV file from the eval 1.12 JPEG encoder that comes with the DVSDK.  When you run this configuration, you will see JPEGsnoop reports the same error as was seen in the 1.12 version of the encoder.

What version of the encoder are you working with?  Since you do not see the problem you may already have a fixed version.

Thanks,

Peter

Hi there --

Just wanted to let you know that the current version of JPEGsnoop (1.5.2) does not handle the case where the encoder has split the image components between multiple SOS markers. In other words, if the SOF has defined 3 image components, it expects that the SOS will also show 3 image components (ie. not 1 component in each of 3 SOS). This has been captured in SourceForge bug report #3298074. I believe the image you have shared exhibits this arrangement.

Hope that helps,
Calvin

Hi Calvin,

Thanks for the timely help.I suppose it would lead us further to narrow down the problem.

Hi Peter,

I checked with the reference images you had mentioned about using JPEGsnoop(version 1.3.0) and not seeing any issue of the sort you told about.Please check with your JPEGsnoop version and let me know if the issue is still seen.

Regards,

Poornima

Hi Calvin,

Thank you for that insight. Clearly it looks like some of the decoder software we are working with also cannot decode images where the encoder has split the image components between multiple SOS markers.

Hi Poornima,

Is it possible to direct the encoder that it must keep all three components in one SOS marker?

Regards,

Geoff