NDK Learning Note (v) Reader mechanism

The corresponding module is provided for each suffix nuke. In order to decide which version of reader or writer module to use, Nuke will parse the file suffix first and then call the relevant module based on this.

Take JPG as an example:

The file format has two suffix names:. jpg and. jpeg. In fact, the two suffix names are solved by using the same module. Use TCL script to solve this problem in nuke. Nuke file path has such a file: JPEGREADER.TCL, the content is as follows:

#jpegReader. Tclload Jpgreader

The JPEGREADER.TCL script is called when the nuke main program resolves a suffix called. jpeg. The script points the call to the Jpgreader module. In this way, a problem with multiple suffix names for image formats is solved.

Reader and writer modules for most image formats are available in Nuke, for example: Dpxwriter,dpxreader,exifreader,exifwriter.

For the corresponding image format respectively.

The NDK documentation provides a standard reader base template as follows:

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::D escription myreader::d ("Myfile\0", "My file format", build, test);

A subclass that inherits reader is defined first: myreader, which then defines the build and test, description functions.

The description function uses the build and test functions to control and estimate whether the Myreader class is suitable for manipulating the current image format.

In general, the reader instance uses the suffix name to find the corresponding reader, and once a particular image format is found, the test function is started to determine if the reader matches the current format.

In this case, the my_magic_byte is recognized as the first element in memory. To prevent incorrect suffix image format (such as the file suffix in dpx format is. jpg), Nuke will also test the tester method again to tell the user that testing can decide that the file type is readable and avoids the same file suffix conflict.

As with the TCL language approach, multiple file suffixes can also be defined in description. The cases are as follows:

Const Reader::D escription myreader::d ("Myfile\0someotherfile", "My file format", build, test);

In this case, reader can be used in the. myfile format and. someotherfile format.

This Reader structure can be used to set the IO access area through the Dd::image::reader::set_info () L. This can be a quick process. Complex reads, decoding, and caching can be solved by Dd::image::reader::open ().

The last way to create a basic reading mechanism that requires a user's own definition is dd::image::reader::engine (). The following example shows nuke's own image processing process:

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) );  }}

This example sets the width of the screen at the beginning and then reads the data from each channel into the row.

Row is a data buffering mechanism.

There are a few other ways:

The following methods are optional and do not have to be defined for each one. They provide some additional features and information to the reader class.

void Dd::image::reader::p refetchmetadata ()

This method can be used to get metadata (metadata) for a particular frame.

Const metadata::bundle& Dd::image::reader::fetchmetadata (const char* key)

This method can be used to obtain metadata (meta data).

BOOL Dd::image::reader::supports_stereo () const

This is a flag that determines whether the current class supports stereoscopic double-view reading.

BOOL Dd::image::reader::filestereo () const

This is a flag indicating whether the current file is a stereoscopic material.

BOOL Dd::image::reader::videosequence () const

This is a flag that indicates whether the current file is video footage, or Mov.

About the FileReader base class:

FileReader is a class that inherits from reader, but it always behaves like a base class. It needs to instantiate the same function method as reader. And then filereader all the interesting things about this class, mostly because it has some new features that go beyond reader.

When a user inherits the reader class directly to create his own reader class, you must also instantiate the file manipulation function. FileReader provides a way to directly enter or manipulate file data, and for most instances, FileReader is a very suitable solution.

To use more features, you simply need to customize a class to inherit Dd::image::filereader as follows.

Class Myreader:public dd::image::filereader{...  };

The extended features of the FileReader have the following:

int Dd::image::filereader::lockintint  length)int dd::image::filereader: :lockint  l)int dd::image::filereader::lockint l)

The above three methods are used to lock data on a given parameter.

Const Char& dd::image::filereader::byteconstconstcharconst

The above two methods are used to enter bytes on a given offset.

void Dd::image::filereader::unlock ()

Unlocks the memory before unlocking it.

