[参考译文] TDA4AEN-Q1：如何执行输入图像裁剪和放大器；在不使用 VPAC 中的 LDC 节点的情况下调整大小

您好、

这是一个漫长的周末、因此请希望下周初有响应。

此致、
Sudheer

你(们)好

MSC 可以支持裁剪、并可在裁剪后执行缩小。  

此外、请注意裁剪是一个简单的操作、因此也可以 在存储器中完成、比如您可以将起始指针更改为帧、更改输入大小、并可以实现裁剪...

此致、

Brijesh   

您好、感谢您的回复。

您能否分享一个示例？

此致、

Minseo

尊敬的  Minseo：

SDK 中没有示例。

此致、

Brijesh

您好、Brijesh、

我在 tivxVpacMscPmdSetScParams 函数中完成了裁剪图像。

if(level == 0)
        {
            sc_cfg->inRoi.cropStartX = 0u;
            sc_cfg->inRoi.cropStartY = 256u;
            sc_cfg->inRoi.cropWidth = in_img_desc->imagepatch_addr[0].dim_x;
            sc_cfg->inRoi.cropHeight = 608u;

        }else{
            sc_cfg->inRoi.cropStartX = 0u;
            sc_cfg->inRoi.cropStartY = 0u;
            sc_cfg->inRoi.cropWidth = in_img_desc->imagepatch_addr[0].dim_x;
            sc_cfg->inRoi.cropHeight = in_img_desc->imagepatch_addr[0].dim_y;

            sc_cfg->outWidth = out_img_desc->imagepatch_addr[0].dim_x;
            sc_cfg->outHeight = out_img_desc->imagepatch_addr[0].dim_y;
        }

在上述函数中、首先应用裁剪、然后高斯金字塔过程从1920x1080开始。 但是、我想先裁剪和调整输入图像本身的大小、然后再应用高斯金字塔。 如上所述、我想将 Gaussina 金字塔输入大小调整为960X304。 我应该检查什么来实现这个目标？ 有可能吗？  

此致、

Minseo

尊敬的  Minseo：

Unknown 说：

在上述函数中、首先应用裁剪、然后高斯金字塔过程从1920x1080开始。 但是、在应用高斯金字塔之前、我想先裁剪并调整输入图像本身的大小。

很抱歉、我仍然无法理解。 甚至上面的代码也在应用裁剪。 实际上、在 MSC 中、将首先完成裁剪、然后再进行缩放。 所以不明白 您在这里的问题。  

此致、

Brijesh

您好、Brijesh。

我想以不同的方式提问。

在 pyranmid 节点中、是否可以将 guassian 平滑处理仅应用到特定级别？

例如、  

-----

l0：1920x608

L1：960x304 (仅调整大小而不应用平滑处理)  

L2：480x152 (应用平滑处理)

L3：240x76 (应用平滑处理)

L4：120x38 (应用平滑处理)

-----

此致、
Minsun (Romana)

大家好、 Brijesh Jadav 

我有一个关于这个问题的问题。  

正如我在本问题中提到的、我裁剪了输入图像并调整了大小、生成了一个4级 GPRMD 图像。

我的问题是：MSC 多标度输出的执行时间平均值为 6.5ms 而为 MSC PRMD 执行4级输出需要执行耗时 1.6ms。

如何缩短 MSC 多标度输出的执行时间？

如果您能回答、我将不胜感激。

仅供参考、我还会分享我所做的流算法。

(在 MSC 多标度输出中) : 1920x1080 → 裁剪(1920X608) → 调整大小(960X304)  

→μ s (MSC 金字塔中) ：960x304 | 480X152 | 240X76 | 120X38  

尊敬的  Minseo：

这是预期的。 对吧？ 与金字塔节点相比、多尺度的输入分辨率更大、因此即使金字塔节点运行多次迭代、金字塔节点的总时间也会更短。  

此致、

