I'm using IPP 6.1.2.041.
I need to convert RGB image to HSV color model. I have a simple 2 pixel image to test, first pixel is RGB 0,0,254 (near pure blue), second pixel is
0,255,1 (near pure green).
First Pixel in HSV should be 240,100,100, but IPP sets first pixel components to 170,255,254.
Here is code for the simple test program I wrote (ReadImageJPEGHighLevel basically just calls ReadImageJPEG in jpeg.cpp that is included with IPP decoder package).
1) First is the JPEG reading method:
I'm currently using bilteral filtering of IPP (ippiFilterBilateral_8u_C1R) but i encounter som problems of linking during compilation.
I went to the link above to be sure that everything is ok concerning Visual Studio 2010 settings:
i give the include directory and the additional include directory : "C:\Program Files (x86)\Intel\Composer XE 2013\ipp\tools\ia32\staticlib"
I detected an issue related to Loading and Unloading steps for Waterfall DLLs ( Instruction Set specific ).
Let's say I've compiled an application ( 64-bit / Dynamic linking of IPP libraries ) that could work on CPUs that support AVX Instruction Set ( code e9 for Waterfall DLLs ). A test case starts with a call to ippInit function in main function:
[ Source codes ]
Cross-posting from http://stackoverflow.com/q/15836542/90475
Here's my code... I intend to run IPP FFT over millions of 1D traces by calling Correlate(): **performance matters**.
In Visual Studio profiler, I can see IPP DFT calls taking a lion's share of time when running with a low number of processes.
I am having a strange problem using Intel ipp jpeg compression for my 64 bit windows application... the color conversion function ippiBGRToYCbCr_JPEG_8u_C3P3R defined in ippj.dll gets bizare frequently and seems like it stucks somewhere and gets slower. its quite random but I did some timing checks and it seems that this function does not work properly for me. Same function in 32 bit dll is working fine but in 64 bit its creating problem. Can anyone help me please.. If somebody wants i can upload the compression timing test which i made.
Can the source and destination parameters for ippsFIR_32fc (the non-inline version) safely be the same array?
What is the fastest way to upsample or downsample a signal, given that both block sizes and up/downsample ratios are all powers of 2? For some audio processing filter I need to upsample and downsamplte my signal 16 (!) times, and I need to repeat this a lot of times per block of audio - my current method doesn't even run in realtime on my i7 system. Most important restriction: After downsampling the upsampled signal, the result must be identical to the original (except for rounding errors of course).