Migration from IPL to IPP

[adi_shavit]

Hi,

I was wondering about the IPP IPL emulation that comes with the IPP examples. This is very useful to help migrating IPL apps to newer processors in a gradual manner.

However, in the attached manual it is clearly stated that some IPL functions are faster than the IPP implementation.

I think that for getting the best of both worlds, it would be very convenient to add an additional #define compilation flag that would create a different library name, e.g. ippipl.lib[dll], and put the new functions in a different namespace, e.g. IppIpl, so that "IPL" functions can be mixed from both implementations.

Would this be possible?

Thanks,

Adi

PS,

The IPP-IPL manual says that 1u (and tiled) images are not supported. In fact, 16s images aren't suupported either in many of the functions. Perhaps this should be mentioned too.

[Intel_C_Intel]

Yes, it is possible as a particular solution for particular user. But

remember, it will require changes in users source code because of different function names. It is the thing we don't want to do in this sample.

Regards,
Vladimir

[adi_shavit]

Actually, that's what namespaces are all about.

They allow you to avoid function name collisions.

Say you have a flag that enables the namespace IppIpl, and the project compiles to IppIpl.lib, (if the flag is off we get the regular compilation as today).

Now, in my project, I can use iplAdd() to get the IPL iplAdd() and IppIpl::iplAdd() to get the Add() function.

There will be no collisions.

The idea is to just add a scope for the names instead of them sharing the global namespace.

Adi

[Intel_C_Intel]

Yes, it is good solution, with only one remark. It looks to IPL, but welookto the forward.

Actually, it is the thing we wanted toget when wedecided to replace IPL library with IPP sample, available in sources. The user will decide how long he needs in IPL interface in their project, when it is the good time to go to the new interface which provided with IPP.

Regards,

Vladimir

[adi_shavit]

That's all good and well, but since more tha a few IPL functions are still faster than their IPP equivalent, I think many people would like to enjoy the benefit of both libraries together.

Adi

[Intel_C_Intel]

Yes,and they can create such modifications himself, right?

Vladimir

[adi_shavit]

That's right. Anyone who cares enough will have to do the same repititious task of trying to separate IPP-IPL from old IPL.

Anyway, it was just a suggestion.

Thanks,

Adi

[Intel_C_Intel]

Thank you for sharing your ideas, I hopethis conversationwill be useful for many people whouse IPL and IPP.

Vladimir

[Intel_C_Intel]

Hi Adi

Fortunately, now we have good opportunity to talk about migrating from IPL to IPP directly with Stewart Taylor, who was chief architect for both IPL and IPP libraries. So, I think, it is interesting to know his opinion about that.

So, actually, the question is:

Stewart, what do you think, should IPL-IPP compatibility layer provide the possibility to use old IPL as well as new IPP?
I'm afraid it will froze people on old interface instead of moving them to the new one.
Adi's reasons is functionality. The IPP do not support all the functionality which IPL did (and people did use).

Regards,
Vladimir

[adi_shavit]

Bingo! Vladimir.

I agree completely. I am eager to hear Stewart's answer.

I have been using IPL (gee... I can't remember) I guess at least 4-5 years. I was very happy when IPP came out but to tell you the truth, we are still using IPL today in combination with OpenCV, due to the very different interfaces (IPP is lower level) of the 2 libs. Only when I need additional performance boost do I whip out IPP for the job. These are usually localized functions and (as I explained on a different thread) use local interface converters that allow an IplImage (w/wo ROIs) to be easily accessed and passed to an IPP function.

When I saw the IPP based- IPL implementation I was very happy since finally I could port everything to IPP. However, there are still many functions in which IPL out performs IPP, according to the projects documentation.

I look forward to Stewart's reply.

Thank you,

Adi

[vipulchawathe]

As an experienced C Plus Plus programmer I prefer the namespace approach to the solution as it prevents making a contribution of another dll in the already huge crowd of dlls, however, if the output file size is an issue then maybe you have no option but to make separate small dlls for each functionality you might intend to use.

[Stewart_T_Intel]

I think we should have included the potential for coexistance between IPL and IPP in our original plan, but we were focused on making a sufficient replacement for IPL(withIPP-IPL). As Vladimirhinted our focus wasto makeitas easy as possible to move from one to the other, and avoidbreaking software with the new API We knew we couldn't support bothlibraries in the long run, so migration was the answer.

What we really wanted to do above IPP was not focus onIPL but replace the IPL API, which was always something of a compromise between performance and convenience, with something more convenient, something nice and object-oriented. I thinkmost developers prefer to use a higher-level API and thatthere were two sub-types: those who want to write (or have written) their own image class, and those that haven't and don't. Given that assumption, it makes sense to provide an image class (which we do somewhat in the samples), and design IPP so that it fits nicely under someone else's image class.

We also figured that within a processor generation or two, if not immediately, we would certainly overtake the IPL performance with IPP, and that everyone would move over. Of course, as you point out, there are two gaps in this reasoning: 1) Performance may not be enough to justify using a lower-level API and 2) IPP-IPL is unlikely toovertake IPL in every instance, no matter how many intervening processor generations.

