码迷,mamicode.com
首页 > 其他好文 > 详细

NDK学习笔记(五)Reader机制

时间:2015-12-18 16:42:46      阅读:382      评论:0      收藏:0      [点我收藏+]

标签:

     针对每一种后缀名Nuke都提供了对应的模块。为了决定用哪个版本的reader或writer模块,Nuke会先解析文件后缀名再以此为依据调用相关模块。

 

以JPG为例:

该文件格式有两种后缀名:.jpg和.jpeg。实际上两种后缀名用同一个模块来解决即可。Nuke中用tcl脚本来解决这个问题。Nuke文件路径中有这样一个文件:jpegReader.tcl,内容如下:

#jpegReader.tcl
load jpgReader

 当Nuke主程序解析后缀名为.jpeg的时候就会调用jpegReader.tcl脚本。该脚本会将调用指向jpgReader模块。通过这种方式就解决了一种图像格式有多种后缀名的问题。

Nuke中提供了对应大部分图像格式的reader和writer模块,例如:dpxWriter,dpxReader,exifReader,exifWriter。

分别针对对应的图像格式。

 

 

NDK文档中提供了标准的一个Reader基础模板如下:

class MyReader : DD::Image::Reader
{
  static const Description d;
  ...
};

static Reader* build( Read* r, int fd, const unsigned char* b, int n )
{
    return new MyReader( r, fd, b, n );
}

static bool test( int fd, const unsigned char* block, int n )
{
  return ( block[0] == MY_MAGIC_BYTE );
}

const Reader::Description MyReader::d( "myFile\0", "my file format", build, test );

 首先定义了一个继承Reader的子类:MyReader,继而定义其中的build及test、Description函数。

Description函数将通过build及test函数来控制和估计是否MyReader类适用于操作当前的图像格式。

一般来说,Reader实例通过后缀名来寻找对应的读取器,一旦找到了特定的图像格式,就是启动test函数去确定读取器与当前格式是否匹配。

在这种情况下,MY_MAGIC_BYTE会被当做内存中第一个元素来识别。为了防止错误的后缀名图像格式(比如dpx格式的文件后缀名却是.jpg),Nuke还会再次测试tester方法,来告诉用户,testing可以决定文件类型是可读的,同时避免了相同的文件后缀冲突。

 

和使用tcl语言的的方法一样,多种文件后缀也可以在description中被定义。案例如下:

const Reader::Description MyReader::d( "myFile\0someOtherFile", "my file format", build, test );

 这样的话Reader就可以适用于.myFile格式和.someOtherFile格式了。

 

这个Reader结构可以通过DD::Image::Reader::set_info()l来设置IO访问的区域。这会是一个快速的处理过程。复杂的读取,解码,缓存可以通过DD::Image::Reader::open()来解决。

最后一个需要用户自己定义来创造基本的读取机制的方法是DD::Image::Reader::engine()。下面这个案例会显示Nuke自己的图像处理过程:

void MyReader::engine( int y, int x, int r, ChannelMask mask, Row& row )
{
  row.range( 0, width() );

  for( int z = 0; z < 4; z++ ) {
    // A user implemented read function
    custom_read_channel( y, z, row.writable( z ) );
  }
}

 这个实例会在开始时设置画面的宽度,然后读取每一个通道的数据到row中。

row就是一个数据缓冲机制。

 

 

还有一些其他的方法:

 

以下的方法都是可选的,不必每一个都定义。他们提供了一些额外的功能和信息给Reader类。

void DD::Image::Reader::prefetchMetaData()

 这个方法可以用来获取特定帧的metadata(元数据)。

const MetaData::Bundle& DD::Image::Reader::fetchMetaData(const char* key)

 这个方法可以用来获取metadata(元数据)。

bool DD::Image::Reader::supports_stereo() const

 这是一个flag,决定当前类是否支持立体双视角的读取。

bool DD::Image::Reader::fileStereo() const

 这是一个flag,表明当前文件是否为立体素材。

bool DD::Image::Reader::videosequence() const

 这是一个flag,表示当前文件是否是视频素材,即mov。

 

 

 

 

关于FileReader基类:

FileReader是一个继承自Reader的类,但它总表现的像是一个基类。它需要实例化的函数方法同Reader一样。然后FileReader这个类之所有有趣,主要还在于它有一些新加的超越Reader的特性。

当用户直接继承Reader类来创建自己的reader类的时候你必须也实例化文件操作函数。FileReader会提供方法直接进入或者操作文件数据,基于此,对于大部分实例,FileReader是一种非常合适的解决方案。

要使用更多的特性,只需要向下面一样自定义一个类继承DD::Image::FileReader即可。

class MyReader : public DD::Image::FileReader
{
  ...
};

 

 

 FileReader的扩展特性有以下这些:

int DD::Image::FileReader::lock(FILE_OFFSET offset, int min_length, int length)
int DD::Image::FileReader::lock(FILE_OFFSET offset, int l)
int DD::Image::FileReader::lock(FILE_OFFSET offset, unsigned int l)

