The TI E2E™ design support forums will undergo maintenance from July 11 to July 13. If you need design support during this time, open a new support request with our customer support center.

  • State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 417 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

Original question:

[FAQ] TDA4VM: How to create a LDC mesh LUT for fisheye distortion correction on TDA4?

J784S4XEVM: LDC LUT file format of the tiovxldc GStreamer element

Adam Balazs
Prodigy 10 points
Part Number: J784S4XEVM
Other Parts Discussed in Thread: TEST2

Tool/software:

Hi,

We would like to use tiovxldc GStreamer element to undistort our images.

In https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1058565/faq-tda4vm-how-to-create-a-ldc-mesh-lut-for-fisheye-distortion-correction-on-tda4 the LUT calculation is described well.

For the incoming 1280x944 image with m=4, (16x downscaling) the LUT file should contain a grid with the following resolution:

The mesh width is 1280 / 16 + 1 = 81;

The mesh height is 944 / 16 + 1 = 60;

The padded LUT pitch size = 81 * 2 * 2 = 324 rounded up to be 16 aligned = 336 bytes

So the full padded LUT mesh size is 336 * 60 = 20160 bytes.

We create a binary file that contains 10080 S16Q3 elements and try to specify that file as a LUT file for tiovxldc:

gst-launch-1.0 videotestsrc ! video/x-raw,width=1280,height=944 ! tiovxldc ldc-ds-factor=4 ldc-table-width=1280 ldc-table-height=944 lut-file=./binarylut.lut ! v4l2h265enc ! filesink location=test2.mp4

After launching a pipeline we get the following error:

[ERROR] 1503: readImage: Plane [0] bytes read = 20160, expected = 23040

I checked the original post and found the following image:

Here the SL2 size is the exact size our GStreamer pipeline expects.

If we check the "test_mesh_ldc_dcc.xml" mentioned in the original post our size calculation is correct, but somehow the tiovxldc GStreamer element expects an LDC LUT file with more content than the actual mesh_table_size:

We can't use a fixed, pre-generated DCC file as we need to change and re-calculate the distortion on the fly. Could you please help us how to generate a proper LDC LUT file that we can use with the tiovxldc GStreamer element?

  • 0
    TI__Guru 56290 points

    Hi Adam,

    Adam Balazs said:

    So the full padded LUT mesh size is 336 * 60 = 20160 bytes.

    This is correct from LDC H/W point of view.
    336 bytes is the minimum LDC LUT row width.
    Larger row width such 336+16, 336+32, or 386 would work as well.

    Adam Balazs said:
    [ERROR] 1503: readImage: Plane [0] bytes read = 20160, expected = 23040

    This seems suggesting that gstreamer pipeline expects "384 * 60=23040" bytes as total LDC LUT size.
    I am familiar with gstreamer implementation and why it requires 384 bytes per row.
    It is likely that there is some issue in s/w for row alignment.

    You may try padding your original LUT to 384 bytes rather than 336 and test again.
    I would expect that to work for you.

  • 0
    TI__Guru 56290 points
    Adam Balazs said:

    Here the SL2 size is the exact size our GStreamer pipeline expects.

    This is just a coincidence.

  • 0 in reply to Gang Hua
    Prodigy 10 points

    Hi ,

    Thanks for the quick reply. Yes, I was thinking the same, but all we pass to the GStreamer element are:
    tiovxldc ldc-ds-factor=4 ldc-table-width=1280 ldc-table-height=944 lut-file=./binarylut.lut

    So if we decide to apply a larger padding, how would the tiovxldc GStreamer element know what is the actual padding we use in the binarylut.lut file? It needs to be based on the width and the ldc-ds-factor, otherwise tiovxldc couldn't calculate it.

    But the interesting thing is that even during the DCC configuration the pitch of the LUT matches with the pitch we use, why would the GStreamer element expect a different pitch, and if it does, how can we calculate it? Because right now the only way to observe the problem was trying the setup. I've checked the source code of the GStreamer element and it simply pass the LUT file to the underlying low level LDC API.

    So if the GStreamer element expects a different pitch in the LUT file, we would need the exact way to calculate it, because right now the only way would be based on the runtime error message we get.

    Thank you,
    Adam

  • +1 in reply to Adam Balazs
    TI__Guru 56290 points
    Adam Balazs said:

    tiovxldc ldc-ds-factor=4 ldc-table-width=1280 ldc-table-height=944 lut-file=./binarylut.lut

    gstreamer would have to decide the padding using these input and with some assumption.
    It might have assumed 16x for the number of LUT elements on each row rather than 16x bytes, which would lead to 384 bytes rather than 336.

    Adam Balazs said:
    But the interesting thing is that even during the DCC configuration the pitch of the LUT matches with the pitch we use,

    The natural assumption would be the minimum number of bytes, which is how tuning tool and LDC FAQ calculate the the row width.

    Please let me know if 384 works for you.

  • 0 in reply to Gang Hua
    Prodigy 10 points

    It is the right way to calculate the pitch indeed.

    So the mesh width is 1280 / 16 + 1 = 81;

    The mesh height is 944 / 16 + 1 = 60;

    The mesh width should be aligned to 16, so it is 96.

    The padded LUT pitch size = 96 * 2 * 2 = 384.

    So the full padded LUT mesh size is 384 * 60 = 23040 bytes.

    We have tested it with other resolutions as well and it worked in all cases.

    Thank you very much

  • 0 in reply to Adam Balazs
    TI__Guru 56290 points

    Hi Adam,

    Thanks for the confirmation!

    That is what I was suspecting.
    It should be due to a misunderstanding of the requirement of row alignment.
    I will check if anyone can fix that issue in gstreamer.

    I will close this thread and please feel free to open a new one if you have any further questions.