Keeping all that in mind, if enough people continue to use IPL to this day, then why shouldn't the IPL-IPP layer should support that or enable it? (Can I see a show of hands?) It doesn't seem to me to be an implementation burden. The real burden, and one the IPPteam would not be able to take on, would be testing the compatibility between IPL and IPL-IPP.

I'm afraid I spent more time reminiscingthananswering the question.

Stewart

[adi_shavit]

Hi Stewart,

Thanks for the candid reply. I agree with the multi-layer approach that you refer to. It is indeed empowering to those who need it while simplifing thing for those who do not need the extra power.

I just have two notes/questions.

1. In another post(IPP and modern C++ techniques at http://softwareforums.intel.com/ids/board/message?board.id=IPP&message.id=107 ) I suggested and we discussed a more modern C++ approach for this second (actually 3rd)layer. Given the IPP C++ sample project, which uses typed data arguments, this compile time (no-runtime-overhead) layer could indeed replace most of IPL functionaly withimproved OO elegance and improved efficiency as many IPL run-time decisions will be made at compile time. I think this layer, should be developed with Intel cooperation to ensure compatibility and regular updates. I will try to post a basic skeleton of my idea soon.
2. I was interested to know what makes some of the IPL functions faster than their IPP equivalents. Even though the API is different, the basic algorithms should be the same, and should give similar performance on all versions.

Regarding your informal pole, it would be interesting to know how many people actually use IPL features which are (currently) in compatible withIPP like tiled imagesand multi-channel (non-RGB and/ornon 1,3,4 channel) images.

99% of my own usage is of the "basic" RGB/BGR/grayscale images with standard depths of 8U/8S/16S/32F. IPL also needs 1U images as masks.

Adi

[tyezek]

I have to agree with Soulfry99. We use both the IPP and IPL libraries. The IPL library works better for our image sharpening, since it allows us to directly select the sharpening kernel, something the IPP does not do. (See IplConvolve2D, for instance - the kernel weights can be directly specified in iplCreateKernel). If I'm just being simpleminded and there is a way to easily do this in the IPP library (I'm using IPP 2.0, which I am aware is outdated), please educate me; otherwise, I'm really pretty well forced to keep using the IPL library. Was an Itanium version of the IPL ever produced ? Any chance of downloading the lib & dll if so ?

[Vladimir_Dudnik]

Hi,

we had stopped development of IPL library and concentrated on IPP. I has mentioned some of the reasons for that earlier in this thread.

There were no IPL library for Intel Itanium processor. And there is no more possibility to download this old library.

But IPP is growing from version to version. There were a lot of addition and improvements from version 2.0 you still using. Why did not you try to evaluate the latest version of IPP?

If I understood you correctly you can try to use IPP function ippiFilter. It is similar to iplConv2D but allows you to select sharpening (or any other) kernel directly.

Regards,
Vladimir

[nrw]

Hi,

you mentioned an IPP-based IPL implementation. I'm in the process of porting some software from IPL to IPP, so this sounds very interesting to me. Is this implementation still available ,and where could I get it? Many of the interfaces in IPP are very different from the IPL versions so it is sometimes difficult to find an equivalent. I have ipl-ipp.pdf, which has been very helpful so far, but an IPP-based IPL implementation would be even better still.

Thank you!

[Vladimir_Dudnik]

Hello, unfortunately that sample is not more available. Please submit your request to Intel Premier Support, we can see how we can help you

Regards,
Vladimir

[nrw]

Hi Vladimir,

thanks for your response! The page gives me an error saying I need to log in using https://.. If I do that, I can enter a login and password, but I'm always getting the page:

---

Welcome to Intel Premier Support.

We were unable to authenticate your access to the Intel Premier Support web site. Please check that your login ID and password were entered correctly and that the URL used was "https://premier.intel.com".

If you have forgotten your login or password, the fastest method to gain access to the system is to use the automated login and password links Forgot your password or Forgot your Login ID on the login page.

If you continue to have problems, please contact Intel Customer Support via email at ... at mailbox.intel.com.

---

If I click "forgot your password" and enter the name "nrw", I receive an email with the account + password I use on this forum, so those should be valid account data for premier.intel.com as well?!

If you don't know why this is happening I'll try mailing that intel address tomorrow, but I need to go home now ;-)

Thanks!

[Vladimir_Dudnik]

yes, it is better to contact with support service regarding login issue, I do not know what can be the reason for that

Vladimir