以上三个方法用于锁定给定参数上的数据。

const unsigned char& DD::Image::FileReader::byte( FILE_OFFSET n ) const
const unsigned char* DD::Image::FileReader::at( FILE_OFFSET n ) const

以上两个方法用于进入给定offset上的字节。

void DD::Image::FileReader::unlock()

解锁之前锁住的内存。

int DD::Image::FileReader::read(void* p, FILE_OFFSET offset, int min_, int max_)
int DD::Image::FileReader::read(void* p, FILE_OFFSET offset, int l)
int DD::Image::FileReader::read(void* p, File_OFFSET offset, unsigned int l)

直接读取存入内存的文件。

 

 

 

Reader的KNOBS机制:

在reader类中添加knobs需要额外的步骤,因为Reader类并不同于Ops。有特定的对象可以跟Reader一起被初始化和注册来赋予Reader类似常规Op创建Knobs的能力。有两个主要步骤如下:

1.继承一个DD::Image::ReaderFormat类。用这个ReaderFormat类就可以将knobs()及knob_changed()接口实例化了。

2.用你自己的reader类创建一个新的正确类型的对象,确保正确的reader format被初始化了。

代码如下:

class MyFileFormat : public DD::Image::ReaderFormat
{
  // implementation of the knobs call
  void knobs(Knob_Callback c)
}

class MyReader : public DD::Image::FileReader
{
  static const Description d;
}

static Reader* build( Read* r, int fd, const unsigned char* b, int n )
{
  return new MyReader( r, fd, b, n );
}

static bool test( int fd, const unsigned char* block, int n )
{
  return ( block[0] == MY_MAGIC_BYTE );
}

static ReaderFormat* buildformat(Read* iop)
{
  return new MyFileFormat();
}

const Reader::Description MyReader::d( "myFile\0", "my file format", build, test, buildFormat );

第一个MyFileFormat类是一个包装器,用来包含knobs类。第二个类即为MyReader,继承自FileReader,在类中定义了description。第三个代码块是对build函数的定义,第四个代码块是对test函数的定义,第五个是对buildformat函数的定义。最后定义Description函数,该函数是对MyReader类的一个说明,参数与Reader基类比较多了一个buildFormat。这也是FileReader基类的一个特点,有扩展属性,可以很方便的添加新的属性功能。

案例中就通过buildFormat函数新添加了knobs对象。

 

 

 

Reading MetaData:

Metadata可以再解码的时候使用相同的模式去读取。DD::Image::fetchMetaData( const char* key )实例化之后可以返回DD::Image::MetaData::Bundle的对象。代码如下:

class MyReader : public DD::Image::FileReader
{
  ...
  DD::Image::MetaData::Bundle& fetchMetaData( const char* key )
  {
    return _metaData;
  }

  DD::Image::MetaData::Bundle _metaData;
}

在这个案例中,_metaData信息可以在requested的时候获得。reader对象构建的时候这个metadata已经提前建好了。可以直接调用。

 

 

 

Testing with Tester:

正如之前提到的,当读取一个文件的时候,基于对应于文件格式的已注册的可用扩展名,Nuke会判断用哪一个reader来读取。这下面的代码是一个简单的测试模块来检查第一个字节来确保匹配MY_MAGIC_BYTE宏。这当然是一个简单的例子简单表示一下怎样设置该函数,真实的实例会检查更多更复杂的模式来确保匹配。(这个函数似乎是对指令地址逐一测试用的)test代码块如下:

#define MY_MAGIC_BYTE 0x000000001
static bool test( int fd, const unsigned char* block, int n )
{
  return ( block[0] == MY_MAGIC_BYTE );
}

第二个用来防止出现错误文件后缀的机制如下:

typedef bool (*Tester)(int fd, const unsigned char* buf, int bufsize);
DD::Image::Reader::(Tester* )( int fd,const unsigned char* block,int n )

Tester函数返回值是指针,执行结果是bool值,当指针非零时,表示一个Unix文件被用来存储图像了。这种情况下,Reader类就会打开这个Unix文件调用该函数。如果函数执行结果是True,那么对应reader就会被调用。当然该机制也允许所有的reader类对一个未知文件类型进行投票来确定谁来读取这个文件。

如果返回值是Null,那么图像就会以空值的形式传递给reader机制。

 

 

 

 

Working Metadata:

metadata在nuke中是通过DD::Image::Metadata::Bundle对象来解决的。这个抽象的对象提供了了所有需要读写的功能。

在使用metadata的过程中有两件事需要注意,metadata可以被分成两种机制:

1:nuke识别的默认的metadata机制。比如时码(DD::Image::MetaData::TIMECODE)这个关键字是用来存储特定值的。所以nuke读写时码的时候,使用这个关键字的。

2:自定义的metadata机制。如果你想用其他名称来代替timecode这个关键字,Nuke内部也会认可这种key-value值对的方式。

NDK学习笔记(五)Reader机制

标签:

原文地址:http://www.cnblogs.com/hksac/p/5057325.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!