DM642 图像存储格式
来源:百度文库 编辑:神马文学网 时间:2024/04/27 20:07:28
(一):我们实验室的板卡用到的解码芯片是TVP5150,大家都知道这款芯片本身不支持缩放,通过配置其寄存器,得到一个8-BIT的BT.656格式的数字视频流—其Y:Cb:Cr为4:2:2.(这个视频流的分辨率应该是D1格式的吧?大家给说说)。
(二):这个内嵌同步信号的8-BIT的数字视频流进入DM642的Video-Port,在Video-Port中自带了Filter(滤波器)(硬件实现),它可以通过配置Video-Port的寄存器来实现对流入数据的重采样,(比如,可以将流入的Y:Cb:Cr-4:2:2数据重采样成4:2:0,也可以将水平像素数缩放为原始数据的二分之一。),这些参数的具体设置在结构VPORTCAP_Params中会有(文档The TMS320DM642 Video Port Mini-Driver对该结构也有很详细的说明),我们只需对某些元素值进行修改即可。在这里,我用到了滤波器的水平二分之一缩放功能(horizontal ½-scaling)。
(三):大家都知道,要从D1格式实现CIF格式,水平和垂直方向都应该有一个二分之一的缩放。最要紧的是如何实现竖直方向的二分之一缩放了(Vertical ½-scaling)。这也是困扰我的主要原因,因为TI的文档说到,Vertical scaling must be performed in software.我就是被这句话害得很苦啊。其实我们都知道,TVP5150是按奇偶场的方式扫描一帧图像的。竖直方向的二分之一缩放不外乎就是只取其中一场数据即可。在DATA_copy中,数据的搬移是这样的(只以亮度分量说明,Cb,Cr分量是一个道理):
for(i = 0; i < numLines; i ++)
{
DAT_copy(capFrameBuf->frame.iFrm.y1 + i * capLinePitch,
disFrameBuf->frame.iFrm.y1 + i * disLinePitch,
numPixels);
}
其中,numLines=287,capLinePitch=352,disLinePitch=720,numPixels=352;这说明在本程序中,capFrameBuf中y分量的确是按奇偶场方式分开排列的。在Y中的前287行数据的确是两场数据中的一场。然而在我跑另外一个D1格式的采集与显示的例程时,我只让DATA_copy搬移capFrameBuf中y分量的前一半数据,发现图像是正常显示的,尽管只显示了图像的一半(即只显示了720*576图像的上半部分,但如果capFrameBuf中y分量的前一半数据存放的是一场数据的话,显示的图像应该是一个压扁状的图像阿)。
(四):问题还是出在了结构VPORTCAP_Params的设置上。这个结构中有一个元素Int mergeFlds,对这一位 置1的话,表示Video-Port在将数据放入BUF之前会将两场数据糅合到一起再放入BUF中,而如果置0的话,两场数据是隔离的,即在BUF中存放顺序是先放完一场数据再紧跟着将另外一场数据存入。这也是为什么D1格式的采集与显示的例程会出现我说的上述情形,是因为在这个例程中,将mergeFlds设置为了1 。而在CIF格式的历程中,将mergeFlds设置为了0。
(五):将mergeFlds设置为了0以后,只需DATA_copy capFrameBuf中y分量的前一半数据,即实现了搬移两场数据中的一场数据,即实现了竖直方向的二分之一缩放。于是一幅完整的CIF格式的图像数据就得到了,接着拿给应用程序处理也行,直接显示也行了。本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/henhen2002/archive/2009/08/16/4453776.aspx
(二):这个内嵌同步信号的8-BIT的数字视频流进入DM642的Video-Port,在Video-Port中自带了Filter(滤波器)(硬件实现),它可以通过配置Video-Port的寄存器来实现对流入数据的重采样,(比如,可以将流入的Y:Cb:Cr-4:2:2数据重采样成4:2:0,也可以将水平像素数缩放为原始数据的二分之一。),这些参数的具体设置在结构VPORTCAP_Params中会有(文档The TMS320DM642 Video Port Mini-Driver对该结构也有很详细的说明),我们只需对某些元素值进行修改即可。在这里,我用到了滤波器的水平二分之一缩放功能(horizontal ½-scaling)。
(三):大家都知道,要从D1格式实现CIF格式,水平和垂直方向都应该有一个二分之一的缩放。最要紧的是如何实现竖直方向的二分之一缩放了(Vertical ½-scaling)。这也是困扰我的主要原因,因为TI的文档说到,Vertical scaling must be performed in software.我就是被这句话害得很苦啊。其实我们都知道,TVP5150是按奇偶场的方式扫描一帧图像的。竖直方向的二分之一缩放不外乎就是只取其中一场数据即可。在DATA_copy中,数据的搬移是这样的(只以亮度分量说明,Cb,Cr分量是一个道理):
for(i = 0; i < numLines; i ++)
{
DAT_copy(capFrameBuf->frame.iFrm.y1 + i * capLinePitch,
disFrameBuf->frame.iFrm.y1 + i * disLinePitch,
numPixels);
}
其中,numLines=287,capLinePitch=352,disLinePitch=720,numPixels=352;这说明在本程序中,capFrameBuf中y分量的确是按奇偶场方式分开排列的。在Y中的前287行数据的确是两场数据中的一场。然而在我跑另外一个D1格式的采集与显示的例程时,我只让DATA_copy搬移capFrameBuf中y分量的前一半数据,发现图像是正常显示的,尽管只显示了图像的一半(即只显示了720*576图像的上半部分,但如果capFrameBuf中y分量的前一半数据存放的是一场数据的话,显示的图像应该是一个压扁状的图像阿)。
(四):问题还是出在了结构VPORTCAP_Params的设置上。这个结构中有一个元素Int mergeFlds,对这一位 置1的话,表示Video-Port在将数据放入BUF之前会将两场数据糅合到一起再放入BUF中,而如果置0的话,两场数据是隔离的,即在BUF中存放顺序是先放完一场数据再紧跟着将另外一场数据存入。这也是为什么D1格式的采集与显示的例程会出现我说的上述情形,是因为在这个例程中,将mergeFlds设置为了1 。而在CIF格式的历程中,将mergeFlds设置为了0。
(五):将mergeFlds设置为了0以后,只需DATA_copy capFrameBuf中y分量的前一半数据,即实现了搬移两场数据中的一场数据,即实现了竖直方向的二分之一缩放。于是一幅完整的CIF格式的图像数据就得到了,接着拿给应用程序处理也行,直接显示也行了。本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/henhen2002/archive/2009/08/16/4453776.aspx
DM642 图像存储格式
基于DM642的图像处理硬件系统设计
点阵格式图像
视频与图像RGB/YUV格式详解
02_点阵格式图像 PHOTOSHOP在线教程
一张存储卡可以记录多少张图像?
NO.4 如何改变图片的色彩模式、存储格式
使用数码单反怎样选择存储的图像文件格式
为什么RAW格式可以使图像处理游刃有余?
图像锐化深度探索之JPEG格式的数字图像
人像摄影必备器材及技术-图像记录格式
为什么RAW格式可以使图像处理游刃有余?-蜂鸟网
为什么RAW格式可以使图像处理游刃有余?
使用RAW格式进行图像处理的优势
将Excel中存储为文本的日期转换为日期格式-
:图像尺寸和格式(纠结了很久终于明白了)
大家做DM642时供电是什么方案?
基于DM642的机器人双目视觉系统设计
单机存储
存储过程
存储管理
思想汇报格式 思想汇报格式
图像调整
图像处理