• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 99 subscribers
  • Views 986 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM365 & Appro IPNC application, Resizer Config

reda38
Expert 1455 points

Hello again,

Going deeper in the IPNC application driver customisation for my YUV422 camera, i am struggling to get resizer output nice images.

The drv_resz.c code takes a VGA yuv image in input from sdram (stored as 8 bits per pixel clock, one component per clock, in the order Y, U, Y, V) and sends it through the IPIPEIF and then to the RESIZER for resizing in two pipes : one is a test for 1:1 resizing and the second is a QVGA resizing.

There are many parameters to play with and it appears that my images are not proper in output viewer.

First of all, if I try to set the IPIPEIf correctly :

gDRV_reszObj.inSrcConfig.inputSource2           = CSL_IPIPEIF_INPUT_SOURCE_SDRAM_YUV;

gDRV_reszObj.inSrcConfig.isifInType       = CSL_IPIPEIF_ISIF_INPUT_TYPE_YUV;

since     inType==DRV_DATA_FORMAT_YUV I set :

gDRV_reszObj.inConfig.inputDataPath      = CSL_RSZ_INPUT_DATA_PATH_IPIPEIF; //Data is to be passed through IPIPEIF to RSZ

 

I still have concerns with the following parameters. Unpack Mode and rawDataShift. It looks like that the application is only waiting for YUV420 or pure RAW bayer sensors.

I have the default parameters :

      gDRV_reszObj.ddrInConfig.rawUnpackMode = CSL_IPIPEIF_SDRAM_IN_RAW_UNPACK_MODE_NORMAL_16;
      gDRV_reszObj.ddrInConfig.rawDataShift  = CSL_IPIPEIF_SDRAM_IN_DATASHIFT_BITS_11_0;

What to put in them ?

Since a pixel is the equivalent of 2bytes do i need to keep the unpackmode16 ?

For the second parameter it looks like there will be a truncating of data. So do I need to put CSL_IPIPEIF_SDRAM_IN_DATASHIFT_BITS_7_0 if we consider 8bits per pixel clock is the reference, or is this parameter will be set apart by the hardware since input format is yuv ? I have not found the CSL_IPIPEIF_SDRAM_IN_DATASHIFT_BITS_NOBITS to keep the 16 bits (if pixels are 16bits packed and processed) ?

There is also a problematic info. It is in the datasheet VPFE sprufg8a.pdf. At the page of ImagePipeIF and modes. Paragraph 4.6.5: SDRAM YCbCr4:2:2 Input Mode.

"When the input source is YCbCr4:2:2 data from the SDRAM read buffer interface, the data is expected to be stored as 16bits in memory, so there is no shifting or other preprocessing done".

So what do we need to do with this info. In this sentence what means data ? a whole pixel (16bits Y+U or Y+V) , or only a 8bits pixel component stored on 16bits(Y, or, U, or V?).

And how to get rid of the shifting ?

For test I input a YUV8 4:2:2 colour bar captured by the drv_isif example program.

