With the correct resolution and format selected, you then insert Write nodes to indicate where you want to render images from the script.
|
Inserting Write nodes for rendering. |
One Write node is usually placed at the bottom of the compositing tree to render the final output. However, Write nodes have both input and output connectors, so they may be embedded anywhere in the compositing tree.
You can execute renders for a single Write node or all Write nodes in your compositing script.
1. | Select the node in the script from which you want to render an image. |
2. | Select Image > Write (or press W over the Node Graph). Nuke attaches a Write node and opens its properties panel. |
3. | Connect a Viewer to the Write node you want to render and verify that the correct resolution is displayed for output. If necessary, press Ctrl/Cmd+P to toggle between full-res and proxy resolution. The displayed output resolution is used for rendering. |
4. | In the properties panel, click the file or proxy field’s folder icon (depending on whether you want to render high res or low res images) and browse to the directory where you want to store the rendered sequence. For instructions, see Using the File Browser. |
5. | After the path, type a name for the rendered image and then click OK. If you’re rendering an image sequence, include the frame number variable (for example, ####) in the name. |
See To Render Selected or All Write Nodes in the Script below for examples of valid file names with the frame number variable.
6. | If necessary, adjust the following controls: |
• Using the channels dropdown menu and checkboxes, select the channels you want to render.
• Using the frame dropdown menu and input field, set the relation between the currently processed frame and the numbering of the frame written out. For more information, see Changing the Numbering of Rendered Frames.
• check read file if you want the output of the Write node to be produced by reading the rendered file back in rather than by processing the upstream node tree. For more information on this and the missing frames control, see Using a Write Node to Read in the Rendered Image.
• From the colorspace dropdown menu, select which lookup table to use when converting between the images’ color space and Nuke’s internal color space.
• From the file type dropdown menu, select the file format for the rendered images. If you don’t specify a file format, Nuke uses the extension in the file name to figure out the format.
• Check the limit to range box if you want to disable the node when executed outside of a specified frame range. In the frame range fields, enter the range of frames you want to make executable with this Write node.
7. | In the Write node properties, click the Render button. |
8. | Nuke prompts for a frame range, defaulting to the range you gave in the frame range fields. If necessary, change the start and end frames (for example, 1-100), and then click OK. |
TIP: When specifying the frame range to render, you can enter complex frame ranges into the frame range prompt dialog. For example, if you enter 1-5 8 10 15 22-25, it only renders those frames. You can also increment rendered frames using something like 10-50x10, which resolves to only frames 10, 20, 30, 40, and 50 from the range.
Likewise, you can specify multiple ranges on the command line, for example:
nuke -F 1-5 -F 8 -F 10 -F 15 -F 20-40x5 -x myscript.nk
TIP: When rendering with the Write node, you can force a certain data type by adding the data type and a colon before the file path. For example, you can enter ftiff:C:\Temp\test.tif as the file path to render a file whose data type is ftiff and extension tif.
1. | Connect a Viewer to a Write node you want to render and verify that the correct resolution is displayed for output. |
2. | If necessary, press Ctrl/Cmd+P to toggle between full-res and proxy resolution. The displayed output resolution is used for rendering. |
3. | If you want, you can change the order in which your Write nodes are rendered by giving them custom render order numbers in the render order field. |
4. | Do one of the following: |
• With the desired Write node selected, select Render > Render selected (or press F7).
• Select Render > Render all (or press F5).
5. | In the Render dialog, adjust the render settings if necessary. The default values are drawn from the Viewer you have active. |
• Frame range - set the frame range you want to render.
• Use proxy - check to use proxy mode.
• Render in background - check to render in the background. If you check this, you can also set #CPU limit and Memory limit controls. The former limits the number of threads that Nuke uses in the background and the latter limits the amount of cache memory that Nuke uses.
Setting the number of CPUs is useful for limiting Nuke to use only a particular number of CPUs (for example, 4 threads can occupy 4 CPUs) with the OS trying to distribute time accordingly, or you could limit Nuke to a number of CPUs so background rendering won't interfere too much with your interactive Nuke.
• Continue on error - check to keep rendering even if an error occurs during the process.
• Views - set which stereo views to include in the render.
6. | Click OK. |
TIP: When specifying the frame range to render, you can enter complex frame ranges into the frame range prompt dialog. For example, if you enter "1-5 8 10 15 22-25", it only renders those frames. Likewise, you can specify multiple ranges on the command line, for example:
nuke -F 1-5 -F 8 -F 10 -F 15 -F 22-25 -x myscript.nk
You can see the progress of your render in the status window that appears. When the render is complete, the rendered images are added to the directory you specified in step 4.
TIP: When rendering with the Write node, you can force a certain data type by adding the data type and a colon before the file path. For example, you can enter ftiff:C:\Temp\test.tif as the file path to render a file whose data type is ftiff and extension tif.
If you are rendering .mov files, you can:
• choose the QuickTime codec from the codec dropdown menu.
NOTE: If you're using the Avid DNxHD codec, Avid AVDn, avoid setting the pixel format control to r408 as there is a known issue within the codec causing frames to darken with each frame progression in the sequence.
• Set the encoder library used to write the file:
NOTE: Depending on the codec in use, this control may be read only. For example, Apple ProRes 4444 always uses mov64, but Animation allows you to choose mov32 or mov64.
• mov32 - uses the full range of QuickTime codecs, but can be slow to process due to extra complexity during decode.
• mov64 - uses its own packing and unpacking and streams decode/encode for extra processing speed, but only supports a sub-set of QuickTime codecs.
NOTE: Nuke defaults to the fastest decoder for the codec used in the file - if you're reading in a type supported by the mov64 sub-set, Nuke defaults to that reader. Otherwise, the fallback mov32 reader is used.
• fps - set the playback frames per second for the output file.
• audio file - Allows you to specify a separate audio file to include in the output. Either enter the filepath manually or click the browse button to locate the audio file.
• audio offset - Sets the start time of any audio file specified in the audio file control. The unit of measure is specified using the units control. Negative values cause the audio to start before the video and vice versa.
• write timecode - When enabled, Nuke writes the timecode into the .mov metadata, where available.
NOTE: The timecode is read from the input/timecode metadata key pair. If this field is blank, the timecode is not written into the file.
You can adjust advanced codec options by opening the Advanced dropdown. The options available vary, depending on whether you're using the mov32 or mov64 encoder.
Control |
Description |
---|---|
mov32 encoder |
|
codec options |
Click to display an advanced Compression Settings dialog. |
fast start |
When enabled, MOVs are playable while still down loading. |
use format aspect |
When enabled, the rendered .mov uses the same pixel ratio as the input. When disabled, the codec determines the pixel aspect to use. NOTE: Codecs writing PAL and NTSC should be allowed to determine the ratio during render, but formats that otherwise expect 1:1 pixel ratios may require this override. |
ycbcr matrix |
Sets the way RGB is converted to Y’CbCr. Rec 601 and Rec 709 follow the ITU.BC specifications, whilst Nuke Legacy, Nuke Legacy Mpeg, and Nuke Legacy YUVS are retained for backwards compatibility. Format-based sets the color matrix to Rec 601 for formats with a width below 840 pixels and Rec 709 for formats with a width of 840 pixels or above. This setting is only available when you’re working with a Y’CbCr-based pixel type. |
pixel format |
Lists pixel formats supported by the current codec. The pixel format defines the type and layout Nuke requests from QuickTime: • Pixel colorspace - either RGB(A) or YCbCr(A). This defines whether QuickTime or Nuke’s QuickTime reader does the conversion between colorspaces. For a Y’CbCr pixel type, choosing an RGB(A) colorspace means Nuke relies on QuickTime to do the RGB to Y’CbCr conversion. Choosing a YCbCr(A) colorspace means that Nuke is responsible for the conversion, and so a specific ycbcr matrix can be used (this is recommended). • Pixel bit depth - 8-bit, 16-bit, and so on. This sets the encoding depth used when decompressing the frames. A large bit depth gives higher accuracy at the cost of speed and memory usage. • Pixel layout - 422, 444, 4444, and so on. This defines how the chroma channels in the buffer are arranged. 444 buffers have lower spatial chroma sampling than 422, so they are generally preferred when available. For all cases, Nuke unpacks the sub-sampled buffer to full resolution. • Range - either Biased or empty. For RGB(A) types, the values are full range (from 0 to 1). For YCbCr(A) types, the values are in video range by default, offering headroom at both ends of the scale. If this is set to Biased, then headroom is only available at the top end. • (4cc). This is the pixel type 4cc, as defined by the QuickTime API. This setting defaults to the best format accepted by the codec. |
write nclc |
When enabled, write the nclc data in the colr atom of the video sample. |
write gamma |
When enabled, write the gama data in the gama atom of the video sample. |
write prores |
When enabled, write the prores data in the prores header of the video sample. |
mov64 encoder |
|
bitrate |
Sets the target bitrate that the codec attempts to reach, within the limits set by the bitrate tolerance and quality min/max controls. NOTE: The bitrate control is only enabled for certain codecs, such as MPEG-4 - Video. |
bitrate tolerance |
Sets the amount that the bitrate can vary from the bitrate setting. Setting this tolerance too low will result in renders failing. NOTE: The bitratetolerance control is only enabled for certain codecs, such as MPEG-4 - Video. |
quality min |
Sets the quality range within which the codec can vary the image to achieve the specified bitrate. Higher ranges can introduce image degradation. NOTE: The quality min/max controls are only enabled for certain codecs, such as MPEG-4 - Video. |
quality max |
|
gop size |
Sets how many frames can be placed together to form a compression GOP (group of pictures). NOTE: Use caution with this control as large alterations can stop other applications reading the rendered file. NOTE: The gop sizecontrol is only enabled for certain codecs, such as MPEG-4 - Video. |
b frames |
Sets the maximum number of B frames that can be consecutive in the rendered file. The default, 0, does not impose any maximum number of B frames in the output. NOTE: The b frames control is only enabled for certain codecs, such as MPEG-4 - Video. |
write nclc |
When enabled, write the nclc data in the colr atom of the video sample. |
Nuke writes the selected colorspace and pixel format, along with some other information, into the metadata of the file. If you then read the rendered file in, Nuke reads that metadata and is able to pick the correct defaults for the file. To see the file metadata yourself, use a ViewMetaData node.
When writing QuickTime files, some users have reported receiving the following error at the end of rendering:
Failed to flatten movie data: the movie is open in another application.
This is because the output file has been opened by some other process. This can be the Finder on Mac OS X trying to show a preview, an OS file system search trying to index the file, or a virus checker, for example. The workaround is to turn off Fast Start in the Write node controls to skip the flattening process that is affected.
Nuke supports multi-part OpenEXR 2.0.1 files, which allow you to store your channels, layers, and views in separate parts of the file. Storing the data this way can make loading .exr files faster, as Nuke only has to access the part of the file that is requested rather than all parts. However, for backwards compatibility, you also have the option to render your .exr files as single-part images.
To set how the data is stored in your rendered .exr file, open the Write properties and set interleave to:
• channels, layers and views - Write channels, layers, and views into the same part of the rendered .exr file. This creates a single-part file to ensure backwards compatibility with earlier versions of Nuke and other applications using an older OpenEXR library.
• channels and layers - Write channels and layers into the same part of the rendered .exr file, but separate views into their own part. This creates a multi-part file and can speed up Read performance, as Nuke only has to access the part of the file that is requested rather than all parts.
• channels - Separate channels, layers, and views into their own parts of the rendered .exr file. This creates a multi-part file and can speed up Read performance if you work with only a few layers at a time.
|