Hello,
Just downloaded the npp sample, and its working very well.
It seems that after filter processing, ex. nppiFilterBox_8u_C1R, the resulted image needs to be reduced a little according to the kernel size used.
This is inconvenient for real world applications.
Is it possible to avoid this? For example, just use the source data to fill the border of the resulted image?
Thank you!
That’s an effect of convolution, not of CUDA. You can try edge extraction to get rid of some of the effects, i.e. that the border of the image is used to define values outside of the image, rather than setting those pixels to 0. This can be handled automatically if you store the image in a 2D texture.
Thank you, wanderine.
In opengl, it is automatically handled, also ipp.
Actually IPP does not automatically pad border pixels either. You can use nppiCopyConstBorder to expand your input images to appropriate size, so that the convolution result is the same size as the input.
IPP does have a small number of filters that do support clamping and we (NVIDIA) could provide something similar in NPP if the general consensus is, that that would be helpful. Automatic clamping comes at a performance penalty, in particular for large image sizes. Can you let me know which particular filters (filter type, number of channels and data type) you think we should provide?
I already made a similar request here:
user-defined texture border color and a wrap mode (GL_CLAMP)
Why it is not possible to write textures? Probably some hardware limitation?
Personally I would be fine with just 8-bits single channel images. For machine vision that data format covers a large percentage of scenarios.
OR, it would be nice if there were functions that received textures instead of pointer to memory, I don’t know if it would make things simpler. Only nearest-neighbor accesses would be required as the filters only use integer-coordinates anyway.
OK. So single channel 8-bit is most important for you. Which filters that require expanded input regions would you like to see with the additional option to specify clamping rules?
Regarding textures as inputs to primitives: If NPP had gone that way, it would have been more complicated for users to chain filters: A user would have to take the raw output from the first filter, bind it to a texture, pass that to the next filter, unbind, and-so-on.