Copy (move) pixels within an Image

[Mikael_Grev]

Hello,

Maybe I'm just unable to find it (but I have been browsing the manuals for an hour) but I can't seem to locate a function like ippiCopy_xx that works for overlapping RIOs. ippiCopy doesn't work if the memory areas overlap unless the delta x and delta y are both zero or negative.

It's quite common to want to move around an image within another one so I one such function must exist. It's like memcpy vs memmove. Can someone point me in the right direction?

Btw, am I suppost to post these things on the premier support site?

Cheers,
Mikael

[Vladimir_Dudnik]

Hi Mikael,

no sense to submit simple 'how to' questions to premier support channel. That is what this forum stands for.

To copy overlapped memory regions you may need to use ippsMove function. We do not have 2D variant of this function, so youneed todo copy on row by row basis.

Regards,
Vladimir

[Mikael_Grev]

Thank you, then I know.

Isn't it a bit odd that a 2D version is missing? Especially since it is quite easy, and without performance implcations, to modify a normal copy to be overlap sensitive?

Anyway, thanks for the answer. And the otherwise very good lib!

Cheers,
Mikael

[Vladimir_Dudnik]

There is performance implication if normal copy had to also support overlapped regions. That is why special functions implemented in C run time and in IPP libraries.

For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP

Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?

Regards,
Vladimir

[Mikael_Grev]

Quoting - Vladimir Dudnik (Intel)

There is performance implication if normal copy had to also support overlapped regions. That is why special functions implemented in C run time and in IPP libraries.

For 2D case you can just write a wrapper on top of ippsMove function and potentially even thread this with OpenMP. This will be very similar to what it may look like if implemented in IPP

Thanks for your feedback. Can I ask you what kind of applications you develop with IPP? What are the most important features of IPP from your prospective and what are the weak areas?

Regards,
Vladimir

Thanks Vladimir.

On my system memmove and memcpy seems to have the same speed. Actually you just iterate from the start or beginning depending on if the dest is before source or vice versa. Really simple unless you have some really funky optimizations (which you might have, I have no idea).

I have made such a wrapper. Speed is satisfactoy.

I am creating a VNC-like app with a very advanced codec. It is the high level parts that are advanced btw, and I am using IPP for parts of the codec. Mostly the Jpeg codec and some copy functionality.

I find the speed most satisfactory for the most part. I miss the Java way of documentation, but that is more a C/C++ problem.

The only performance problem I have found is in the function that swaps bytes in an int, essentially converting from lille- to big endian and back. My own function is much faster there (using bswap asm).

You should have a look at quicklz.com. It is an _extremely_ fast compressor/decompressor. Much much faster than anything you have I think. One problem is that if I compile it with ICC 11.1 and enable -parallel then it sucks upp all 4+4 cores on my Mac Pro i7 and performs 50% worse... Strange.

Keep up the good work!

Cheers,
Mikael

[Vladimir_Dudnik]

Thanks Mikael,

regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"

It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?

Regards,
Vladimir

[Mikael_Grev]

Quoting - Vladimir Dudnik (Intel)

Thanks Mikael,

regarding quicklz speed - the key phrase I found on the link you provided I believe was: "Speed is favored over backwards compatibility"

It is always possible to simplify the things in favour of performance. But the next question is what customers will do with their already existed achives?

Regards,
Vladimir

True, but there are good use cases, like my codec which encode+decode on the other side in real time. I can always keep the two in sync version wise.

Cheers,
Mikael