Global tone mapping corruption

[lhh31]

Using Vitis 2021.2 to compile to Vivado IP then using this in a Petalinux build.

See above image (partial not the full res) when using the global tone mapping (c1 = 3.0, c2 = 1.5) when running against a 3456x3456 image. The input is a 16bit and the output an 8bit. Changing the values of c1 and c2 just give different kinds of saturation errors.

Is this a bug in Vitis or something I have done wrong in my setup?

#define XF_NPPC XF_NPPC2
#define XF_WIDTH 3456  // MAX_COLS
#define XF_HEIGHT 3456 // MAX_ROWS
#define SIN_CHANNEL_TYPE XF_8UC1
#define SIN_CHANNEL_IN_TYPE  XF_16UC1
#define XF_SRC_T XF_16UC1 // XF_8UC1
#define XF_LTM_T XF_8UC3  // XF_8UC3
#define XF_DST_T XF_16UC3 // XF_8UC3

static bool flag = 0;

static ap_ufixed<16, 4> mean1 = 0;
static ap_ufixed<16, 4> mean2 = 0;
static ap_ufixed<16, 4> L_max1 = 0.1;
static ap_ufixed<16, 4> L_max2 = 0.1;
static ap_ufixed<16, 4> L_min1 = 1;
static ap_ufixed<16, 4> L_min2 = 1;

void ISPpipeline(InVideoStrm_t& s_axis_video,
                 OutVideoStrm_t& m_axis_video,
                 unsigned short height,
                 unsigned short width,
                 ap_ufixed<16, 4>& mean1,
                 ap_ufixed<16, 4>& mean2,
                 ap_ufixed<16, 4>& L_max1,
                 ap_ufixed<16, 4>& L_max2,
                 ap_ufixed<16, 4>& L_min1,
                 ap_ufixed<16, 4>& L_min2) {
// clang-format off

#pragma HLS INLINE OFF
    xf::cv::Mat<XF_SRC_T, XF_HEIGHT, XF_WIDTH, XF_NPPC> _src(height, width);
    xf::cv::Mat<XF_DST_T, XF_HEIGHT, XF_WIDTH, XF_NPPC> demosaic_out(height, width);
    xf::cv::Mat<XF_LTM_T, XF_HEIGHT, XF_WIDTH, XF_NPPC> _dst(height, width);
// clang-format off
#pragma HLS DATAFLOW
    // clang-format on
   AXIVideo2BayerMat<XF_SRC_T, XF_HEIGHT, XF_WIDTH, XF_NPPC>(s_axis_video, _src);
   xf::cv::demosaicing<XF_BAYER_PATTERN, XF_SRC_T, XF_DST_T, XF_HEIGHT, XF_WIDTH, XF_NPPC, 0>(_src, demosaic_out);
   xf::cv::gtm<XF_DST_T, 
                XF_LTM_T, 
                SIN_CHANNEL_IN_TYPE, 
                SIN_CHANNEL_TYPE, 
                XF_HEIGHT, 
                XF_WIDTH, 
                XF_NPPC>(demosaic_out, _dst, 
                        mean1, mean2, L_max1, L_max2, L_min1, L_min2, 
                        3.0, 1.5);
  ColorMat2AXIvideo<XF_LTM_T, XF_HEIGHT, XF_WIDTH, XF_NPPC>(_dst, m_axis_video);
}

void ISPPipeline_accel(uint16_t width,
                       uint16_t height,
                       InVideoStrm_t& s_axis_video,
                       OutVideoStrm_t& m_axis_video) {

#pragma HLS INTERFACE axis port=&s_axis_video register
#pragma HLS INTERFACE axis port=&m_axis_video register

#pragma HLS INTERFACE s_axilite port=width bundle=CTRL offset=0x0010
#pragma HLS INTERFACE s_axilite port=height bundle=CTRL offset=0x0018
    // clang-format on
    if (!flag) {
        ISPpipeline(s_axis_video, m_axis_video, height, width, mean2, mean1, L_max2, L_max1, L_min2, L_min1);
        flag = 1;
    } else {
        ISPpipeline(s_axis_video, m_axis_video, height, width, mean1, mean2, L_max1, L_max2, L_min1, L_min2);
        flag = 0;
    }
}

[vt-lib-support]

For a 16bit input image with parameters c1 =3 and c2 = 1.5, we are able to see proper 8bit output image. Can you share your 16bit input image to gtm kernel. With changing values of c1, c2, saturation errors is expected.

[vt-lib-support]

Hi @lhh31 ,

There were recent updates in data types of the GTM design files. Please check if your issue is resolved with the latest code.