I have ran into an issue with IPP JPEG I cannot sort out on my own.
Namely I am experimenting with an encoder I wrote which should have lossless as well as lossy mode.
I made it so that if I pass quality 100, it performs just DCT with no quantization using ippiDCT8x8Fwd_16s_C1R() and I perform level shift beforehand. Mind you I work with 16-bit data (12 bits are actually important) and so far I am just storing the result of the DCT to see if I can reverse the operation.
When the quality is less than 100 then I call ippiDCTQuantFwd8x8LS_JPEG_16u16s_C1R() without performing level shift on my own and I pass it properly prepared quantization table.
Calling ippiDCTQuantInv8x8LS_JPEG_16s16u_C1R() works fine, but with ippiDCT8x8Inv_16s_C1R() I get complete garbage.
I checked the documentation and I was astonished to find that ippiDCT8x8Inv_16s_C1R() has this warning:
CAUTION: Source data for 16s flavors must be the result of the forward discrete cosine transform of data from the range [-256, 255], they can not be arbitrary data from the range [-32768, 32767].
Function documentation for ippiDCT8x8Fwd_16s_C1R() does not mention anywhere that its output is limited to 9 bits!!!
So why do you advertise 12-bit or even 16-bit support for JPEG when it simply doesn't work?!?
What is the rationale behind "regular DCT without bundled quantization and level shift doesn't support more than 9 bits" and is there any way around this nonsense?
I am sorry if I sound pissed off but it is because I put a lot of time into this and I need help really quick like yesterday.
I find IPP documentation sorely lacking on this subject.