Справка Houdini на русском Import and export Supported file formats

Image file formats

On this page

Available formats
16-bit image formats
- Field Notes on Converting Cineon Images

Tip

Some formats support gzipping the file (.gz extension). This can result in smaller files but makes loading/saving slightly slower.

Tip

Use the icp program to convert between image formats. For example, icp myImage.pic myImage.jpeg .

Available formats

Extensions	Type	Read	Write	Notes
`.pic`	Internal	✓	✓	Houdini picture format. Houdini image files are run-length encoded disk files with the suffix `.pic`. The files contain color and color map information as well as the size of the picture. Example source code for reading and writing Houdini image files is in $HFS/houdini/public/sidefx.Pic.tar.Z.
`.pic.gz`	Internal	✓	✓	gzip compressed `.pic`
`.pic.Z`	Internal	✓	✓	Compressed `.pic`.
`.rat`	Internal	✓	✓	Random Access Texture maps (RAT) are tuned for texture mapping. The format allows the renderer to access portions of the texture without having to load the whole image into memory at once. The RAT file format also supports arbitrary channel depth, meaning that a single channel image can be used as a texture map. Using `.rat` files is faster for texture mapping, and typically consumes less memory than other formats because portions of the map are flushed out if more data is required for rendering. Only the portions of the map required for rendering are loaded. By default, mantra allocates a maximum of 8 MB of RAM for rat files. you can specify the maximum amount of ram (in MB) used for texturing with the environment variable SESI_RAT_USAGE. For example `setenv SESI_RAT_USAGE 32`. We recommend using `.rat` files for texture maps before any other format because the quality tends to be much better than using stochastic sampling. Note To convert deep image rat files to openexr2.0, you need to run the standalone tools `dsmconvert`. `dsmconvert in.rat out.exr`
`.picnc`, `.ratnc`	Internal	✓	✓	Non-commercial versions of `pic` and `rat` formats saved by Houdini Apprentice. Cannot be used by regular Houdini.
`ip` / `iw` / `md`	External		✓	iplay / image window.
`.png`	Internal	✓	✓	Standard lossless network image format.
`.psd` / `.psb`	Internal	✓		Imports a `.psd` or `.psb` file into a COP. All of the layers and masks will be imported into a single COP with multiple planes.
`fip`	Internal		✓	Flipped iplay window.
`vf` / `a60`	Internal	✓	✓	VideoFramer/Abekas
`.cin` / `.kdk`	Internal	✓	✓	Kodak Cineon format
`.fit`	External	✓	✓	FIT tiled image format
`.gif`	External	✓	✓	GIF
`.gif89`	External	✓	✓	GIF89a (GIF with 1-bit alpha)
`.ies`	Internal	✓		IES format (photometric lights) IES files store a table of light emission intensities parameterized by angle. When viewing an IES image, only the light emission intensities are shown, not the angles on which the pixels are parameterized. The correct polar mapping, based on the angles stored in the file, is only applied when the image file is used as an environment map. For example, when using the `environment()` VEX function. The candela intensity values in the file are automatically normalized to the maximum intensity value in the file upon load. This allows intuitive rendering without the need to calibrate to the physical units stored in a particular file.
`.jpg` / `.jpeg`	Internal	✓	✓	JPEG (Very efficient for storage; lossy)
`.qtl`	External	✓	✓	Quantel `yuv` format
`.rla` / `rlb`	Internal	✓	✓	Wavefront format Wavefront pictures are treated like other image file formats but have one additional feature. The gamma value placed in Wavefront `.rla` files defaults to 2.2, but can be overridden by setting the `WFGAMMA` environment variable to the desired value.
`.rla16`	Internal	✓	✓	Wavefront `.rla` 16 bit format
`.pix`	Internal	✓	✓	Alias `.pix` format
`.sgi` / `.rgb` `.rgba`	Internal	✓	✓	SGI format (a.k.a. `.rgb` by non-Houdini software)
`.si` / `.pic`	Internal	✓	✓	Softimage format
`.tif` / `.tiff`	Internal	✓	✓	TIFF (Tagged Image File Format) is the standard used by RenderMan and many Mac and PC applications. If a file has a `.tif3` file extension, Houdini uses tiff version 5.0 from mid-1990: LZW compression, RGB color space, and 32-bits per pixel (i.e. four channels per pixel - RGB and alpha, at eight bits per channel). If a file has a plain `.tif` extension, Houdini uses a newer TIFF library from early-1996 that is compatible with RenderMan 3.6. Adobe-Deflate codecs are also supported.
`.tif3`	Internal	✓	✓	TIFF RGB, no alpha
`.tif16`	External	✓	✓	TIFF 16 bit format
`.tx`	External	✓	✓	RenderMan texture images (requires RenderMan t.kit)
`.tga` / `.vst`	Internal	✓	✓	The Targa and Vista file formats are treated identically. Houdini supports: Image type 10 (RGB Run Length Encoded) Image type 2 (RGB Raw Data Stream) Data Bits 15, 16, 24 and 32 …and all combinations of the above (for example Type 10, 16 bits per pixel).
`.vtg`	Internal	✓	✓	Houdini’s preferred extension for Vertigo files is `.vtg`, however Vertigo uses the extension `.pic` by default. Houdini will intelligently load Vertigo files with a `.pic` extension. Compressed Vertigo files (.Z) cannot be read by the frame buffer library, nor can they be created. Use the unix uncompress program before using them in Houdini.
`.yuv`	Internal	✓	✓	Abekas `yuv` format

