Is IJL_411 IJL_420actually? about Intel JPEG Library.

[Gaiger_Chen]

Your Excellency :

I would like to use IJL on 420 format, So I would modify IJL.

I found that, the IJL code for the defination of 411 :

case IJL_411:

/* 1st component */

jprops->jframe.comps[0].ident = 0;

jprops->jframe.comps[0].hsampling = 2;

jprops->jframe.comps[0].vsampling = 2;

/* 2st component */

jprops->jframe.comps[1].ident = 1;

jprops->jframe.comps[1].hsampling = 1;

jprops->jframe.comps[1].vsampling = 1;

/* 3st component */

jprops->jframe.comps[2].ident = 2;

jprops->jframe.comps[2].hsampling = 1;

jprops->jframe.comps[2].vsampling = 1;

That is just the defination of 420 as IPP doc said:

That make me confusing..... the IJL_411 do be 420 format???

If yes, why that name IJL_411 instead of IJL_420 ?

if no, how I should do to modify the code for IJL_420 ?

Thank you !

[Vladimir_Dudnik]

Hello,

you are right, actually what called in IJL as 4:1:1 in reality is 4:2:0. We still keep that for compatibility reasons.

By the way, you are aware about new C++ Unified Image Codec framework we develop in IPP since old IJL days? That new implementation has some advantages over IJL, like it supports JPEG Extended Baseline Losy Compression Mode for 12-bit images, it also support JPEG Lossless Compression Mode for 2..16 bit images and it is threaded, so you can get additional performance benefits on multicore systems. The UIC is unified C++ framework where several image codecs implementations inherited from base classes. It support PNG, JPEG, JPEG2000 and starting from IPP 7.0 Beta JPEG-XR.

Regards,
Vladimir

[Gaiger_Chen]

Hi,
Yes, I have got some test on the UIC package(the Jpeg Viewer).
I found the performance is better than IJL in multicore systems.
But I found that the IJL is the best for the ratio of speed over computation costing.
(that is said: IJL is higher on C/P value).
(plot I will post on monday)

So the IJL is my choise.

Thank you.

[Vladimir_Dudnik]

Not sure you try exactly UIC when you describe JPEG Viewer. We had some days JPEGView sample which now is deprecated and substituted by UIC sample (with uic_transcoder_con and picnic as demo applications). Just want to be sire you try namely UIC.

I thought performance is measured in units of time required to to some work...

Regards,
Vladimir

[Gaiger_Chen]

Hi:

It is performance plot by my benchamrk.
To encode a image(from WOW) as JPEG 422 format 100 times.






IJG6b_IPP meanings IJG-6b embedded IPP
JV means Jpeg Viewer (on the Legacy Samples\image-codecs\jpegview\jpeg )
JVSerial and JVOpenMP has been compiled by Microsoft VC 8 (VC 2005).
+ ICC means that been compiled by Intel C compiler 10.1.

Platform : Intel E6500 (dueal core 2.93GHz), windows xp sp3.


As you seem the fastest in JpegViewer, but the most high C/P value, is the IJL.

[Vladimir_Dudnik]

Hi Chen,

thank you for providing your comparison, I think it isquite useful to IPP developers in order to understand the benefits provided by Intel C/C++ compiler, OpenMP threading and Intel IPP optimized functions.

Just addition, if you have a time and desire could you please also add UIC codec performance to that chart?

Especially, for IPP 7.0 UIC codec, it will be great to show performance on multi-core system for JPEG file encoded with restart intervals (when there is one restart interval per image row). That will demonstrate performance of new threading model we implemented in UIC JPEG codec (we did for both encoder and decoder).

Re IJL performance, please note, that its high performance in serial mode achieved at a particular cost, namely arithmetic accuracy of color conversion computation and some limitation in robustness and codec features. To have completepicture it might be useful to add also some kind of quality comparison, like PSNR vs original non compressed image. You will find that IJL codec provides lower (worse) PSNR.

Regards,
Vladimir

[Gaiger_Chen]

HI Vladimir:

by My Checking, The JpegViewer mentioned above is jsut the UIC jpeg encoder.

I have check the 2 code : \ipp-samples\image-codecs\uic\src\codec\image\jpeg\enc\src
and \Legacy Samples\image-codecs\jpegview\jpeg\

are the same.

I used the 6.1 version for above testing.

by the way, UIC jpeg codec is heavy OOP, and with few

documentation . (there is only one page doc ,example code I do not found it on website or within fold.)

It is hard to modify for me by my stupid.

Anyway, thank your support, I would comparison the UIC 7.0 beta with 6.1 .


Thank you.

[Vladimir_Dudnik]

Thanks. There should be UIC manual PDF file in doc folder. But it might be too brief, you are right.

By the way, UIC has uic_transcoder_con application which can be used for performance testing, so you may not need to modify that OOP code :)

Vladimir

[Gaiger_Chen]

HI Vladimir:



