• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 98 subscribers
  • Views 413 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.

using resizer with preview engine output

MattLipsey
Genius 3575 points

My goal is to take an image in DDR2 in bayer format, run it through the previewer & resizer to produce a 1/2 resolution YUV 4:2:2 interleaved image that I can run through the jpeg baseline encoder provided by TI.  I have been able to do this in pieces, by running the previewer to output the full res image to ddr2, then running a second pass to resize, then calling the jpeg encoder on the result.  Right now, I have each previewer step shaving 32 pixels from each line, and would like to minimize this.

From what I understand, the input to the previewer engine from ddr2 has to have a line width that is a multiple of 32 bytes.  (spru977 6.2.6, RADR_OFFSET)

The resizer output also has to be a line width that is a multiple of 32 bytes. (spru977, 6.3.10 SDR_OUTOFF)

The jpeg encoder has to have a line width multiple of 16 bytes (sprueh4, section 4.2.1.3)

It would seem that since the previewer eats a few pixels from each line, my best result would be if the resizer could output a line that is 16 bytes smaller than the original input image, but that had an extra 16 bytes of "junk" on each line to maintain the 32 byte spacing requirement.  I could then program the jpeg encoder parameters to encode the (line - 16) size with an original image of (line - 0) size.  Is this possible, or is using any portion of the preview image always going to shave 32 bytes from the original image?

Also, in studying the documentation, I was very confused by the resizer IN_START register HORZ_ST value  (quoting from spru977 section 6.3.5):

Horizontal starting pixel. This field makes sense when the resizer obtains its input from the preview
engine. When the resizer gets its input from SDRAM, this field must be set to ≤15 for YUV 16-bit
data and ≤31 for 8-bit color separate data.
Horizontal starting pixel value is in number of pixels, if input is from SDRAM.
If the input to the resizer is from CCD controller/preview engine, this field needs to be programmed
as follows:
1. Program this field using number of bytes (twice number of pixels).
2. Change the lowest bit to reflect start position in pixels (effectively change from a value 0 to a
value 1, if required).

 

What on earth does this mean?

Thanks,

Matt

 

  • 0
    TI__Intellectual 995 points

    From what I understand, the input to the previewer engine from ddr2 has to have a line width that is a multiple of 32 bytes.  (spru977 6.2.6, RADR_OFFSET)

    Xiangdong>> This only means that each horizontal line of the video frame must start at an DDR address of multiple of 32. The size of the line, on the other hand, does not need to be multiple of 32. For example, for a line size of 360, RADR_OFFSET must be 384, which is multiple of 32. This means the last 24 bytes of each line is garbage.

    The resizer output also has to be a line width that is a multiple of 32 bytes. (spru977, 6.3.10 SDR_OUTOFF)

    Xiangdong>> Same as above

     

    It would seem that since the previewer eats a few pixels from each line, my best result would be if the resizer could output a line that is 16 bytes smaller than the original input image, but that had an extra 16 bytes of "junk" on each line to maintain the 32 byte spacing requirement.  I could then program the jpeg encoder parameters to encode the (line - 16) size with an original image of (line - 0) size.  Is this possible, or is using any portion of the preview image always going to shave 32 bytes from the original image?

    >>Xiangdong: Yes, this is definitely possible. The # of pixels cropped by the Preview engine depends on the functions used in it. Please refer to details in the PRG.

    Horizontal starting pixel. This field makes sense when the resizer obtains its input from the preview
    engine. When the resizer gets its input from SDRAM, this field must be set to ≤15 for YUV 16-bit
    data and ≤31 for 8-bit color separate data.
    Horizontal starting pixel value is in number of pixels, if input is from SDRAM.
    If the input to the resizer is from CCD controller/preview engine, this field needs to be programmed
    as follows:
    1. Program this field using number of bytes (twice number of pixels).
    2. Change the lowest bit to reflect start position in pixels (effectively change from a value 0 to a
    value 1, if required).

    >>Which part of the do you have problem understanding?

    For the horizontal starting pixel. Let me rephrase the statement below:

    If input is from SDRAM, the value shall be <15 for YUV 422 data or  <31 for 8-bit gray scale data. The value is in number of pixels.

    If input is from CCDC, the value is in term of pixel clocks. Since each pixel of YUV 422 data requires 2 clocks(Y and Cb/Cr), this means each additional pixel of offset requires 2 clock(or byte) adjustment.

    Resizer always requires the first pixel of each line to be the Y pixel. If, however, the first pixel of the input data is a chroma data, then the offset needs to be adjusted from 0 to 1.

    Hope this makes sense to you.

    Regards,

    Xiangdong

     

     


  • 0 in reply to Xiangdong Fu
    Genius 3575 points

    As a follow up to make sure I understand the hardware operation, let me make up a test case.

    My original bayer pattern image is 1024 wide by 720 tall.  I feed this to the previewer, where the only stage enabled is CFA interpolation.  According to table 24 in spru977, this means the previewer crops 4 pixels/line and 4 lines, meaning that it will output 1020 pixels wide by 716 pixels tall to the resizer (each pixel now being 2 bytes).  Am I correct in assuming that the horizontal crop is from each side, so if my original line array was [0:1023] the output array now corresponds to [2:1021] ?

    I now want the resizer to do a %50 downres in each direction and get the maximum horizontal resolution out that is possible.  50% downres means I need to use the 8 phase, 4 tap filter mode.  From section 4.1 of spraai7, this means I am going to lose 4 pixels in both the horizontal & vertical directions (even though I need to program the input size register as 7 for the horizontal due to the hardware implementation).  So I would use 1020 - 4 = 1016 for my input width, and thus get 508 pixels wide for my output width (and 356 pixels vertical size).  Since the previewer line offset has to be 32 byte aligned, I would round this up to 512, resulting in 4 trash pixels at the end of each line.  Now I am a little confused as to which edge these pixels are culled and how the output image lines up with the input.  First, in my case is there a reason to set horizontal start pixel or phase anything other than 0?  Second, how can I calculate where the output pixel 0 lines up horizontally with the input pixels?  Third, the same questions for the vertical alignment between input & output.  I ask these questions because I have a reference location in the original image that I need to keep track of through the previewer operations.

     

  • 0 in reply to MattLipsey
    TI__Intellectual 995 points

    >>My original bayer pattern image is 1024 wide by 720 tall.  I feed this to the previewer, where the only stage enabled is CFA interpolation.  According to table 24 in spru977, this >>means the previewer crops 4 pixels/line and 4 lines, meaning that it will output 1020 pixels wide by 716 pixels tall to the resizer (each pixel now being 2 bytes).  Am I correct in >>assuming that the horizontal crop is from each side, so if my original line array was [0:1023] the output array now corresponds to [2:1021] ?

    Yes.

    >>First, in my case is there a reason to set horizontal start pixel or phase anything other than 0?

    No.

    >>Second, how can I calculate where the output pixel 0 lines up horizontally with the input pixels? Third, the same questions for the vertical alignment between input & output.

    It is 2 pixels at the left and two pixels at the right horizontally and 2 at top and 2 at bottom vertically.

  • 0 in reply to Xiangdong Fu
    Genius 3575 points

    It's becoming more clear.  As a final check, is this how the images line up, exactly pixel on pixel, or is there a fractional pixel in between?

    0 1 2 3 4 5 6 7 8 ... (input to resizer)

    x x 0 x 1 x 2 ... (output from resizer)

  • 0 in reply to MattLipsey
    TI__Intellectual 995 points

    In general, Yes. However, The exact location is really depends on the filter you use, or more precisely, the center of the filter.

    Regards,

    Xiangdong