You have a striding problem. Change this line:
npp::ImageCPU_8u_C4 oHostDst(oDeviceDst.size());
To this:
npp::ImageCPU_8u_C4 oHostDst(oDeviceSrc.size());
What is happening?
Let's assume your input image is 600x450.
oHostSrc
is 600 x 450, and the pitch is 600x4 = 2400.- the
memcpy
fromdata
tooHostSrc
is ok because they have the same width and pitch. oDeviceSrc
picks up the size fromoHostSrcc
(600x450)oDeviceDst
is slightly smaller thanoDeviceSrc
, because it only picks up the size of the ROI, so it is something like 596x446.- Your code was creating
oHostDst
to be the same size asoDeviceDst
, so about 596x446. - The
.copyTo
operation copies the oDeviceDst (pitched) 596x446 image to (unpitched)oHostDst
, also 596x446. - The final
memcpy
breaks the image, because it is copying a 596x446oHostDst
image to a 600x450data
region.
The solution is to create oHostDst
at 600x450 and let the .copyTo
operation handle the difference in line sizes and pitches.
The original code didn't have this problem because there were no unpitched copies anywhere in that code (e.g. no use of raw memcpy
). As long as you handle the source and destination pitch and width explicitly at every copy step, it does not matter whether you create the final image as 600x450 or 596x446. But your final memcpy
operation was not handling pitch and width explicitly, instead it implicitly assumed both source and destination were of the same size, and this was not the case.