search

Xilinx / xfopencv

Other
321 stars 144 forks source link

Possibly wrong DataType for signed pixel types in include/common/xf_types.h #32

Closed ghost closed 5 years ago

ghost commented 5 years ago

I am currently trying to instantiate an xf::Sobel kernel on single-channel xf::Mat images with signed 16 bit integer values (i.e. of type XF_16SC1). However, there seems to be a bug that causes all operations to be instantiated with unsigned values instead.

Digging deeper, the cause seems to be the macro XF_TNAME(SRC_T,NPC) that is used in xf::Sobel (and lots of other places). It uses the specialization of the DataType<XF_16SC1,XF_NPPC1> traits class in include/common/xf_types.h:128. Almost all signed (XF_xxSCy) data types have ap_uint<xx> as the name; only the specialization of XF_16SC3 seems to use a signed ap_int<xx> type. Shouldn't the type for all signed types be ap_int<xx> instead, or am I missing something here?

bgouthamb commented 5 years ago

Hello @andreasmuetzel-ametek ,

The XF_TNAME(SRC_T,NPC) is always meant to resolve to unsigned type. This datatype is used as a container for the incoming/output data, but all the core processing happens after typecasting to appropriate data type. XF_16SC3 is not used currently in any functions and it will also be modified accordingly in the future release.

ghost commented 5 years ago

Hi, thanks for the explanation! Sorry, this whole "integer type number as a template parameter" is really confusing if you're used to directly using types as template parameters...