Thank you for your help.

 

  • 0
    TI__Mastermind 19985 points

    Hi,

    I will try to get you the source code for YUV input mode that we have developed for IPNC. I hope that will help you.

    Meanwhile, i want to understand your data flow. If your data flow is as below:

    YUV sensor --> ISIF --> DDR --> RSZ A --> DDR

                                                      |--> RSZB --> DDR

    then from our previous conversation you would already have got the YUV422 data from ISIF in DDR correctly. Isnt it?

    If yes, then you just need to refer to DRV_reszRun() API in drv_resz.c and call the resizer to either do color conversion from YUV422 to YUV420 or downscaling from VGA to QVGA.

    Am i understanding your problem correctly?

    Regards,

    Anshuman

    PS: Please mark this post as verified if you think it answers your question. Thanks

  • 0 in reply to Anshuman Saxena
    Expert 1455 points

    Hi Anshuman,

    Nice to hear from you. I have made some tests laely this friday with the configuration i gave you. And it worked.

    My pipe is for the first step:

    YUV sensor --> ISIF --> DDR : this was done when we talked about the ISIF interface YUV8 issue.

    In a second step, using the ipnc drv_resz.c:

    DDR --> RSZ A --> DDR

             |--> RSZB --> DDR in parallel of the rszA.

    I tried output in YUV422 and YUV420 and it got images which are ok. except that yuv420_semiplanar are not well understood by image viewer software.

    My problem was that i misunderstand the way the unpack is done for ipipe from sdram and the way the shifting is done in the case of the yuv case (normally itshould not be done, and that is what i got, the code is by default shft 11-0 (12 bitspixels) but i guess it is for raw bayer).

    1-so my question summarizes in understanding the unpack mode 16 define and register.

    2-another point is the ipipe_data_path_ycbcr_in_ycbcr_out define in the ipipe register. it is not set in the drv_resz.c but it is in drv_ipipe.c which is not used for the resize demo. So what does it mean about its usedfulness ?

    i will in the next step test the flow with the drv_capture.c from the sensor to the memory through the resizer.

    thanks for your help in understanding this product.

     

  • 0 in reply to reda38
    TI__Mastermind 19985 points

    Hi,

    reda38 said:

    1-so my question summarizes in understanding the unpack mode 16 define and register.

    I assume you are talking about UNPACK register bits in CFG1 register of IPIPEIF. This register is valid only if RAW data is given as input to IPIPEIF from SDRAM. The idea is ISIF could have stored the raw data into SDRAM as packed mode (either using A-law or DPCM).

    For YUV422 data, IPIPEIF always expects data in 16 bits per pixel. So this register is not really valid for you. Are you seeing problems with usage of this register? If you notice, we dont set this register bit whenever we are trying to do a DRV_resizeRun() operation.

    reda38 said:

    2-another point is the ipipe_data_path_ycbcr_in_ycbcr_out define in the ipipe register. it is not set in the drv_resz.c but it is in drv_ipipe.c which is not used for the resize demo. So what does it mean about its usedfulness ?

    The ipipe_data_path_ycbcr_in_ycbcr_out is not valid for drv_resz.c. The fact is that resizer module can take input from either IPIPEIF or IPIPE. If the input is coming from IPIPE, we need to tell the IPIPE that it is YCbCr input and YCbCr output. The difference in IPIPE input mode against IPIPEIF input mode for RSZ is that in IPIPE input mode, you can additionaly do edge enhancement.

    In our drv_reszRun() function call we dont use IPIPE input mode. We just use IPIPEIF input mode for the Resizing operation.

    reda38 said:
    except that yuv420_semiplanar are not well understood by image viewer software

     You are right. Many image viewers do not understand the YUV 420 semiplanar format that we use in our system. You might have to convert it to YUV422 to see it on your image viewer.

    Hope this helps.

    Regards,

    Anshuman

    PS: Please mark this post as verified if you think it has answered your question. Thanks.

     

  • 0 in reply to Anshuman Saxena
    Expert 1455 points

    Hi anshuman,

    thank you for your useful answers.

    concerning the unpack mode selection, it is used multiple time in the drv_resz_run function. even when yuv420 is read from sdram.

    but the application works in normal mode with 16bits. i guess this is the 16bits yuv 422 mode you are talking about.

    I am working on a converter for yuv420_sp to ppm seeing none on the market.

    thank you for your help.

     

  • 0 in reply to reda38
    TI__Mastermind 19985 points

    Hi,

    There is a little non-trivial code that we need to put for YUV420SP input mode. In this mode, there are some registers that need to be programmed like the one mentioned below. This is because IPIPEIF has to pass on Y data and UV data separately. I agree it is not documented in detail in the VPFE PRG and we will try to make the changes. Meanwhile, i would suggest you refer to the code in the IPNC Reference Design resizer driver.

        if(inType==DRV_DATA_FORMAT_YUV420) {
          gDRV_reszObj.inConfig.chormaFormatType    = CSL_RSZ_CHROMA_FORMAT_420; 
          gDRV_reszObj.ddrInConfig.rawUnpackMode    = CSL_IPIPEIF_SDRAM_IN_RAW_UNPACK_MODE_PACK_08;
          gDRV_reszObj.inSrcConfig.inputSource2     = CSL_IPIPEIF_INPUT_SOURCE_SDRAM_RAW;
          gDRV_reszObj.inSrcConfig.isifInType       = CSL_IPIPEIF_ISIF_INPUT_TYPE_YUV;
        }   

    reda38 said:
    I am working on a converter for yuv420_sp to ppm seeing none on the market.

    I did not understand the above statement. Do you need something from us?

    Regards,

    Anshuman

    PS: Please mark the post as verified if you think it has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Expert 1455 points

    Hello Anshuman,

    Indeed concerning the :

    if(inType==DRV_DATA_FORMAT_YUV420) {
          gDRV_reszObj.inConfig.chormaFormatType    = CSL_RSZ_CHROMA_FORMAT_420; 
          gDRV_reszObj.ddrInConfig.rawUnpackMode    = CSL_IPIPEIF_SDRAM_IN_RAW_UNPACK_MODE_PACK_08;
          gDRV_reszObj.inSrcConfig.inputSource2     = CSL_IPIPEIF_INPUT_SOURCE_SDRAM_RAW;
          gDRV_reszObj.inSrcConfig.isifInType       = CSL_IPIPEIF_ISIF_INPUT_TYPE_YUV;
        }   

     code, I tried this adapted for YUV422. But the image was not OK. It worked when CSL_IPIPEIF_SDRAM_IN_RAW_UNPACK_MODE_PACK_08 was replaced by the normal mode 16 bits. So my question I asked you.

     

    Concerning the format YUV20_SP wiewer, does code composer do such viewing ?

    Thank you


    I


  • 0 in reply to reda38
    TI__Mastermind 19985 points

    Reda,

    reda38 said:
    code, I tried this adapted for YUV422. But the image was not OK. It worked when CSL_IPIPEIF_SDRAM_IN_RAW_UNPACK_MODE_PACK_08 was replaced by the normal mode 16 bits. So my question I asked you.

     

    The code i mentioned is valid only for YUV420SP input going into Resizer. Please see the inType variable comparison.

    There is no tool readily available to view YUV420SP data. You can make a very simple C program that separates the U and V data into two buffers and then you can make YUV420 planar data that most of the YUV viewers support.

     

    Regards,

    Anshuman

    PS: Please mark this post as verified if you think this has answered your question. Thanks.

  • 0 in reply to Anshuman Saxena
    Expert 1455 points

     

    "The code i mentioned is valid only for YUV420SP input going into Resizer. Please see the inType variable comparison."

    yes i am ok with that. what i told is that when i tried to adapt this code for inType = yuv422 it did not work until i changed the packing to normal mode 16bits.

    Thank your for the indication for yuv420 semiplanar to planar.

    Best regards

    Reda

  • 0 in reply to Anshuman Saxena
    Prodigy 125 points

    Hello Anshuman,

    I have the DMVA1IPNC-MT5 and have connected a TVP5150AM to C0-C1 on the reference design along with I2C and PCLK.  Could you please send me your code for the YUV input mode for the IPNC.  I am having trouble passing any video thru to the streamer and TVout.

    My email has changed: panchy.rivas@gmail.com

     

    Thanks ...