As you see, The UIC 7.0 is not faster than 6.1. Each codec has been compiled by VC 8.
UIC7.0 is within IPP7.0 beta, UIC6.1 is within IPP 6.1.

When I use IPP 7.0 beta, there is another problem arise:
If I select "Generate Debug Info" as "Yes" in Debugging uder linker (Yes means that I could not set up break point), I could not pass the compiling :

ippcore_l.lib(pscpudefas.obj) : fatal error LNK1103: debugging information corrupt; recompile module


How should I do? thank you.

[Vladimir_Dudnik]

Hello,


new JPEG threading model we introduce in IPP 7.0 beta only work for JPEG files compressed with restart intervals (when restart interval is set in each image row). Yes, it is limited in that sense, not every JPEG file is encoded with such options, but for those files which are, there is significant boost in performance (especially for 4+ core systems) because for JPEG it is possible to process restart intervals independently.

You can try attached JPEG file (which was encoded with required options) to demonstrate threading scalability of new JPEG threading model.

Regarding your problem for debug build will take are careful look into that. Looks like something we need to fix. Did you use 32-bitor 64-bit build?

Regards,
Vladimir

[Pavel_B_Intel1]

When I use IPP 7.0 beta, there is another problem arise:

If I select "Generate Debug Info" as "Yes" in Debugging uder linker (Yes means that I could not set up break point), I could not pass the compiling :

ippcore_l.lib(pscpudefas.obj) : fatal error LNK1103: debugging information corrupt; recompile module

Hi Chen!

It is helps you: http://support.microsoft.com/kb/949009

Pavel

[Gaiger_Chen]

Hi , Berdnikov:

I have download and install the patch, "VS80sp1-KB949009-X86-INTL.exe"
(my software system : Windows XP sp3, Visual studio SP1)

After reroot computer, that is the same: I could not set up break point or could not passing the compiling.

That is ok, The IPP-7.0 beta is just for comparison with ver. 6.1.

Anyway, Thank your support.

[Gaiger_Chen]

Hi Vladimir:
/*
new JPEG threading model we introduce in IPP 7.0 beta only work for JPEG files compressed with restart intervals (when restart interval is set in each image row). Yes, it is limited in that sense, not every JPEG file is encoded with such options, but for those files which are, there is significant boost in performance (especially for 4+ core systems) because for JPEG it is possible to process restart intervals independently.
*/


I do not know what is the meaning of "restart intervals" you mentioned above.
To my knowledge, Jpeg is just encode/decode a static image, or are you refer to Motion JPEG ?
Or you means that: There is lots image await to been encode, the duration of encode would be shorter after first image has been encode by UIC 7.0.

Could you just me some refernce to the "restart intervals".

I guess, our application needs that.... maybe Motion JPEG be the phase.

Thank you.

[Pavel_B_Intel1]

I have download and install the patch, "VS80sp1-KB949009-X86-INTL.exe"

(my software system : Windows XP sp3, Visual studio SP1)

After reroot computer, that is the same: I could not set up break point or could not passing the compiling.

That is ok, The IPP-7.0 beta is just for comparison with ver. 6.1.

Anyway, Thank your support.

Hi!

Do you mean that "Fatal error LNK1103: debugging information corrupt" error still is after MS patch was installed? If yes could you say which version of MS Studio do you use?

Actually it is the bug of MS Studio - "This problem occurs because of a compatibility issue between Visual Studio 2005 and Visual Studio 2008 versions".

Pavel

[Gaiger_Chen]

HI Pavel:

Yes, "Fatal error LNK1103: debugging information corrupt" error is still after MS patch was installed.

I am use visual studio 2005 with SP1(sorry for I do not write the "2005" on last post).

I think the IPP 7.0 beta is built by intel C++ with VS 2008, so some library is not Compatibility with VS 2005.

thank you lots.

[Vladimir_Dudnik]

Hello,

restart intervals are kind of sync points defined by JPEG specification. Their primiry goal is to provide some error resilence capability to decoder and we use them for parallel processing of regions of JPEG file which is not possible without them because of VLC coding in JPEG.

I'd suggest you to measure performance of JPEG decoders on multi core system on file attached in my previous post. You should see better threading scalability in IPP 7.0 UIC JPEG decoder comparing with IPP 6.1, especially on number of core 4 and more. That is why we introduce that new threading model in IPP 7.0 UIC JPEG.

Regards,
Vladimir

[Gaiger_Chen]

HI Vladimir:

Our application is using PC to encode the images, then transmission the jpeg by WIFI to some device(like mobile phone or wireless projector), decode the JPEG by pure - hardware on the device to display.

The intel Moorestown is un-released, so, I think the decode part is not helpful for us..

Anyway, thank you.

Gaiger

[Vladimir_Dudnik]

Hi Gaiger,

new threading model will work in both JPEG encode and decode. I thinkuic_transcoder_con application should use new threading model (and set appropriate parameters) by default. I can check and if it is not default will provide you description on how to enable it.

Regards,
Vladimir