The first page of the documentation on the geometry functions (node 504351) covers ROI processing, and in fact states that all functions take an IppiRect parameter to specify the source and destination ROIs. Reading through the documentation on the resize functions, it appears that none of the functions take such parameters. Is the overview description of the geometric transforms correct, or have those functions completely gone, with different parameters now (destination point and size only)?
There are some differences of ROI processing for resize functions. The functions resize the source image ROI origin to the destination image ROI origin. The destination image ROI origin is defined by the following parameters: the offset of the tiled destination image with respect to the destination image origin (dstOffset) and the destination ROI size (dstSize). The source image ROI origin is defined automatically.
The ippiResizeGetSrcRoi function with the corresponding mod value can be used to obtain the source image ROI.
thanks for the answer. I understand that the parameters are different, but it is not clear to me that the functionality of 8.x is available in 9.x. Perhaps what would help is some pseudo-code that shows how to map the parameters that are passed to the 8.x ippiResizeSqrPixel functions. If the functionality is still there, it presumably is possible to generate a wrapper for the new ippiResize that mimics the functionality of the old ippiResize? I understand that the "warp" functions can be used as replacements in 9.x, but that is more work than a simple wrapper.
Your answer (that there are differences of ROI processing) also doesn't seem to jive with the description on page 504351, which states that the src and dst regions are defined by IppiRect structures - which doesn't seem to be the case, based on my reading and also your answer.
Unfortunately ippResize<Interp> functions do not cover whole ippResizeSqrPixel functionality. ippResize<Interp> functions do not support explicit scale factors (xFactor,yFactor), real (sub-pixel) image shifts (xShift,yShift) and explicit source ROI (srcRoi).
If the mentioned above parameters are important, ippiWarpAffine* can be used instead ippResizeSqrPixel functions, otherwise ippResize<Interp> can be used.
Patrick, are the mentioned above parameters important for your task?
The use of ippiWarpAffine (as I mentioned earlier) is an option for us. However the documentation (particularly node 504351) needs to be fixed - it should explicitly say that the resize functions do NOT follow the model described (as they don't).
The changes to use of ippiWarpAffine in principle allow us to use 9.0, but unfortunately a larger problem is the loss of the jpeg functionality. We did start exploring a mixed deployment (8.2 for the jpeg support and 9.0 for the remainder), but that doesn't seem easy to get working. My guess is that we will thus have to stay on 8.2 until there is an alternative to the jpeg functions, or look for a complete replacement for all of ipp.
I have seen comments from other developers about the changes in the resize functions and the jpeg functions, so we are not alone in using those aspects of IPP. My read is that Intel is moving away from this domain (an obvious sign that we should be looking elsewhere for image processing support!).
Thank you, we will review our documentation and make the required changes. However IPP team are working to make easier transition from IPP 8.2 to IPP 9.0. Keep watching for announcements.