Brijesh

大家好、 Brijesh Jadav

关于答案、我很好奇、为什么 MSC 多规模流程比金字塔流程需要更长的时间。

即使多刻度中的输入图像尺寸也比金字塔中的图像尺寸更大、多刻度只进行裁剪并调整大小、而无需任何平滑滤波器。

我认为它应该减少双倍时间、但它需要两倍以上(6.5ms > 1.6ms)、因为图像大小是双倍。

另外我想知道、如果我们使用的 LDC 函数也包括裁剪和调整大小函数、比如我 konw、它也需要同样的处理时间？

总之、我们的目的是在 vpac 中使用金字塔节点、但需要超过10ms 的时间才能应用我们的产品、因为我预计如果使用 HWA、需要的时间会更少。

此致、
Minsun

大家好、Minsun、

Unknown 说：

总之、我们的目的是在 vpac 中使用金字塔节点、但应用我们的产品需要花费超过10ms 的时间、因为我预计如果使用 HWA、需要的时间会更少。

但上面的金字塔节点所花费的时间较少,不是吗? 那么、对于哪种分辨率、需要10ms 时间？  

Unknown 说：

另外我想知道、如果我们使用的是 LDC 函数、它还包括裁剪和调整大小函数、就像我所说的那样、它也需要同样的处理时间？

是的、当我们启用裁剪时、即使跳过了这些像素、仍会读取它们。 这就是为什么应在内存中完成裁剪、并且应将直接裁剪的数据发送到 MSC。  

此致、

Brijesh

大家好、 Brijesh Jadav  

关于此答案、 10ms 是整个金字塔节点(包括 Scale + PRMD)的总执行时间。

我会再次询问—那么、您认为从1920×1080→作物和调整大小→960×304的缩放时间需要6.5ms 是合理的吗？ 是否有办法进一步降低数字馈通？

我们提出这一问题是因为我们预计使用硬件加速器会缩短执行时间。  

此致、

Minseo

尊敬的  Minseo：

是的、不应花费太多时间、即使您将其用于 NV12格式、处理此帧所需的时间也应小于5ms。  因此、我们需要了解为什么需要多出大约1.5ms。  

此外、对于 NV12格式、我们可以启用同步处理模式、 这应该会将时间减少33%。 在这种情况下,MSC 将使用两个扇形同时处理亮马和色度。

此致、

Brijesh  

大家好、 Brijesh Jadav  

感谢您的答复！

实际上、我们特别要求 TI 应用使用的其他 TI 补丁 YUV422i 作为输入格式。 因此、在我们的代码中、数据流为1920×1080 [UYVY]→960×304 [UYVY]。

YUV422i 输入格式是否是您提到的额外1.5毫秒处理时间的原因？

此外、我们已经使用 msc_PRMs.isEnableSimulProcessing = 1 ; 实施中使用

此致、

Minseo

尊敬的  Minseo：

不、对于 YUV422格式、不应花费太多时间。  由于 启用了同步处理、在 TDA4AEN 器件上应该需要大约4ms。 是的、似乎需要比预期多2.5ms 的时间。  

您能为我提供具体的测试用例详细信息吗？ 还有其他任何内容并行运行吗？  

此致、

Brijesh

大家好、Brijesh Jadav  
感谢您的答复。 我来作更详细的解释。

第一个信号 MSC 扩展 和 PRMD 空间受限的架构内。 与通常的方法不同、我们在内部按顺序处理这两种情况 单个内核(一个节点) 。 这可能是需要增加额外的原因吗 2.5ms 处理时间？

如果是、如果我们分离节点、您希望速度提高吗？  

我们希望 处理速度稍快一些。  如果需要、我可以共享已实现的代码。

 流动 ： 输入(YUV422 1920×1080)→MSC Scale→(YUV422 960×304)→MSC PRMD→4级 PRMD 图像(Y)

此致、

Minseo