Jpeg 2000 support?

[ChicagoBob]

Does this SDK support wavelet or fractal compression?

[Nina_K_Intel]

No, Intel Media SDK doesn't support this format.

Regards,

Nina

[Vladimir_Dudnik]

Hello,

for wavelet functionality or even forbaseline JPEG2000 codec implementation I would recommend you to take a look at Intel Integrated Performance Primitives product, the latest version is IPP 7.0.1.

Regards,
Vladimir

[ChicagoBob]

Performance and JPEG 2000 are not in line with expectations. Reading the posts it seems IPP never tuned JPEG2000 and is being out shined by a few others. If its true or not when I think of the idea is best performance I think that Intel should be able to deliver the highest performance solutions. Sadly though this has not been the case. Several times smaller commercial efforts have been faster/better. This is the case with IPP which I dont think to this day directly supports YUV even though video and many image formats are in YUV including the macro blocks found in JPEG images.
In short no IPP would be my last choice, I was hoping since the tag line is one Media SDK etc it would include all the current mainline video compressors which the BBC thinks JPEG2000 is one of.
Thanks for the reply.

[Vladimir_Dudnik]

Well, the wavelet functions in IPP pretty good optimized for modern processors. The implementation of JPEG2000 codec in IPP samples serves for purposes of demonstration how you can build codec from IPP functions. It might not achieve the best performance yet, athoughJPEG2000 is currently a little out of our development focus.

I did not get what is your concern on YUV support. The data in YCbCr macroblocks found in JPEG perfectly served by dedicated IPP functions as you may see in IPP JPEG codec sampe.

Vladimir

[ChicagoBob]

I did not get what is your concern on YUV support. The data in YCbCr macroblocks found in JPEG perfectly served by dedicated IPP functions as you may see in IPP JPEG codec sampe.
>>
IPP always converts from YUV to RGB internally. Thats been my experience.IPP never hadnative hooks
to input YUV or output YUV without going through an RGB coversion someplace in the code. This has always troubled me. Why is Intel wasting cycles on color space conversion?

I work in video and when I cap data from any device I do the work in YUV to reduce CPU cycles.
I mix it, alter it, diplay it, etc.. all in YUV. It may come in different bit depths but in general its 4:2:2 or 4:4:4, 8 or 16 bit depth.
Even from a video editing perspective YUV is the native language and you get color shifts if you try and marry the 2 color spaces.

And since YUV is the nativeformat of video its always bothered meIntel wastes precious cyclesconverting from YUV to RGB. Floating point conversion is quite expensive. Always working in realtimewith multiple sourcesand 33ms NTSC intervals in HD or even SD format why waste the time converting back and forth fromthe native input format of YUV?
Far as JPEG2000 the BBC declared JPEG2000 as the new international standard for image compression and with such importance you would think Intel would consider being the absolute best to compress and decompress ona "PC" sinceIntel hasthe ability to tune the assembly to its level best.

I dont think Intel should be in involved in all types of software but something that has to be as highly tuned as compressors and decompressors seems like s goodplace for the expertsto ensure that a fast CPU is worth while. Otherwise why not use any junk CPU and get a good GPU instead? Video card GPU's have contained onnboard decompressers forvideo for a while now.

To me as a developer GPU's lend to inconsistancy in commercial code writting so CPU software solutions are desireable over GPU's but if the CPU cant compete speed wise with GPU's I guess there is no reason for a mediaSDK either as NVidia must have a H264 compressor decompressor?

[Vladimir_Dudnik · Accepted solution]

>>IPP always converts from YUV to RGB internally. Thats been my experience.IPP never hadnative hooks
to input YUV or output YUV without going through an RGB coversion someplace in the code. This has always troubled me. Why is Intel wasting cycles on color space conversion?

I'm sorry, but can't agree with your statement above! It would be nice if you can refer to an example of IPP function which do color conversion internally (except ones which are serves specifically for color conversion).

Although JPEG2000 is international standard it still not the only and single international standard in image compression area. The level of industry adoption of JPEG2000 isnot that high as old good JPEG.

We developed highly optimized JPEG2000 primitive functions (for example wavelet transforms in IPP are really good in performance)which one might use to build high performance JPEG2000 codec. An example of our JPEG2000 codec implementation is available in sources and it can serve as a reference to see how to call IPP functions and hopefully somebody can implementcodec even better. It also possible to integrate IPP functions in other third party implementations of JPEG2000 codec to get an additional speedup from processor specific optimization.

Regarding hardware implementation of multimedia codecs (it is what I assume you mention as GPU implementation, though not quite accurate) I would agree, the trend is that widely adopted multimedia codecs go to hardware implementationnowadays, because it is cheaper and more effecient. The Intel Media SDK product is built on top of such hardware implementation in order to provide an API to access those Intel platform capabilities.

Regards,
Vladimir