Intel® Software Network

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

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

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

 Vladimir

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

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

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

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 (with IPP-IPL).  As Vladimir hinted our focus was to make it as easy as possible to move from one to the other, and avoid breaking software with the new API   We knew we couldn't support both libraries in the long run, so migration was the answer.

What we really wanted to do above IPP was not focus on IPL 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 think most developers prefer to use a higher-level API and that there 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 to overtake 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 IPP team would not be able to take on, would be testing the compatibility between IPL and IPL-IPP.

I'm afraid I spent more time reminiscing than answering the question.

Stewart

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 with improved 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 with IPP like tiled images and multi-channel (non-RGB and/or non 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

I'd like to add another dimension to this discussion of IPL vs. IPP by considering the larger impact IPL has had.

IPL was a well-designed, efficient library that had no real equal. Its capability, combined with its free availability, caused it to be widely adopted, in a number of contexts. Apart from its commercial usage, it has played a pivotal role in many academic settings:

• IPL is widely used in undergraduate- and graduate-level classes to help teach graphics and computer vision. For example, projects in Georgia Tech's digital video special effects class rely heavily on IPL and OpenCV (see, for example, student projects and their write-ups citing what packages they use at: http://www.cc.gatech.edu/dvfx/videos/dvfx2004.html). Its use at other schools can be observed by performing a search for IPL at Google
  
• IPL enables research in domains such as human computer interaction and new digital media. Personally, I have used it to create a new method of rendering time-lapse data, where multiple points of time can viewed simultaneously: http://www.cc.gatech.edu/~mterry/timemaps
  
• IPL is even used as a benchmark. See: http://www.cs.colostate.edu/cameron/ipl.html
  

These are just a few examples drawn from a quick search for IPL on the Internet; many more could be added to this list. The points I'd like Intel to consider in this discussion of IPL and IPP are these:

• IPL does some things well that IPP either cannot do or cannot do well (e.g., image tiling or basic operations such as per-pixel copying)
  
• IPL's API is at a convenient level of abstraction for many common image manipulation tasks; the developer can quickly begin using the functionality of IPL without a lot of code
  
• IPL works well on older processors. Given the tight budgets of many institutions, both commercial and academic, older flavors of Pentium processors are going to be in use for some time. While it is understandable that Intel's IPP dev team wants to cater to new processors, there is still a significant and real need to develop for all the older machines out there
  

In laying out these points, I am not suggesting that Intel continue development on IPL. Rather, I would like to see an option where this library is still available for use, whether as part of an IPP purchase, or as a standalone, unsupported free download, as before. If it could be integrated with IPP using one of the suggestions in this thread (e.g., via namespaces), that would be terrific. But overall, it simply has too much value to be hidden away and ignored.

Thanks for your consideration,

Michael Terry

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 ?

 

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(R) Itanium(R) 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

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!

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

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(R) Premier Support.

We were unable to authenticate your access to the Intel(R) 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!

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

Vladimir