DM355 IPIPE 2048x1536 picture Issue!

I answered a similar post some time ago: http://community.ti.com/forums/p/1621/5874.aspx#5874

If you have a image file that is 2048x1536 pixels in YCbCr 422 and all you want to do is JPEG encoded, than this 1344 pixel limitation does not apply; if the image is in RAW format and you need to converted to YCbCr 422 before encoding it, the the 2344 limitation applies and you will need to break up the image, process it, and piece it back together; using DMA as suggested in my post above should help.

  hi,juan Gonzales! 

  Thank you for your reply,my  english is poor!Do you mean is: from the CMOS sensor to capture the 2048x1536 raw data format image convert ycbcr422 format image, then IPIPE in the H / V resizer MODEL deal ycbcr422 format image, H / V resizer Module Writing  SDRAM buffer less than 1344 pixels in each horizontal line.

1. I would like to use RAW Bypass Mode to capture 2048x1536 raw format image, because in RAW

 pass through mode, images up to 4096 pixels per line may be processed. In RAW pass through mode, the

 input data is directly written out to SDRAM. This method is correct? There are other better solution?

2,Whether there is any raw format convert into ycbcr422 the tools?

 3.in frmae division mode-v ,the input image is horizontally split into multiple images,

  in frame division mode-h,the input image is split into several boxes,

  Please recommend the best use of the method,

 best regards,

winky!

winkyxiao said:

1. In RAW pass through mode, the input data is directly written out to SDRAM. This method is correct? There are other better solution?

2. Whether there is any raw format convert into ycbcr422 the tools?

 3. in frmae division mode-v ,the input image is horizontally split into multiple images, in frame division mode-h,the input image is split into several boxes,  Please recommend the best use of the method, 

Not sure if I understood everything, but I will try to answer...

1. In RAW capture mode, data can be written directly to DDR2

2. I am sure there are software conversion tool out there, but this approach will take precious CPU time; preview hardware block can do the conversion in hardware and since you are already paying for the preview engine hardware in the silicon, I would recommend you use this approach and save yourself some CPU bandwidth for other tasks.

3.  The limitation is only in the line length, therefore to minimize work and CPU usage, I would just split the image vertically (set line length, number of lines does not matter).

I see what you mean,I have the following issue:

1.You say that preview hardware block can do the conversion in hardware ,This sentence has an error !The previewer driver does not support DM355 EVM.the IPIPE driver should be used.

2.You say that I need split the image vertically .are used in the Frame Division Mode-V model?

3.If I use Frame Division Mode-V model,The input image is split into the left side block with width of h1 and the right side block with width of h2.Each image is resized to the ratio of 256/d to make images with width of H0 and H2 = H - H0 respectably.

for example :The input image width is 2048,height is 1536,how split the most appropriate image!

the left side block and  the right side block How to deal with in DDRAM memory! Whether there is any overlap?

1. you are correct; I was mistakenly thinking dm6446, in DM355 it is the ipipe hardware that does the conversion,

2.  yes

3. you will need to break down your 2048x1536 image intoat least two images (two is recommended); for example, you can have a 1024x1536 image, where h1 = 1024 or pixels 0 thru 1023 of original line and h2 =1024 consisting of pixels 1024 thru 2047 of original line.  This means that you will likely need two intermediate buffers where you can copy these two new images using DMA to move DDR2 data from original 2048x1536 image to both 1024x1536 images; then you will do the conversion to YCbCr and use DMA again to piece the final image back together.

hi, Juan Gonzales!

First of all, I am very grateful for your reply! I still have some details are not very clear!

1.According to the chart above formula,if h1=1024,then d is equal 2?

  One of the X0 formula in the document did not explain!What does it mean X0?

  Formula on behalf of the H1 and h1 What does it mean？ I am very confused!

2.you say that need two intermediate buffers where you can copy  these two new images using DMA to move DDR2 data from original 2048x1536 image to both 1024x1536 images;

because 2048x1536 image break down two images; two images stored in two intermediate buffers , Image size for each intermediate buffers 1024x1536x2byte.

but IPIPE can work with up to 1344 pixels in each horizontal line.

Therefore stored in raw data format of intermediate buffer is converted to   ycbcr422 format by IPIPE hardware module.  Converted Ycbcr422 data  image will be stored in Ring BUffer(RSZ line MEM)！

I have the following questions:

ycbcr422 data already inside DDR2. why still need to use DMA to transmit data to the DDR2?

3.LSP 1.20 DaVinci Linux IPIPE Driver
User's Guide ,

 Slicing of an Image

This use case is for slicing the image of horizontal size “x”. Suppose x has to be sliced to sizes “a”, ”b”,
and “c”. So x = a + b + c

You recommend methods and principles of this method are the same?

be use DMA to piece the final image back together?

how use DMA to piece the final image ?I am confused！

any suggest and help would be appreciate!

 best regards,

winky!

Who can help me reply the above question?my english is poor , any suggest and help would be appreciate !

Apologies for the delay, I just got back from vacation.

