NppiBorderType of NPP_BORDER_MIRROR details not documented

Section 7.2.2.7 of the NPP document specifies a NppiBorderType of NPP_BORDER_MIRROR but does not explain exactly how it mirrors the pixels. OpenCV uses two flavors of “mirror” : BORDER_REFLECT and BORDER_REFLECT_101.

The behavior of “mirror” for the function nppiFilterGaussBorder_16s_C3R is what I am particularly interested in.
When used for blurring up-sampled data in Laplacian Pyramids its important that BORDER_REFLECT_101 is used to get correct
results at the edges.

The OpenCV docs at
http://docs.opencv.org/2.4/modules/imgproc/doc/filtering.html
demonstrate the difference:

BORDER_REFLECT:         fedcba|abcdefgh|hgfedcb
BORDER_REFLECT_101:   gfedcb|abcdefgh|gfedcba

Which one does NPP use for NPP_BORDER_MIRROR?

–thanks, w

it should match the behavior of the Intel ipp functionality:

https://software.intel.com/en-us/forums/intel-integrated-performance-primitives/topic/295847

Thanks – it does seems to mimic BORDER_REFLECT_101 (which is what I want).
One of the replies used the following test case:

INPUT:  1 2 3 4 5
FILTER: 1 1 1 1 1
OUTPUT 11 12 15 18 19

which would be what BORDER_REFLECT_101 would give you.
It would be nice to see an actual document somewhere that
specified this behavior. The Intel docs just say it “mirrors” which
is a bit ambiguous.

“a little thin” and “giant PDF” seems like a contradiction in terms. I guess what you mean is that the PDF is huge but there is relatively little information for each individual function?

I would think that is a consequence of the vast number of functions provided by NPP. As you can see from the Intel IPP documentation, a similar problem exists there. If each function were extensively documented, the PDF would become even more unwieldy. Seem like a fundamental issue that is difficult to address.

In practical terms, you might want to file an enhancement request with NVIDIA to have this particular functionality documented in a bit more detail. You can do so via the bug reporting form linked from the CUDA registered developer website, simply prefix the synopsis with “RFE:” to mark it as an enhancement request rather than a functional bug.

Aha – I did find the Intel Specifics for this:

https://software.intel.com/en-us/node/504117#SECTION_2E4BC8BDC7EE457D850EA777F5E86229

Mirror Border = OpenCV’s REFLECT_101
Mirror Border with Replication = OpenCV’s REFLECT

Nice.

To njuffa:

Yes, by “a little thin” I do mean that there is little beyond just the function and definitions (I might as well just grep through the header files). Yes, “by a giant PDF” I mean it is just a giant PDF – at least some HTML to hypertext through would be an improvement. There needs to be a way to see the forest without having to look at each tree – and each tree should have more detail.

I know documentation is hard. I think OpenCV does a fair job of both overview and details (like the their BORDER_REFLECT_101 example). You need both. I could file an enhancement request, but it doesn’t seem like documentation is a high priority.

The only thing I can tell you with regard to enhancement requests in general is that improvement-worthy aspects aren’t likely to improve in the absence of RFEs. Large software projects tend to be driven by formal databases of bugs and enhancement requests.

This is pure speculation, but the fact that the NPP documentation is so voluminous may be what precludes HTML generation, while still allowing PDF generation. Many of the tools I have encountered for automatic generation of documentation from source code annotations start to break when the amount of data becomes large. Since NVIDIA provides documentation in both HTML and PDF formats for all other libraries, this seems like a plausible hypothesis.

What are need are two separate documents. One that gives the overview, general description of each class, etc… and another that is a detailed reference manual for each function. One is usually called the “programmer’s manual” and the other the “reference manual”.

Your proposal seems worthy of an RFE.

Unfortunately this is currently moot – I just discovered the following in the document under FilterGaussBorder"

Currently only the NPP_BORDER_REPLICATE border type operation is supported.

I guess I’ll go write my own kernel.
If you want to get something done, ya gotta do it yourself.