Note

Some older software packages use .pic as an extension for SGI pixmap images (.rgb or .sgi). Houdini uses .pic for its own image format. Houdini should still load SGI pixmaps with the .pic extension correctly, but if you have problems try renaming the SGI file to have an .sgi extension.

16-bit image formats

Houdini supports Cineon (.cin, .kdk), 16-bit TIFF (.tif16), and 16-bit Alias RLA (.rla16).

Note

When the composite editor reads or writes Cineon format files directly, it does not perform gamma correction.

When reading or writing Cineon format images Houdini performs a logarithmic-to-linear conversion as described in "Greyscale Transformations of Cineon Digital Film Data for Display, Conversion and Film Recording", Cinesite Digital Film Center, Kodak Motion Picture & Television. This conversion process can be adjusted using the following environment variables:

CINEON_FLIP

When set (to any value) flips all Cineon images in Y during input.

CINEON_FILM_GAMMA

This value is used when scaling the between printing densities and "relative log exposure" values. Default value is 0.6.

CINEON_WHITE_POINT

The Cineon log scale value that is considered to be full white and will be mapped on input to the maximum channel value. Range 0 to 1023 (default 685).

CINEON_BLACK_POINT

The Cineon log scale value that is considered to be full black and will be mapped on input to zero. Range 0 to 1023 (default 85).

Field Notes on Converting Cineon Images

CGI imagery is calculated in gamma 1 linear RGB color space. If you want to convert your 10 bit log data to gamma 1 linear data (so that everything is the same), the correct film gamma to use for this conversion is 0.6.

The 0 to 1 step in 10 bit log space is over three hundred thousand times smaller than the 0 to 1023 step. To convert the entire range from 0 to 1023 to linear gamma 1 space would require 19 bits! If you want to convert 10 bit log data to 16 linear data using the correct gamma of 0.6, the highest white point you can use without posterizing the data is about 825.

Using conversion parameters of a white point of 1023 and a film gamma of 1 does allow you to store the entire log range in 16 bits without loss. This is because the signal path that results has a gamma of about 1/0.6, or 1.6666, rather than 1. This essentially brightens the middle grays, allowing more of the 16 bit range to be devoted to the dark levels. If one tries to linearize the entire 0 to 1023 range using a film gamma of 0.6, the dark values will be heavily posterized, and the 10 bit log data will be ruined. Those users that choose to convert using a film gamma of 1.0, should be aware that the signal path that results has a gamma of 1.6666, and they may wish to render their images using that gamma as well.

It is also important to understand that the cinematographer has to point the camera into the sun to get densities in the negative that are anywhere near 1023. The vast majority of 10 bit log scans contain pixels with a maximum brightness in the high 700's to low 800's. This is important, because every 90 steps of log code values translates into a doubling ( 1 stop ) of brightness. So, if you have material that never gets brighter than, say 843 (180 code values, or 2 stops, below 1023), when you linearize using a white point of 1023 (and a gamma of 0.6), your linear data will never get brighter than value 16383 (25% of 65535). The 16 bit levels from 16384 to 65535 (75% of your numerical precision) will never be used! (Using a gamma of 1.0, your 10 bit log value of 843 will convert to about 28600 in 16 bit space.) This is a gross waste of precision.

If you want to maximize your 16 bit precision, the optimal way to proceed is to 'ride the content'. That is, you check all the film elements that will going into a shot and search for the brightest pixel. Once you find the brightest code value (say it’s 765) you add a little fudge factor to give yourself some wiggle room and pick a white point of 790 or so. You apply this one white point value consistently to convert all the layers in your shot. In practice, it is common for a single white point to be chosen for a sequence of shots that were all shot under the same conditions.

To find the brightest pixel, some people use a special purpose tool to scan every pixel in every frame of all the elements, printing out the highest value found. Alternately, you can set the white point to various values and read your images in and look at them. If any bright areas of the images are 1, you have to set the white point higher. You want the brightest pixels in your scans to be at about 90 percent brightness. You must set the white point using the environment variable CINEON_WHITE_POINT.