int Dd::image::filereader::read (voidintint  max_)int dd::image:: Filereader::read (voidint  l)int dd::image::filereader::read (void int L)

Read directly into the memory file.

Reader's knobs mechanism:

Adding knobs to the reader class requires additional steps because the reader class is different from OPS. There are specific objects that can be initialized and registered with reader to give reader the ability to create knobs like regular op. There are two main steps as follows:

1. Inherit a Dd::image::readerformat class. Using this Readerformat class, you can instantiate the knobs () and knob_changed () interfaces.

2. Create a new, correct type of object with your own reader class to ensure that the correct reader format is initialized.

The code is as follows:

classMyfileformat: Publicdd::image::readerformat{//implementation of the knobs call  voidKnobs (knob_callback c)}classmyreader: Publicdd::image::filereader{Static ConstDescription D;}Staticreader* Build (read* R,intFdConstUnsignedChar* B,intN) {  return Newmyreader (R, FD, B, n);}Static BOOLTestintFdConstUnsignedChar* block,intN) {  return(block[0] ==my_magic_byte);}Staticreaderformat* Buildformat (read*IOP) {  return NewMyfileformat ();}ConstReader::D escription myreader::d ("myfile\0","my file format", build, test, Buildformat);

The first Myfileformat class is a wrapper, which is used to include the knobs class. The second class is myreader, inherited from FileReader, and description is defined in the class. The third block of code is the definition of the build function, the fourth block is the definition of the test function, and the fifth is the definition of the Buildformat function. Finally, the description function is defined, which is a description of the Myreader class, and the parameter is a buildformat more than the reader base class. This is also a feature of the FileReader base class, with extended properties that can be easily added to new property features.

The Knobs object is newly added through the Buildformat function in the case.

Reading MetaData:

The metadata can be decoded again using the same mode to read. Dd::image::fetchmetadata (const char* key) can return an object Dd::image::metadata::bundle after it is instantiated. The code is as follows:

class  Public dd::image::filereader{...  Dd::image::metadata::bundleConstChar* key)  {    return  _ MetaData;  }  Dd::image::metadata::bundle _metadata;}

In this case, the _metadata information can be obtained at the time of requested. This metadata was built in advance when the reader object was built. can be called directly.

Testing with Tester:

As mentioned earlier, when reading a file, Nuke will determine which reader to read, based on the registered available extension corresponding to the file format. The following code is a simple test module to check the first byte to ensure matching My_magic_byte macros. This is, of course, a simple example of how to set up this function, and real instances will check for more complex patterns to ensure matching. (This function appears to be a test for the instruction address one by one) the test code block is as follows:

#define My_magic_byte 0x000000001staticboolintconstcharint  N) {   return (block[0] = = my_magic_byte);}

The second mechanism to prevent erroneous file suffixes is as follows:

typedef BOOL (*tester) (int fd, const unsigned char* buf, int bufsize);
int fd,constChar* block,int N)

The return value of the tester function is a pointer, and the execution result is a bool value, when the pointer is nonzero, indicating that a UNIX file is used to store the image. In this case, the reader class will open the Unix file and call the function. If the function execution result is true, then the corresponding reader will be called. Of course, this mechanism also allows all reader classes to vote on an unknown file type to determine who will read the file.

If the return value is NULL, the image is passed to the reader mechanism in the form of a null value.

Working Metadata:

Metadata is addressed in nuke by Dd::image::metadata::bundle objects. This abstract object provides all the functions that need to be read and written.

There are two things to note in the process of using metadata, metadata can be divided into two mechanisms:

The default metadata mechanism for 1:nuke recognition. such as the time Code (DD::IMAGE::METADATA::TIMECODE) This keyword is used to store a specific value. So nuke read and write the time code, use this keyword.

2: Custom metadata mechanism. If you want to replace the Timecode keyword with a different name, the nuke internally will also recognize the way the Key-value value pair is.

NDK Learning Note (v) Reader mechanism