First, lets discuss the concept you have one large 2048x1536 image, but you are limited to a horizontal line size of 1344.  This means that your line size can be up to 1344 pixels long, but can be smaller.  For the image size you have, it is convenient to split the 2048 line length into two equal pieces of 1024 each (notice both are smaller than 1344 maximum).  Also, it does not appear you need to resize at all but rather just conver from RAW to YCbCr format, correct?  If so, let us proceed to your questions

1) the parameter d can take on values from 32 to 4096, but since 256/d determines the resize ratio and it does not appear we need to resize at all (simply conver to YCbCr format), for our purposes d will be 256 (256/d = 256/256 = 1 resize ratio).  In the diagram offered in our user guide lower case x0, x1, h0, h1 are used to denote input parameters and capital-case X0, X1, H, H1, H2 output size parameters per Figure 73.   Where as h1,h2, H, H1, and H2 are fixed values (e.g. h1 = h2 = H1 = H2 = 1024, H=2048), x0, x1, X0 and X1 are variable values (e.g. x0 and X0 range from 0 to 1023, and x1 and X1 range from 1024 to 2047).  Now that we have this information, lets analyze the equations above

For block 1: RSZ_I_HST = 0, RSZ_0_HST = 0, RZS_O_HSZ = 1023, RZS_H_PHS = 0

For block 2: RSZ_I_HST = 1024, RSZ_0_HST = 1024, RZS_O_HSZ = 1023, RZS_H_PHS = 0 (since resize ratio = 1)

2) My reference to intermideate buffers referred to an alternate approach which does not involve using Division Mode-V, but rather using resizer to convert to independent blocks ( similar to block1 in previous step), and piecing them together in a user app; since this would involve moving memory around from intermediate DDR2 buffers to a final buffer in DDR2, I suggested the use of DMA to do this.  If you follow the aproach outlined above (Division mode-V), this is no longer necessary.  Thr definition of a value for RSZ_0_HST for second block, tells resizer where to dump the data in the final buffer (no intermediate buffers necessary).

3) No, I beleive this is something different.  Try the settings described in step 1 above.

Thank you reply my question ,I thank you very much! I Try the settings described in step 1 above.

 I captures 2048x1536 raw data to the SDRAM,raw data deal with by IPIPE hardware module，

my image Pipe main register settings are as follows：

glob_hor_size=2048 +8, glob_ver_size=1536+10,

hnum=2048,vnum=1536

ipipe_dpaths_fmt=RAW2YUV,

ipipe_dpaths_bypass=RAW_MODE_OFF,

ipipe_vst=0,

ipipe_vsz=1536-1,

ipipe_hst=0,

ipipe_hsz=2048-1,

because

For block 1: RSZ_I_HST = 0, RSZ_0_HST = 0, RZS_O_HSZ = 1023, RZS_H_PHS = 0

For block 2: RSZ_I_HST = 1024, RSZ_0_HST = 1024, RZS_O_HSZ = 1023, RZS_H_PHS = 0 (since resize ratio = 1)

1.

I'm sure ipipe_hsz equal to 2048，If ipipe_hsz equal to 1024，then input raw image size is 1024x1536,Therefore can not be divided into two blocks。

 My questions are as follows：

When ipipe_hsz value equal to 2048 ，Prompted this error:" dm355_ipipe.2:validate:invalid ipipe horizontal size buffers";

if ipipe_dpaths_bypass equal to RAW_MODE_ON，Not above error happened，but the image is not conver from RAW to YCbCr format ！

2.

if block1 and block2 deal with separately by ipipe hardware module,

first of all, deal with raw data image of block1 , raw format Conversion is completed,ycbcr422 store in ring buffer,And then the same approach to deal with block2!

 My questions are as follows：

(1) block1 and block2 is converted into ycbcr422 store in ring buffer or DDR2 ?

(2)whether involve moving memory around from intermediate DDR2 buffers to a final buffer in DDR2？ Need to use DMA to do this？

(3)block1 and block2 piece the final 2048x1536 ycbr422 image by IPIPE hardware module auto complete?piecing them together by IPIPE hardware module?

(4)when deal with block1 and block2，two block is not at the same time deal with ，So there will be a delay time，when IPIPE loopback ，display srcreen have image flicker and image Synchronization problem，How to solve this problem?

3.

you say that using resizer to convert to independent blocks ( similar to block1 in previous step),  This sentence has an error,the resizer driver does not support DM355 EVM,the same previewing and resizing functionalities on DM355,IPIPE driver should be used！

hi,Juan Gonzales!
I still confused about Division mode -V.
Can you help me explain the above problem? Thank you for your reply  on many occasions, I learned a lot of things！

best regards,

winky!

Thank you for your reply, I  have solved  this problem! Thank you very much!

> For block 1: RSZ_I_HST = 0, RSZ_0_HST = 0, RZS_O_HSZ = 1023, RZS_H_PHS = 0

> For block 2: RSZ_I_HST = 1024, RSZ_0_HST = 1024, RZS_O_HSZ = 1023, RZS_H_PHS = 0 (since resize ratio = 1)

looks like a simple typo.  RZS -> RSZ

(see e.g. spruf71a page 221)