• State TI Thinks Resolved
  • Locked Locked
  • Replies 12 replies
  • Answers 3 answers
  • Subscribers 100 subscribers
  • Views 889 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.

JPEG Encoder in DM365 support 5M resolutin or not?

Leon Yin
Intellectual 255 points

Greetings,

As the jpeg encoder in dm365 noticed, the Images with resolutions up to (Horizontal MCUsize * 1024)*(Vertical MCU size * 1024) pixels can be encoded. This is the theoretical maximum; however, only images up to 10Mpixels have been tested.

But in my programme, I found that if width is bigger than 2048, then the image encoder output are interlacing color bars. Does that means the Horizontal MCUsize here means 2? The coder performance normal under other lower resolution. But the JPEG datasheet said that 10M pixels have been tested.

or the value of dynParams.numAU in the dynParams struct should be set to a proper value?

Best regards;

 

  • 0
    TI__Genius 17215 points

    There is no limitation from Jpeg encoder perspective. What is your dataflow ? If you are using sensor i/p using IPIPE, then there is a restriction for max pixel per line that IPIPE can handle. Indeed this can also be solved by using IPIPE in slice mode.

     

    regards

    Yashwant

  • 0 in reply to Yashwant Dutt
    Intellectual 255 points

    Thanks Yashawant. 

    As you said, we are using the sensor input using IPIPE. The image size is 2592*1944 which horizontal size is greater than 2176. I found that you noticed unsing IPIPE in slice mode. Any more details about using slice mode of IPIPE like some sample codes or relative document? Because there's no details about the slice mode could be found in the VPFE document or PSP & sdk examples. Thanks

     

    Best Regards,

  • 0 in reply to Leon Yin
    TI__Genius 9101 points

    The IPIPE can take input and output upto a max width of 2176 pixels. In order to process more than this limit, in theory, user can to split the input and output vertically into two "stripes" and then invoke IPIPE+Resizer twice, once for each slice. However TI does not have any detailed explanation or example code for this.

  • 0 in reply to Kedar Chitnis
    Prodigy 110 points

    if the raw bayer image data is from DDRRAM, then according to the VPFE datasheet, the maximum width is limited to 2600. Is that correct? 

     

    Best Regards

  • 0 in reply to Louis Ben
    TI__Genius 9101 points

    The limit of 2600 mentioned in the IPIPEIF section is a documentation error. I shall file an errata bug with the doc team.

    The input width limit of IPIPE is also 2176 pixels.

    If input is more that 2176, say 2500, but the output needed is less than 2176, say, 1600, then you can use the "Horizontal Pixel decimator" in IPIPEIF to downsample the input width from 2500 to just less than 2176 and then let the resizer do the rest of the downscaling. "Horizontal Pixel decimator" is a coarse downsampler so it should be used only to make the input width within the IPIPE input width limits and then use the IPIPE resizer to do the rest of downscaling.

    Given below in the VPFE PRG section text for reference,

    In "VPFE/ISP Functional Description > IPIPE > Input Interface" it says

    "The IPIPE engine receives 12-bit RAW image data or 16-bit YCbCr data via IPIPEIF. IPIPE can work with
    up to 2176 pixels in each horizontal line, except in RAW pass-through mode. If the image width is larger
    than 2176, it must be scaled down at IPIPEIF. Otherwise, the input image must be split into several
    blocks."

    regards
    Kedar

     

  • 0 in reply to Kedar Chitnis
    TI__Genius 9101 points

    hi,

    On further checking I find that the VPFE document at www.ti.com (http://focus.ti.com/lit/ug/sprufg8a/sprufg8a.pdf) already has the correct information.

    regards
    Kedar

     

     

  • 0 in reply to Kedar Chitnis
    Prodigy 110 points

    hi, Kedar

    Thank you for your reply!

     

    The VPFE document I've read is also sprufg8a.pdf. In the document (http://focus.ti.com/lit/ug/sprufg8a/sprufg8a.pdf), at the bottom of Page 120, there is :

    "Since the internal line memory is optimized for image resolutions of 5MP, the IPIPE can process a maximum output and input width of 2600 pixels in a single pass."

     

    Does this mean:

    1, When the raw bayer image is read from Parallel Input( a coms/ccd image sensor ), the limit of IPIPE is 2176.

    2, If the VPFE reads raw bayer image for DDR RAM( the situation in Figure 85.), the image width limit of IPIPE ( or IPIPEIF) is changed to 2600? 

     

    Best regards

  • 0 in reply to Louis Ben
    TI__Genius 9101 points

    No, the input width and output width limitation for IPIPE is 2176 in ALL modes (ISIF input, DDR input, YUV input, RAW input).

    This line is a documentation error.

    regards
    Kedar

  • 0 in reply to Kedar Chitnis
    Prodigy 110 points

    hi[, Kedar 

     

    If only the IPIPEIF and ISIF is used, and the IPIPE is bypassed, then the Parallel Input is not limited by 2176, regardless the YUV or Raw bayer input?

     

    best regards.

     

  • 0 in reply to Louis Ben
    TI__Genius 9101 points

    Yes, this 2176 pixels input/output width limitation is for IPIPE

    If only ISIF, IPIPEIF is used the the widthxheight limit is 32K pixels.
    This is regardless of RAW or YUV data.

     

     

    regards
    Kedar

  • 0 in reply to Kedar Chitnis
    Prodigy 110 points

    Hi, Kedar

     

    Thanks a lot!

     

    Does the DM368 also have the IPIPE input/output limitation of 2176 pixels?

     

    Best Regards

  • 0 in reply to Louis Ben
    TI__Genius 9101 points

    Yes, DM368 has the same IPIPE input/output limitation of 2176 pixels

    regards
    Kedar