Developers! Developers! Developers!

[mmroden]

Remember when Steve Ballmer went bouncing around the room, yelling this loudly and everyone called him a nut?

Well, he was right. Problem is, from where I sit, Intel doesn't seem fit to pay attention to the man.

If you cared about developers, the following things would be easy to do:

1) When I log in to the site, I should be given a link to my downloads. New compiler version? No problem, here's the link. Right now, I have to download an evaluation version in order to get version updates. That is broken.

2) Too many damn choices. I don't care about atom processors. I realize that that leaves me in the minority; I only care about software. Partition your site so that people are left with fewer options. When I go to the downloads page, there are umpteen links, NONE of which actually take me to updates of my compiler version.

3) I posted a bug in IPP to premier support. They post a note that says that the bug was fixed. Great, I'm thinking, where's my download link? Oh no, I have to go hunting through the Link Jungle that is the Downloads page to get an evaluation copy.

4) Don't get me started on the IPP itself, and how it was clearly coded without any concept of ease-of-deployment in mind. Oh, too late. Every damn switch under the sun is present, and not in a cohesively explained way. When I want to perform a gaussian blur with a kernel bigger than 5x5, I should be able to hand over a kernel, an image, and a boundary condition from an enumeration. Instead, I have to, by hand, describe how the boundary conditions should be handled, including figuring out memory footprints and the like (do I count the extra buffer space on the end of a row as part of the image or not?). That's completely bogus-- do it for me, you're making a freakin' library. "Oh no," I hear developers cry, "What if you want to multithread it over tiles?" THEN WRITE IT FOR ME. You know more about how to make your processors go fast than I do, and if that's the way to make it go fast, then make it part of the library call ("Want to use all cores, or 1, or just 2 out of 8?" should be the extent of my thinking about how to parallelize these functions).

5) The IPP isn't consistent. Take the erode/dilate functions. Erode and Dilate, as they are presented, just do not work on a whole image. Instead, you have to ignore the boundaries. So, there are functions for erode and dilate that take into account the boundaries. These functions are called with a parameter that can only be "IppBoundary1", and also require a memory object that is created before use and then destroyed immediately after. Clean that up! There is no explanation for why I have to see that memory object (MorphologyInitAlloc and MorphologyFree), they're just there. And! There are 16u versions of the erode/dilate functions, but not of the functions that work with the boundaries! What the HELL!

I got a survey asking how I would like to see IPP deployed to C# and .NET. That would be great, but you guys have a lot of housekeeping to do before I would even consider going through some kind of translation layer to use these libraries. Make these things work from the perspective of the coder, not the perspective of the engineer who is writing the function. Think about your customers, not yourselves.

Maybe I could post this in a nicer way, but I've been frustrated by this kind of malarkey for the last several years when dealing with these products. Your motto on the compiler/software side should be It Just Works, and my requirements to deal with images should be no harder than a Matlab function call. If I have to deal with memory or stepping or any other of that BS, then You Have Done It Wrong. If I have to hunt for links to the Latest Greatest updates, then You Have Done It Wrong. If I don't automatically get a link to the patch that contains the fix that I suggested, then You Have Done It Wrong.

Now, if you'll excuse me, I have to go back to making erode and dilate work with a set of ushort images. I might just roll my own, especially since the IPP's break with no explanation and it turns out that it's a boundary condition that's handled by an entirely different function call.

mmr

[softrite]

Do you mean you will go back to programming AFTER you take the cold shower?
(giggle)

ipp is indeed very difficult to impliment and samples/documentation really on the sparse side. You are lucky to get a response here and if you do it's often days later. Lets see, I get paid somewhere between $50-$100 an hour as most of the rest of you... so while I am sitting on my hands waiting, who is paying the bill?

Maybe I will go take a cold shower while I'm waiting as well...

[mmroden]

Quoting - softrite

Do you mean you will go back to programming AFTER you take the cold shower?
(giggle)

ipp is indeed very difficult to impliment and samples/documentation really on the sparse side. You are lucky to get a response here and if you do it's often days later. Lets see, I get paid somewhere between $50-$100 an hour as most of the rest of you... so while I am sitting on my hands waiting, who is paying the bill?

Maybe I will go take a cold shower while I'm waiting as well...

Well, I just took one, and that didn't help much at all.

I'm actually paid per project, rather than per hour, so I'm the one paying for the delay, which may be why the shower doesn't work that well...

[Chao_Y_Intel]

Hello mmr,

Thanks for your feedback. I can understand some difficulties on using some functions. It looks you are getting some questions. Hereis some information that mayhelp your problem( maybe for some others here :-))

1) Regarding downloading IPP packages, users can download the latest IPP release (and some old IPP releases) from software products registration center:
https://registrationcenter.intel.com/regcenter/register.aspx
If you have registered for your products, you can login in with your account and password, and download IPP releases.
If you get any problem to login into that site, you can this site to get the start-up support for your accounts.
http://software.intel.com/en-us/articles/download-registration-licensing/

2) For handling image border for image border, we find a few users have questions on that.
The document at the image processing manual (ippiman.pdf), Chapter 9, "filtering Functions", "Borders" sections, has some detail discussion.
Is the information enough? (or too much to understand :-) )

The following article may also be helpful to understand the image borders:
http://software.intel.com/en-us/articles/intel-integrated-performance-primitives-intel-ipp-processing-an-image-from-edge-to-edge/

3) Regarding "Erode and Dilate" functions, it is true that 16u data is missing in DilateBorderReplicate/ErodeBorderReplicate functions. We added 16u data support in recent IPP releases from the customer request, but not all of the functions add16u functions. Too much work if we add it for all functions, as you know we have many functions in IPP now. I can track the request, so our development team will consider it in the future release.
For additional "memory allocation" for these functions, someusers want to manage the memory allocation by themselves, other than that the library handle this for them. Such way is more flexible. I agree that for some users, this may require some additional work...

IPP forum is a good place to ask question, feel free to share your problems. So users can help each other.

Regards,
Chao